The Good, the Bad, and the Unexpected

Replacing a development machine sounds simple enough: install your tools, copy your projects, sign in to your accounts, and get back to work.

In reality, moving a developer workstation from one MacBook to another is a little more involved. Especially when your setup includes Android, iOS, Kotlin Multiplatform, Unity, multiple signing identities, and a collection of tools that have quietly accumulated over the years.

I recently replaced my MacBook Air with another one featuring almost identical hardware, with one important difference: the SSD went from 256 GB to 1 TB.

The old machine was perfectly capable of doing the job. Storage was the problem. After spending quite some time cleaning caches, moving projects around, and trying to keep everything below the 256 GB limit, I decided that it was time for an upgrade.

This is what I learned during the migration.

1. Start with a list, not with a fresh installation

Before touching the new machine, make an inventory of what actually makes up your development environment.

My setup includes:

• IntelliJ IDEA Ultimate
• Kotlin and Compose Multiplatform
• Android SDK and Gradle
• Xcode and iOS development tools
• Unity 6.3 LTS
• Google Drive and iCloud Drive
• Homebrew and various command-line utilities

There are also credentials, signing keys, configuration files, and project-specific settings that are easy to forget.

The important distinction is between installing software and migrating your development environment. Installing an IDE is easy. Getting it to build and sign your existing projects exactly as before is where the interesting part begins.

I chose to rebuild the environment manually rather than blindly cloning the old machine. It gave me an opportunity to leave behind old experiments, unused tools, and accumulated clutter.

2. Install the basic macOS tools

I started with the usual macOS setup:

• Install system updates.
• Sign in to the Apple Account.
• Configure the keyboard layout and function keys.
• Set up the external monitor.
• Install Homebrew.

Homebrew makes installing most development tools straightforward.

For example:

brew install git wget curl htop tmux

And applications:

brew install --cask google-chrome
brew install --cask intellij-idea
brew install --cask rider
brew install --cask unity-hub
brew install --cask google-drive

Xcode was installed separately through the Mac App Store.

One small but useful tip: configure function keys as standard F1–F12 keys if you use IntelliJ, Rider, or terminal-based tools regularly. It makes a difference when you’re used to a traditional developer keyboard.

3. Android and IntelliJ: surprisingly painless

This was probably the smoothest part of the migration.

I installed IntelliJ IDEA, let it configure the Android SDK, and opened my existing Kotlin projects.

The first builds exposed the expected missing configuration, but there was no need to migrate the entire Gradle environment.

The important files were:

• Android signing keystores
• gradle.properties
• Project-specific local.properties, if applicable

I copied the signing keys and gradle.properties from the old machine.

The local.properties file deserved a quick check because Android SDK paths are machine-specific. On macOS, the SDK is typically located under:

~/Library/Android/sdk

After checking the paths and letting Gradle download anything missing, both debug and release builds worked.

That was a good start.

Lesson learned: Don’t forget the signing keys. A project that builds successfully is not necessarily a project that can produce a properly signed release.

Also, keep your signing credentials backed up securely. They are much more important than most of the IDE configuration files.

4. Xcode: where things got interesting

iOS development was the first real migration headache.

I installed Xcode, signed in with my Apple Developer account, connected my physical iPad, and tried to install a debug build.

Instead of building, Xcode displayed this message:

Your account already has an Apple Development signing certificate for this machine, but its private key is not installed in your keychain.

This is a classic certificate-versus-private-key problem.

An Apple Development certificate is not the same thing as its private key. The certificate can exist in your Apple Developer account, but without the corresponding private key in your macOS Keychain, Xcode cannot use it to sign applications.

Exporting certificates from the old Mac

The solution was to go back to the old Mac.

1. Open Keychain Access.
2. Select the login keychain.
3. Open My Certificates.
4. Find the Apple Development certificate.
5. Expand it and verify that its private key is present.
6. Export the certificate and private key as a .p12 file.
7. Protect the export with a password.

I did the same for the Apple Distribution certificate, since there was no reason to leave that one behind either.

Then I imported both .p12 files into the new Mac’s Keychain.

The unexpected duplicate certificate

During its first startup, Xcode had already created a new Apple Development certificate.

After importing the old certificate, I had two Development certificates:

• The original one, associated with my old developer identity.
• A newly generated one, associated with my current account name.

Both were visible in Keychain Access and in Xcode’s Manage Certificates screen.

Initially, this looked like a problem. It wasn’t.

The important thing was to make sure the original certificate had its corresponding private key and that Xcode could use it.

I removed the unnecessary local November certificate from Keychain Access, but did not revoke it in the Apple Developer portal. Revoking a certificate is a different operation: it invalidates it at the account level and can affect other machines or build environments.

The new certificate was also visible in the Apple Developer portal. That was expected: Xcode had registered it with Apple’s servers. Its private key, however, remained local to the Mac.

After sorting out the certificates, Xcode downloaded the correct signing certificate and successfully installed the debug application on my physical iPad.

Lesson learned: Export your Apple Development and Apple Distribution certificates as .p12 files before replacing your Mac. Do not rely on Xcode recreating them. And don’t revoke certificates just because you see duplicates.

5. Provisioning profiles and physical devices

Certificates are only part of the iOS signing process.

Provisioning profiles also matter. They connect your application identifier, signing certificate, and allowed devices or distribution method.

If you use automatic signing, Xcode can usually manage these for you. If you use manual signing, make sure the provisioning profile references the certificate you actually want to use.

I also prefer testing on a physical iPad rather than maintaining a collection of simulator runtimes.

For my workflow, the simulator is not essential:

• I use a physical iPad for development and testing.
• iPhone testing is handled through TestFlight.
• I don’t need to download multiple iOS Simulator runtimes just to get started.

One important distinction: the iOS SDK is required for building iOS applications. Simulator runtimes are optional if you don’t use the simulator.

6. Unity

Unity was the next major component.

I installed Unity Hub and Unity 6.3 LTS, including the modules required by my projects:

• Android Build Support
• iOS Build Support
• WebGL Build Support

The project itself was approximately 3 GB, so I transferred it to the same location:

~/UnityProjects

The first project opening may take a while because Unity needs to import assets and rebuild its local cache, but otherwise it was seamless.

7. Don’t migrate everything

One of the benefits of doing a manual migration is that you can decide what not to bring over.

I didn’t want to migrate years of caches, temporary files, obsolete tools, and abandoned experiments.

Some examples:

• Gradle caches can be regenerated.
• Xcode DerivedData can be regenerated.
• Unity Library can be rebuilt.
• Homebrew packages can be reinstalled.
• IDE caches can be regenerated.

On the other hand, these are worth preserving:

• Signing keys and certificates
• SSH private keys
• Project-specific configuration
• Cloud credentials
• Important IDE settings
• Custom scripts and shell configuration

The general rule is simple: migrate valuable state, regenerate disposable state.

8. The 1 TB SSD changes the workflow

The original MacBook Air had a 256 GB SSD.

That sounds reasonable until you start combining:

• Android SDKs and Gradle caches
• Xcode and its build artifacts
• Unity projects and asset libraries
• IDE installations and indexes
• Docker images and development environments

I spent far too much time cleaning up storage.

The new machine has 1 TB of SSD storage, which changes the equation considerably.

I no longer need to aggressively delete caches or move every large directory somewhere else. I can keep the tools and projects locally and let them work as intended.

That doesn’t mean storage management becomes irrelevant, but it removes a lot of unnecessary friction.

---

Final thoughts

The migration was not particularly difficult, but it was a good reminder that a development environment is more than a collection of installed applications. Android and IntelliJ were almost plug-and-play once I copied the signing keys and Gradle configuration.

Xcode required more attention because certificates and private keys are separate things, and its automatic signing setup created an additional certificate before I had imported the original one.

The biggest takeaway is this:

Before replacing a development Mac, make a proper backup of your signing identities and important configuration files. Everything else can usually be reinstalled or regenerated.

And if your only problem with an otherwise perfectly capable MacBook is a 256 GB SSD, upgrading to 1 TB may save you a surprising amount of time, and frustration.