Why Split Safari Into Two Separate Instances?
Most people keep a single Safari installation on macOS and use it as the default web browser for all of their online activity. The single instance shares one set of preferences, bookmarks, extensions, and cache. That setup works well for most users, but it can become a bottleneck if you need distinct browsing contexts for work, personal life, or troubleshooting. Having two separate Safari applications - each with its own settings - lets you run parallel sessions that do not interfere with one another.
Consider a professional who uses Safari for two different email accounts, a corporate account that requires strict privacy settings and a personal account that can stay a bit less secure. With a single Safari, switching between accounts involves logging out, clearing cookies, or opening new private windows - all of which can be tedious and risky if you accidentally mix cookies. Two instances solve this problem at the operating‑system level: each instance holds its own cookie store and preferences file.
Another common scenario is the dreaded crash. Safari is a native macOS app, but even native apps can crash due to memory pressure, malformed extensions, or corrupt user data. When Safari crashes, all open tabs and windows are lost. If you have two separate instances, a crash in one does not affect the other. The remaining instance can continue running, preserving its open pages.
Developers or power users often test websites, JavaScript, or CSS in real time. By running two Safari instances, one can stay in a stable environment while the other is used for experimentation. This isolation reduces the risk of corrupting data or unintentionally affecting live sites. Moreover, some people enjoy customizing Safari with extensions or themes that they do not want available to every tab. Having a second instance gives a sandbox for those experiments.
Beyond technical reasons, there's a psychological benefit. When you open a fresh Safari icon, you instantly feel a sense of separation from your everyday browsing. That mental cue can help keep your work and personal habits distinct, especially for people who live in a work-from‑home environment and need to mentally “switch off” after a day.
In short, duplicating Safari is more than just a novelty. It creates two independent workspaces that protect each other from crashes, provide dedicated settings, and allow you to keep separate bookmarks or extensions. The next sections walk you through setting this up step by step and explain how you can apply the same technique to other macOS apps.
Getting Your Mac Ready for the Duplication Process
Before you touch any system files, it’s wise to ensure your macOS installation is in a good state. Duplicating an app touches the application bundle and changes system metadata, so you’ll want to make sure you’re not running an unrepaired system or that you have recent backups.
Start by opening System Settings (or System Preferences on older macOS versions) and verifying that your system is up to date. A recent OS release often patches bugs that could interfere with app bundles. Once you confirm you’re on the latest macOS version available for your machine, open Terminal from Applications → Utilities or search for it via Spotlight.
In Terminal, run the following command to check the health of the filesystem. macOS uses a built‑in journaling system called APFS, but running a quick diskutil verifyVolume / helps catch any disk‑level issues that might surface when copying large bundles.
diskutil verifyVolume /
If the verification completes without errors, you’re ready to move on. If it reports errors, run diskutil repairVolume / or consider booting into Recovery Mode and running Disk Utility for a deeper repair.
Next, create a dedicated folder inside your home directory to store the duplicate application. This step isn’t mandatory, but it keeps your Apps folder tidy and ensures you can locate the duplicate quickly. Open Terminal again and type:
mkdir ~/Desktop/Safari‑Dups
Now you’re prepared to copy the Safari bundle. The next section will walk you through the duplication process using command‑line tools that preserve resource forks and metadata.
Duplicating Safari Using the Terminal
Apple’s Safari application resides in /Applications/Safari.app. The application bundle is a package containing executables, libraries, resources, and configuration files. To duplicate it, we’ll use the ditto command, which is designed to copy directories while preserving extended attributes and resource forks.
Open Terminal and navigate to the Applications folder:
cd /Applications
Use ditto to create an identical copy called Safari2.app. This command will recursively copy the entire bundle and all its metadata:
sudo ditto Safari.app Safari2.app
macOS will prompt for your administrator password. After the copy completes, you should see Safari2.app in the Applications folder.
The next step is to rename the internal executable. The Safari bundle contains an executable called Safari inside Contents/MacOS. Duplicate Safari needs its own executable name to avoid confusion when the system launches it. Navigate into the new bundle:
cd Safari2.app/Contents/MacOS
Rename the executable:
sudo mv Safari Safari2
With the rename complete, the duplicate app is now ready to launch. Open Finder, locate Safari2.app, and double‑click it. The first time you launch it, macOS may warn you that the application is from an unidentified developer. Because it’s a copy of a system app, you can safely allow it by clicking Open in the dialog. Safari2 will start and appear in the Dock as a separate icon.
By default, Safari2 shares the same preferences and bookmarks as the original Safari because both applications use the same bundle identifier. The next step involves changing that identifier and related strings to create truly independent user data.
Fine‑Tuning the Duplicate for Independent Preferences
macOS stores an application’s preferences in First, open Safari2’s ~/Library/Preferences under a file named after the bundle identifier. Safari uses com.apple.Safari.plist. To give Safari2 its own preferences file, we must change the bundle identifier and related properties inside its Info.plist
Info.plist in a text editor. You can use nano for simplicity:sudo nano Safari2.app/Contents/Info.plist
Within the file, locate the following key-value pair:
<key>CFBundleIdentifier</key>
<string>com.apple.Safari</string>
Change the string value to a new identifier. A common convention is to append a number to the original identifier, such as:
<key>CFBundleIdentifier</key>
<string>com.apple.Safari2</string>
Next, search for any other occurrences of “Safari” that refer to the executable or app name. Typical changes include:
<key>CFBundleExecutable</key>
<string>Safari2</string><key>CFBundleName</key>
<string>Safari2</string>
Be careful to preserve the surrounding XML structure. If you’re unsure whether a string is part of a path, you can leave it unchanged. Once you finish editing, press Control‑O to write the file and Control‑X to exit.
Now, when you launch Safari2, it will look for preferences under com.apple.Safari2.plist instead of com.apple.Safari.plist. Because that file doesn’t exist yet, Safari2 will create a fresh set of default preferences. You can then adjust settings - such as the default search engine, homepage, or tab behavior - without affecting the original Safari.
One nuance to be aware of is Safari’s default homepage. The homepage setting is stored in ~/Library/Preferences/com.apple.internetconfig.plist rather than the app’s own plist. Since this file is shared across all Safari instances, both browsers will start at the same homepage unless you manually edit that file. To keep them distinct, open the file in a text editor and change the DefaultSearchEngine or HomePage key accordingly. Alternatively, you can ignore this and simply change the homepage via Safari’s preferences each time you open it; Safari writes the setting back to com.apple.internetconfig.plist after you close the window.
Another benefit of having a unique bundle identifier is that Safari2 will maintain its own cookie store and cache, stored under ~/Library/Caches/com.apple.Safari2 and ~/Library/Cookies/Safari2/. That means cookies from one instance do not leak into the other, ensuring a clean separation of sessions.
To confirm the duplicate is fully independent, open Safari2, navigate to Safari → Preferences, and change a setting such as “Always open new windows in tabs.” Then close Safari2 and reopen it. The setting should persist, confirming that Safari2 uses its own preferences file. Open the original Safari and verify its settings remain unchanged.
Practical Uses Beyond Safari
While duplicating Safari is a common starting point, the same technique applies to any macOS application that relies on bundle identifiers to locate user data. Developers who maintain separate test and production versions of an app, or users who need distinct accounts for email or social media, can use this approach to run multiple instances side by side.
For example, to run two instances of Mail with separate accounts, copy /Applications/Mail.app to Mail2.app, rename the executable inside, and edit Info.plist to use a different bundle identifier like com.apple.Mail2. Launch both Mail apps; each will store its mailbox data under a separate directory in ~/Library/Mail/. This can be especially handy when you need to keep a work mailbox separate from a personal one while troubleshooting connectivity issues.
Another case is using two instances of Terminal or iTerm2 to isolate different SSH sessions. While Terminal can open multiple windows, each session shares the same configuration file. By duplicating Terminal, you can maintain separate shell profiles, aliases, and SSH keys for different environments. After duplicating, you can change the When working with web applications that store session data in local storage or IndexedDB, launching a second Safari instance gives you a clean slate. Browsers treat each instance as a separate origin, so you can log into the same site with two different accounts simultaneously - ideal for testing authentication flows or debugging cross‑site scripting vulnerabilities. Keep in mind that not every application supports duplication smoothly. Some apps embed strict checks for their bundle identifier, preventing a duplicate from launching. Others rely on hardware‑specific files or serial numbers, which may not copy correctly. If you encounter such limitations, consider using macOS’s built‑in virtualization or sandboxing features to isolate apps instead of duplicating them. In conclusion, duplicating Safari - or any macOS app - opens up a flexible environment for users who need parallel instances with distinct settings. By following the steps outlined above, you can create separate browsers, mail clients, terminals, or any other app you wish to run side by side without interfering with each other. This technique enhances workflow efficiency, protects against crashes, and grants you the freedom to experiment or manage multiple accounts with ease.CFBundleIdentifier to com.apple.Terminal2, and Terminal2 will read ~/Library/Preferences/com.apple.Terminal2.plist
No comments yet. Be the first to comment!