DEV Community: Martin Grüner

How to compare two folders on a Mac (Terminal, Git, and a visual diff)

Martin Grüner — Sun, 11 Oct 2026 10:47:13 +0000

You have two copies of a project, a backup and the original, or two versions of a delivery, and you need to know what is different between them. Finder cannot tell you. Here are three ways to do it on a Mac, from the quickest to the most thorough.

1. Terminal: `diff -rq`

macOS ships with diff, and it can compare whole folder trees:

diff -rq "Folder A" "Folder B"

-r walks every subfolder and -q only reports which files differ instead of printing every changed line. The output lists files that differ and files that exist on only one side:

Files Folder A/config.json and Folder B/config.json differ
Only in Folder B/assets: logo@2x.png

This is fast and always available. It tells you which files differ, not what changed inside them, and a file that was moved shows up twice: once as missing and once as new.

2. Git: `git diff --no-index`

If you want to see the changed lines too, Git can compare two folders that are not in a repository:

git diff --no-index "Folder A" "Folder B"

You get a normal patch for every changed text file, with colors and your usual pager. Add --stat for a summary of changed files first. It works well for source code. It is harder to read for spreadsheets, PDFs, Word documents, and images, which show up as binary files.

3. A visual folder comparison

When the folders are large, mix file types, or you need to be sure nothing is missing, a visual comparison is easier to review. I build Diff Anything, a comparison app for Mac and Windows, so this is the workflow I use:

Choose the original folder on the left and the copy or newer version on the right.
Check the folder options: include subfolders, decide whether hidden files such as .env belong in the review, and add ignore patterns for build output like DerivedData or node_modules.
Read the results in a tree or a table. Each path is marked as only on the left, only on the right, changed, moved, or identical, and you can search and filter by status.
Open any changed pair to see what is different inside it: text and code as a side-by-side diff, spreadsheets cell by cell, PDF and Word documents by their text, and images with an overlay.

Two settings matter when you need an exact answer. Turn on Compare hashes for a byte-level content check rather than trusting names, sizes, and dates. Leave Semantic structured files on when you are reviewing configuration: JSON, YAML, XML, CSV, and environment files are then compared by their parsed content, so reordered JSON keys do not show up as a change.

Moved files are matched by content at a different path, so a renamed asset appears once as a move instead of a deletion plus an addition.

Everything runs on your Mac. There is no account, no upload, and no AI involved, which matters when the folders hold client work, credentials, or anything you would rather not paste into a website. It needs macOS 13 or later, and there is a free version to try it on a small pair of folders.

Which one to use

Quick check of which files differ: diff -rq.
Code changes you want to read as a patch: git diff --no-index.
Backups, client handoffs, mixed file types, or moved files: a visual comparison.

The full guide, with a two-minute video and a table explaining every result label, is here: Compare two folders on Mac and see what changed. If you are on Windows, there is a Windows version of the guide too.

Testing deep links on a real phone without emailing them to yourself

Martin Grüner — Fri, 02 Oct 2026 13:11:14 +0000

On a simulator or a phone connected by cable, opening a deep link is one command:

# iOS Simulator
xcrun simctl openurl booted "myapp://orders/1234"

# Android device or emulator over adb
adb shell am start -W -a android.intent.action.VIEW -d "myapp://orders/1234"

On the phone in your hand, with no cable and no terminal, most of us do something worse. We paste the link into Notes, send it to ourselves in Slack, or email it to our own address, then tap it and hope it opens the right screen. When the order number changes, we do it again.

It gets harder when someone else reports the bug. The ticket says "open this link on a device and check the order screen", and someone has to get that link onto a phone, open it, and write down what happened.

What a phone needs for this

After doing this by hand for a while, I wanted four things on the test phone itself:

Links kept per app, so one app's staging links don't mix with another's.
Values in the link. Save myapp://orders/{{orderId}} once and change orderId when you open it, instead of editing the URL each time.
A record of each open, including whether the phone accepted the link, so you know what you already tried.
A fast way in. Copying a link on a laptop and getting it onto the phone should be one step, not a message to yourself.

How I handle it now

I built TestDock, an iPhone and Android app, for this. Full disclosure: it's my app. Version 1.1 is about the fourth point, getting the link onto the phone:

Paste and open. Copy a link anywhere and a Paste button appears. On iPhone it uses Apple's paste button, so there is no "Allow Paste" prompt. TestDock finds the link inside whatever text you copied.
Quick open. Open any URL without saving it first. The last five stay in a list, each marked as opened or failed.
Paste a whole list. Paste text that contains several links and save them all at once. Links you already saved are skipped.
Share in. Share a link from Slack, Mail, Safari, or any app that shares text or links, and it lands in Quick open.

Putting the test in the ticket

The change I use most is test links. A test in TestDock is a list of steps: open a link, check the expected result, add a note. You can copy a link to a test and paste it into a bug ticket. The link can carry the values for the run, such as orderId=1234.

Whoever opens the ticket on a phone with TestDock taps the link, sees which test it is with the values filled in, and starts it. They mark each step Pass, Fail, or Skip, attach a screenshot, and share the result back as Markdown, PDF, JSON, or text. Tokens and passwords in links are masked in the shared result. After the fix, the same link runs the same test again.

Where the data lives

TestDock has no account and no server. Profiles, links, and results stay on the phone. It connects to the internet only when you open a link, send a push notification, or inspect an association file.

Free and Pro

TestDock is free for one app, with unlimited saved links, Quick open, Paste, sharing into TestDock, app-icon shortcuts, and one test of your own. Pro is a one-time purchase that adds unlimited apps and tests, push notification testing (Expo Push, Firebase Cloud Messaging, and APNs on iPhone), share-sheet testing, apple-app-site-association and assetlinks.json inspection, and profile import and export.

The full write-up with screenshots: https://martingruner.com/blog/testdock-1-1

How do you get links onto a physical test device today? I'm curious whether anyone has a better routine than messaging themselves.

Making active local development work visible in DevDock 1.4

Martin Grüner — Fri, 25 Sep 2026 19:03:38 +0000

A project dashboard can list repositories, commands, and containers, yet still miss the state that matters most: what is changing right now.

For DevDock 1.4, I focused on three pieces of active state.

See when an agent is working in a project

DevDock now shows when Claude Code or Codex is working in a registered project. For Claude Code, it reads the recent local transcripts already stored under ~/.claude/projects, including sessions started from a terminal or the desktop app. The project list can show the session title or latest prompt without an account connection.

That visible state helps prevent accidental overlap: switching branches, starting a build, or editing the same files while an agent is active.

Keep long Git operations within reach

Long Git operations no longer need to hold the workspace open. A new Activity center lists running operations and recent results.

Hiding a progress window leaves the operation running. Selecting it in the Activity center reopens the current step and live output. Pull-before-push still continues into the original push after a successful pull.

Stop the whole command process tree

Stopping a saved command now stops its complete process tree. Scripts such as npm run dev often start a child dev server or watcher. Ending only the parent can leave a port occupied, so DevDock now tracks and stops every process the command starts, including when the app closes.

There is a step-by-step guide to running recurring development commands on Windows.

Smaller improvements that remove friction

The release also improves toolchain detection, event-stream reconnection, action-specific status, Git authentication feedback, command controls, and Microsoft Store purchase restoration.

The complete release article includes screenshots, user-facing details, and update instructions:

Read the DevDock 1.4 release notes

Designing a smart code diff without replacing the line diff

Martin Grüner — Wed, 09 Sep 2026 08:41:55 +0000

A conventional line diff is valuable because it is literal. It is also easy to overwhelm with formatter churn, wrapped expressions, and code reflow. For Diff Anything 1.5, I treated those as two different review questions instead of making one algorithm answer both.

One comparison, two views

Smart Diff aligns language-aware tokens and uses conservative language-family rules for whitespace, indentation, statement boundaries, strings, and comments. Line Diff remains available in the same toolbar for the exact patch. Both views operate on the same source pair and retain syntax highlighting, editing, and apply controls.

The difficult boundary was avoiding an inflated claim: this is not an AST diff and it does not claim compiler-level semantic equivalence. That constraint made it practical to support all 117 non-plain-text editor languages consistently, including 18 newly maintained definitions.

Test the packaged application, not only the engine

I built a release fixture matrix for code, text, structured data, spreadsheets, images, PDFs, archives, folders, merge, transforms, save, export, and recovery. Running it through the packaged macOS app caught a malformed-YAML footer issue and a one-way apply dirty-state bug before release.

The same release also tightens large-comparison performance, cancellation, virtualization, interaction feedback, accessibility, and recovery.

If you are choosing between diff tools, I wrote up how Diff Anything compares with Beyond Compare and where each one fits.

The full release write-up includes the language list, exact product boundaries, and a screenshot from the actual app:

https://martingruner.com/blog/diff-anything-1-5

Comparing XLSX, ODS, Numbers, CSV, and TSV without converting first

Martin Grüner — Wed, 26 Aug 2026 08:17:19 +0000

Diff Anything 1.3 adds the spreadsheet workflow I most wanted the product to have: comparing files even when they use different spreadsheet formats. An XLSX workbook can be compared with ODS, an Apple Numbers file with Excel, or a CSV/TSV table with a workbook. There is no conversion step before the comparison.

The comparison is based on stored cell values. Both sides stay in an aligned, sheet-aware grid with row numbers, column letters, empty cells, values, and the selected coordinate connected to the Differences pane. Large populated ranges are virtualized so the review does not need to render an entire workbook at once.

The boundary matters as much as the feature: spreadsheet mode does not compare formulas, formatting, charts, macros, or workbook layout. It compares the stored values a reviewer can inspect cell by cell.

Folder diff was rebuilt as a review workspace too. It now has two-pane tree and table layouts, search, status filters, progressive loading, ignore patterns, moved-file detection, and direct opening of nested file pairs. Pro synchronization turns a reviewed selection into an explicit create, update, delete, and move plan, with stale-result protection, recovery journals, rollback, and undo. Step-by-step guides: compare two folders on a Mac and compare two folders on Windows.

PDF review now makes two different questions explicit. Visual diff renders both versions and highlights page-pixel changes, which can reveal changed charts, replaced or moved images, visible signature changes, stamps, missing elements, and layout shifts. Extracted text is a separate mode for additions, removals, and changed wording. Visual diff does not authenticate a digital signature or inspect hidden PDF metadata.

All comparisons still run locally on macOS and Windows. There is no Diff Anything account, cloud comparison service, analytics, or telemetry.

The full release notes include the exact boundaries and four new screenshots: https://martingruner.com/blog/diff-anything-1-3

Keeping 3D device-frame perspective editable through native export

Martin Grüner — Wed, 19 Aug 2026 16:43:21 +0000

A device frame can explain what kind of app is being shown, but a flat mockup often sits on top of the composition instead of belonging to it. In Screen Studio Kit 1.2, I added controlled depth without flattening the frame into a finished bitmap.

Device-frame layers now store independent Turn and Tilt angles. The hardware body, screen content, finish, shadows, and perspective remain connected to the same editable layer. Both angles are constrained from -60° to 60°, and the canvas updates immediately while the frame is edited.

The detail that mattered most was export parity. The interactive canvas is not the final renderer, so the native export engine consumes the same stored angles. Existing projects migrate with zero-degree values, preserving their previous appearance until a frame is deliberately changed. Perspective is scene data, not a preview-only effect.

This also needs restraint. Screen Studio Kit warns when a rotated custom iPhone frame is used for an App Store output so the artwork can be checked against Apple’s current requirements. The same reusable project can keep a 3D treatment for another store or campaign and reset the App Store version.

The complete editor, local projects, asset management, preview, validation, device-frame editing, one size and one language per export, and up to 10 full-resolution exports per local day are in the Free tier.

For the basics, there is a step-by-step guide to putting app captures in editable device frames.

The release notes show the real editor and exported artwork: https://martingruner.com/blog/screen-studio-kit-1-2

A diff tool should fail honestly when the input gets difficult

Martin Grüner — Wed, 19 Aug 2026 16:24:29 +0000

Diff Anything 1.2 is a quality release in the literal sense: the same files produce more faithful results, difficult inputs fail more honestly, and every route into a comparison follows the same rules.

The visible change is a broader Free tier. The desktop app can now preview YAML, XML, CSV, environment files, HTTP responses, API schemas, folders, archives, PDF and Office documents, images, and binary files. Free previews are explicitly bounded: files up to 5 MiB per side, 10 new sessions per local day, the first 100 collection items, and the first 3 PDF page previews. The Free CLI remains focused on text and JSON.

The less visible work is in awkward inputs. Structured comparison now handles cases such as duplicate keys, repeated CSV keys, repeated HTTP headers, YAML multi-documents, XML namespace meaning, and masked environment values with explicit warnings when a result cannot be represented without ambiguity. Image comparison handles transparency and decoded-size budgets more carefully. PDF and Office handling keeps extracted text and rendered evidence distinct.

Everything stays local: there is no account, cloud comparison service, analytics, or telemetry. The point is not to claim that one engine can perfectly understand every format. It is to select a bounded specialist engine, show its limits, and keep desktop, CLI, Git, and CI behavior aligned. I wrote more about why a diff should not require handing your files to someone else.

The full release notes include the exact boundaries and screenshots: https://martingruner.com/blog/diff-anything-1-2

What a Windows developer workspace should remember between context switches

Martin Grüner — Wed, 19 Aug 2026 16:23:48 +0000

I built DevDock because reopening a codebase is not the same as recovering the context needed to work on it. A product may span several folders, and the useful state is scattered across commands, Docker, Git, databases, project health, and the checks I want to run before release.

DevDock is my attempt to keep that context in one local Windows workspace. Each registered project gets an overview, saved commands, run history, Docker and Git state, database operations, local security findings, settings, and tools. A Today view keeps recent projects and saved daily workflows close when I switch between products.

The important boundary is that it is a local tool. It does not upload source code. The security audit checks registered folders for exposed secrets, private keys, tracked credential files, unsafe permissions, escaping symlinks, and missing lockfiles, while withholding matched secret values. Database tools are deliberately bounded around schema inspection, constrained record lookups, migration review, diagnostics, and confirmed backup operations.

The Free tier supports up to three local projects with core commands, Git, Docker, Project Doctor, and security audits. Pro is a one-time purchase for unlimited and multi-folder projects, custom workflows, complete history and insights, database tools, SSH transfers, and configuration backup and restore.

I would especially value feedback from developers who work across several local repositories: which piece of context costs you the most time when you return to a project?

If you want to try the workflow, I wrote a step-by-step guide to keeping every development project on Windows ready to run.

https://martingruner.com/projects/devdock