Home / Guides / How to duplicate an app on macOS — and why it doesn't work
How to duplicate an app on macOS — and why it doesn't work
Select an app, hit ⌘D, and Finder makes you “AppName copy.app.” Here's what actually happens when you open it — and the two things macOS keys off that a filename copy never touches.
What Finder's copy actually does
Select any app in Applications and press ⌘D, or hold Option and drag. Finder makes a byte-for-byte duplicate — same code, same resources, same Info.plist. It's real disk-level copying (APFS makes it copy-on-write, so it's fast and takes almost no extra space), and macOS treats a code-signed app's signature as still valid, since nothing inside it changed.
Open the copy, though, and you don't get a second account. You either get nothing — the original app just comes to the front — or a second window that's already signed in to the exact same account as the first. Either way, it's the same app to macOS. Here's why.
macOS keys an app's identity by bundle ID, not by filename
Every Mac app carries a CFBundleIdentifier in its Info.plist — a reverse-DNS string the app's developer chose once, at build time. It's how LaunchServices, the system service that resolves “open this app” to a running process, tells apps apart. It never looks at the file's name or its path.
Rename “Slack.app” to “Slack Personal.app,” move it anywhere you like — the CFBundleIdentifier inside is unchanged, so LaunchServices still sees the identical app it already knows. If that app enforces single-instance behavior — most do, see why open -n doesn't help either — opening the copy just activates the running one.
Duplicating a file changes its name and its inode. It does not open the Info.plist and generate a new CFBundleIdentifier, and it has no way to know it should — that would mean rewriting the app's compiled binary and resources, not just its file listing.
Even a real second process shares the same account
Say the app you copied doesn't lock against multiple instances — you do get two separate processes running. They still aren't two accounts, because both processes read and write the exact same on-disk data: ~/Library/Application Support/<AppName> (or, for a sandboxed app, its shared container under ~/Library/Containers/<bundle-id>), the same preferences file, and any Keychain items the app stores — all scoped to its bundle ID.
Sign out in one window, and you're signed out in the other. There was only ever one signed-in session on disk, and now two processes are pointed at it instead of one.
What a real duplicate needs
To get an actually independent second copy — its own login, its own local data, running at the same time as the first — three things have to change, not one:
- A new, unique
CFBundleIdentifier, so LaunchServices treats it as a distinct app rather than a second copy of the one it already knows. - A private data directory, so Application Support, preferences and cache don't collide with the original's.
- A re-signed binary that still runs — changing the bundle identifier invalidates the original code signature, so the copy needs a new one macOS will actually launch. Apps that check their own Keychain access group by bundle ID internally need their credential lookups redirected too, or login fails silently.
None of that comes from a file-level copy — Finder has no way to reach into a compiled app and rewire what it thinks its own identity is. That's the part that turns “duplicate a file” into “build a second app.”
Questions
Does renaming the copy give it a new identity?
No. Renaming the .app file changes its display name only. The CFBundleIdentifier that LaunchServices actually keys off lives inside the app's Info.plist and is untouched by a rename or a move.
Is this what an app-cloning tool like MacDupl does automatically?
Yes — a clone gets a freshly generated bundle identifier, its own data directory, and a valid re-signature, done in a couple of seconds instead of by hand. Check the compatibility list for a specific app.
Why does the copy still open fine even though it's the same app?
Because the code signature is still valid — nothing inside the file changed, so Gatekeeper has nothing to object to. A valid signature and a distinct identity are two separate questions; the copy passes the first and fails the second.
Try it on your own Mac
The free trial classifies every app in your Applications folder instantly, so you can see exactly how a specific app is handled before paying anything.