Can I install Xcode on an external hard drive along with the iPhone Simulator.app?

Question

I want to install xcode to deploy a cross platform flutter application but I cant find enough space for Xcode is there any alternative solutions to just installing it on the internal storage

Solution 1

---

PLEASE READ THIS FIRST!

Currently, this answer is only valid for systems that runs:

XCode <= v.11.3 running macOS <= v.10.15.2

Why? (Short Version):

With XCode 11.3.x, Apple activated a few (until now) dormant checks in /usr/lib/libxcselect.dylib that enabled checking if the developer tools is located on a read-only / immutable system partition guarded by SIP and gets triggered when you do a xcode-select -s directory switch attempt.

The 11.x "Big Sur" macOS versions, locked it down much harder still, because of things like this. Moving system related files, or even booting from external drives won't work, because the new "encryption seal", part of the new SSV (Signed System Volume) refuses to boot or run select programs if the hash is altered (files in / out etc).

I have not yet found a way to work around these checks. I take no responsibility for broken systems after using this method, and if you choose to tinker with a newer version of XCode / macOS, please take a full backup first! Good Luck!

---

Installing Xcode, Simulators and Other Tools to External Storage

As mentioned in the comments, if you already have Xcode installed the process is quite simple. Start by copying Xcode from the Internal HD to an External drive, rename the original and run the commands from step 4 & 5, and this should do the trick. If so, delete the original (now renamed) directory / app bundle.

My experience is that if you don't have Xcode already, the process is a bit more involved.

There may be simpler ways to do this, but after getting different errors for every thing I've tried, I've done it this way on a MacBook Pro 16" running macOS Catalina (10.15.2) and Xcode 11.3:

I have my external drive attached to the MacBook at all times, using a bit of Velcro as the Samsung T5 drive I use is so small and light. It's mounted at:
/Volumes/SSD

On the external drive I've copied Xcode into:
/Volumes/SSD/Applications

Follow this procedure for installing Xcode:

1. Download the latest 11.3 Xcode release (not the Beta) from Apple's Developer Site (This is a 7.3GB Download and you need to register for a free developer account by the way)
   

2. Install the Xcode command-line tools (to the internal drive), which can be triggered by running the following command in a terminal: sudo xcode-select --install
   This will trigger the installation of the command-line tools and establish the /Library/Developer/CommandLineTools path and set this as the default developer tools path after installation.
   

3. Now, the Xcode download comes as a .xip file that needs to be expanded / unpacked using the Archive Utility included with macOS.
   I've already created a directory on the SSD:
   /Volumes/SSD/Applications
   and moved the Xcode_11_3.xip file here before extracting it by double- clicking it in the Finder.
   NOTE: It will unpack to the same folder as the .xip file, into Xcode.app but leaves the 7.3GB .xip file there as well. After unpacking, you may move the .xip file somewhere for backup or just delete it.
   

4. Now change the default developer tools directory with command:
   sudo xcode-select -s /Volumes/SSD/Applications/Xcode.app/Contents/Developer
   then do another zsh -lor restart the Terminal.app.
   

5. After setting the Xcode.app as the default developer tools directory, run this command, to have Xcode figure itself out:
   /usr/bin/xcrun --find xcodebuild
   
   This took a little while, then I got back:
   /Volumes/SSD/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild
   

Moving The Simulators / Emulators

The simulators, caches and all that also takes up a considerable amount of space but lives elsewhere.
For Xcode, the simulators are normally located within:
~/Library/Developer/CoreSimulator

You'll want to move this whole directory structure to your external drive if you're looking to maximize the available space on the local drive. You can use a regular move operation via Finder.app by first doing a regular ⌘ + C (cmd+c) to copy ~/Library/Developer/CoreSimulator then in the target location, You can use ⌥ + ⌘ + V (opt+cmd+v) to move the copied contents directly (might require admin password).

I use /Volumes/SSD/Library/Developer/

Just had to mention this as many don't know how to properly "cut and paste" files in the Finder, ending up copying first then going back to delete... :)

Now make a symlink using:

ln -s /Volumes/SSD/Library/Developer/CoreSimulator /Users/<your_user>/Library/Developer

You should now be able to use and update the simulators as usual. First time run may throw an error, but subsequent runs should be fine. Sometimes a reboot might be a good thing as well...

The Android emulators are by default located somewhere beneath ~/.android/
Use the same procedure as for the Xcode simulators to move the whole ~/.android directory to a place on your external drive and symlink as described, so you end up with something like:

.android -> /Volumes/SSD/Library/android

when you do a $ ls -la ~ in your Terminal.

Note For Homebrew Users

If you're using Homebrew for installing packages (like many does), it seems as if Homebrew won't register that you have the CommandLineTools installed if you move the /Library/Developer/CommandLineTools directory, and will try to compile some bottles from source.
Homebrew apparently needs some tools found in the separate Command Line Tools package installed with sudo xcode-select --install that's missing from the regular Xcode install (I noticed this when upgrading to a new version of Python, it was still being compiled from source no matter what I tried.)
So, if you use Homebrew, you're probably better off keeping the Command Line Tools installed at the default location. Just install as described with the sudo xcode-select --install command and leave it there, it's not taking up much space anyway.

IMPORTANT, remember to accept the xcodebuild licenses before using a tool that depends on it, using a command like this (with your own path):

sudo /Volumes/SSD/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -license accept

or in cases where the developer tools are already detected and found on an external drive, and the path has been set by XCode:

sudo xcodebuild -license accept should do the trick.

As I said, there might be simpler solutions out there, but after doing it this way I've been able to use Homebrew without errors and Xcode + tools with MacOS, iOS and Flutter frameworks.

Also, I've created an alias to the Xcode.app in /Applications to have it conveniently placed together with the other apps. (Cmd + Opt drag the Xcode.app to /Applications in Finder). Saved myself a ton of space on the internal drive this way.

---

In response to questions in the comments:

Can I upgrade Xcode / Simulators after using this method?

As long as you create a good old "alias" from the external drive's Xcode.app to /Applications/Xcode.app by dragging the app while holding ⌥ + ⌘, I've not had any problems updating, BUT I upgrade by downloading from the Apple Developer Site, not through macOS AppStore, as I've noticed that the AppStore doesn't accept the alias and thinks that Xcode isn't installed.

---

Updates regarding Xcode Versions > 11.3

As I mentioned in the top of the answer, I can't vouch for this answer if you're using an Xcode version higher than 11.3.

I've gone through all the steps using a fresh install on a new machine.

I experienced a couple of showstoppers while trying to figure this one out, and I only had limited time to spare for doing this. The problems were a bit more involved than expected.

TODO:
✅ Disk arrived today (Tue, Sep 8)
✅ Install macOS, Xcode, Android SDK and Flutter SDK dev files
✅ Move Flutter SDK, Android SDK and Android emulator to external SSD
✅ Move iOS Simulator files to external SSD
[🛑] FAILED: Move Xcode and Platform files to external SSD
✅ Adapt Zsh environment variables / scripts to reflect the changes

---

It appears that those who have SIP enabled (probably most users) will get in trouble when accessing tools from within the Xcode app bundle if it's moved outside the internal drive.

You may think that, "hey, I have my tools in /usr/bin or somewhere else, but the problem is that these files are merely shim binaries, which use a system library to resolve a path to a Developer directory, where all the actual executable files, libraries and support files are installed.

This complicates matters further as you now no longer even know which of these files are in actual use. Just try doing:

$ otool -L /usr/bin/xcrun
# or
$ otool -L /usr/bin/xcode-select

And see what pours out... Same goes for most of the tools.

If you disassemble /usr/lib/libxcselect.dylib (is that allowed? 👀) there's apparently some additional checks being performed when running Xcode after version 11.3.

I went back and checked and the configuration have had these tests available for a few versions, but they haven't been activated in previous consumer builds.

So when a directory switch is attempted as described in my original answer, the libxcselect tool will now perform at least one (in)sanity check to ensure that Xcode and its tools are run from internal (safe) storage, which has an immutable system configuration guarded by SIP. System Integrity Protection, so, you can't just move or delete it.

My guess is that you'll have to disable SIP to be able to make this work, and that is not an acceptable solution, as it opens up for lots of security and stability issues (even worse performance).

Finding a Middle Ground

Problem: How to free up space on an internal drive, by moving developer files to an external drive.
I've tried pretty much everything I can think of regarding the moving Xcode part, but I've met new roadblocks and showstoppers no matter what.

SO. I had to throw in the towel on this one, finding a compromise. I can live with having saved approximately 50GB of space on my MacBook Pro's internal 256GB NVMe drive.

I had no trouble moving: ~/Library/Android/* (The whole Android SDK directory) ~/.android/* (Caches and .avd emulator image files)

Using nothing but symbolic links, after copying the contents and deleting the originals. This is only interesting for those who develop using the Android SDK and tools, so sadly I wasn't able to solve this madness caused by Apple's restrictive new policy regarding executable files in "foreign, hostile" locations.
These two directories alone saved me a fair share of space, so I guess for the time being that's about it.

I've tried moving some parts of the Xcode bundle out of the app bundle with varying degree of success, but as you can see in this screenshot:

The bulk of the Xcode.app is within the "Platforms" directory, and when I start messing with those files, the build tools blows up on me, but sometimes not, so I really don't know.

The Simulator files themselves are possible to move, and this will save you anything between a few gigabytes to plenty of GBs depending on how many platforms (iOS / iPadOS etc.) versions you use.

These are located inside: ~/Library/Developer/CoreSimulator I've been able to move this whole CoreSimulator directory without too much trouble using symlinks as explained in the original answer.

I will continue trying to figure this one out, but right now, this is where it's at.

---

Solution 2

I just installed Xcode 12.3 to /Applications then copied the .app to my external drive, then deleted the original. After that:

ln -s /Volumes/ExternalSSD/Applications/Xcode.app /Applications/Xcode.app

It took a while to launch for the first time, but subsequently it's now fine. MacOS 11.1, M1 2020 Air.

(No need to clone the OS or boot off your external drive, like the other posts suggest).

Solution 3

I found out a simpler solution. Create a new user on your Mac. Give administrator privileges(optional), set the home directory of the user account you just created to be an external hard drive. Then login to the new user and install Xcode at ~/Applications directory not /Applications. Then Xcode is installed on your external ssd. No problems using it so far for me! Hope it helps.

Edit: I forgot to mention I should download Xcode from developers website. Haven’t tried downloading from App Store.

Solution 4

As an alternative to just moving XCode to an external drive you could also clone your mac disc and move the whole operating system onto your external drive and make it bootable.

Things you need:

• A large, fast external SSD, such as the Samsung X5 Thunderbolt 3 drive.
• A Mac disk cloner (e.g. Carbon Copy Cloner beta for Big Sur, or SuperDuper!)

Install the cloning software, follow the instructions and you'll have a bootable external drive in less than an hour (depending on what you are cloning)

You now have a portable development disk which can be plugged in and booted from the same mac. Booting from other macs may not work as cseder suggest in the comments.

On first boot and usage of XCode, the Apple OS will perform some verification of apps, but once that is done you should be fine.

I have a 2018 mac-mini running Big Sur with only 128GB internal SSD. Every time I needed to upgrade XCode I had to delete all the simulators. Upgrading to Big Sur was even harder :-/

Performance?

The external drive (Samsung T5) is 3x quicker to write to than the cheap internal SSD that Apple use on the mac-mini. Read speeds are about the same according to BlackMagic. Overall, Flutter app builds on the external drive are about 10% quicker.

Solution 5

@cseder you're a life saver!

Btw, If you are getting issues or takes a long long time in Mac Catalina to verify while doing step 5 /usr/bin/xcrun --find xcodebuild just:

1. Turn off the computer
2. Turn on, and quick enter in Secure mode (Press CMD + R multiple times)
3. Login to your account and open the terminal once Secure mode is on
4. Run this command csrutil disable <- will disable the verification of software download from the internet
5. Run sudo reboot

And then you can open Xcode directly without doing any /usr/bin/xcrun --find xcodebuild

Note after you are able to run Xcode then make sure to Turn Off again and enable csrutil enable in secure mode.

View more solutions

Comments

[Djiveradjane Canessane]

I created a question here, if you want and have the time to give a detailed response: stackoverflow.com/questions/61370082/…

[user185887]

Just to get a confirmation, cause it is not really clear to me, if I install any other dependencies for XCode (as an analogy to Python, we install packages via pip, similar to that in XCode. I don't really have a concrete idea about what it will be called, because I am a beginner developer), will they be stored in my External Drive or Internal SSD?

[C. Sederqvist]

Sorry for the late response. I've been very busy lately. Answer : Yes. I told you multiple times that I do this and have been doing this for at least a year. If you follow my post regarding this you should ger up and running in no time!

[Kasra]

Dear @cseder . I did not understand your note about Homebrew. Can you explain more?

[Kasra]

I have a few questions: 1. Does this method also move the simulators as well? 2. When we move Xcode, can we update Xcode in the future?

[C. Sederqvist]

@Kasra : No, the simulators, caches and all that lives elsewhere. For Xcode, the simulators are normally located at ~/Library/Developer directory. Just move this whole directory structure to your /Volumes/<ext_drive_name>/[some_folder_name]. I use /Volumes/SSD/Library/Developer. Now make a symlink using ln -s /Volumes/SSD/Library/Developer /Users/<your_user>/Library/ and you should be able to use and update the simulators as usual. Same procedure for Android, just use the ~/.android directory instead.

[C. Sederqvist]

@Kasra : Forgot to mention that you might have to prepend a sudo to the command, but I think that's just if you use a terminal for moving the ~/Library/Developer directory. Because of additional attributes and ownership on some of the files, you're actually better off just using the Finder for the move and confirm with a system admin password when prompted. If unsure, just copy the directory first, rename the original ~/Library/Developer and create the symlink. This should work just fine.

[C. Sederqvist]

I've updated the main post to cover most of the questions asked in the comments. If anything else is still unclear, just ask in the comments, and I'll add it to the main answer if it's important for making things work!

[C. Sederqvist]

@Kasra Did this clear things up or are there still some stuff you find hazy? Did you manage to set up a working config? English isn't my primary language, so sometimes I choose poor words for describing things, but I do want to improve the readableness of what I write, so please, constructive criticism is always welcome!

[RogerTheShrubber]

I've found after moving the Developer directory to an external drive, whenever I try to build I get an error: "Failed to find or create execution context for description..." Exactly the same as this issue: apple.stackexchange.com/questions/372010/… Any ideas?

[C. Sederqvist]

Hi. I think "lifesaver" is a bit extreme, but thanks! You shouldn't have to disable SIP to get this working. I think you have to troubleshoot why, because this is really nothing that should require that you do that, as the same things gets loaded as when running Xcode from the local drive.

[C. Sederqvist]

@RogerTheShrubber Have you tried to keep the command line package installed as is by default, like I described for using brew? It takes only a few hundred megs.. Try installing it and keep it under /Library/Developer and after that run the xcrun command again. See if that works. I can't reproduce this myself, so hard to say why you're having trouble. What mount options are listed for the external drive by the way? Just run 'mount' without arguments to see. Might be a mount option that's missing. Also, you use APFS on the external drive right?

[tapizquent]

I did all the steps here, but after moving Xcode, my simulators do not work. They launch with the app, but do not load the OS, they just stay with a black screen. Anyone know why this might be?

[RogerTheShrubber]

@cseder Yeah, I actually never moved the command line utils because they were small and you had suggested that moving them might be problematic. I wasn't clear in my comment which dev folder I meant. So /Library/Developer is still in place, but when I move ~/Library/Developer to an external drive and put a symlink in it's place I get that error. If I browse it via the Finder or Terminal, everything looks like the symlink is working as expected, but Xcode (both the current shipping version and the newest Beta) freaks out with every build.

[C. Sederqvist]

Have you tried to use an alias in place of the symlink? Might be worth a shot. It can be done from within Finder holding cmd + option while dragging the source folder to the destination. Just curious, do you use FileVault on this Mac? Let me know how it goes! I'm going to install a new external drive next week on a machine with a fresh macOS install and the latest Xcode (local) install, so I'll document the process and make sure to note any problems, and update the main answer if something isn't working.

[C. Sederqvist]

Please see my edit in the top section of my main answer regarding the problems using the latest version(s) of Xcode and macOS Catalina.

[Patrick Sebastien]

Also looking forward to this - having the same issues as @JoseTapizquent with the simulators.

[C. Sederqvist]

You're actually right about the Xcode and SIP connection. I'm trying to figure out if it is at all possible to run Xcode and accompanying tools + tools that depend on those without disabling SIP, as that isn't really a solution in the long run... See my update for more...

[C. Sederqvist]

Disabling SIP will cause some checks to be ignored, letting you run Xcode from other locations than your system drive, but it also opens up for a slew of malicious programs to have a feast on your operating system, so doing this should ONLY be done temporarily as a last resort for solving problems.

[Limpuls]

@PatrickSebastien I as well have a problem with black simulator screen. Do I need to move simulator files to external drive too? Have you guys done that?

[Harsh Mehta]

Getting the same error as @JoseTapizquent. I cannot run my simulator. I can't find the Library/Developer/CoreSimulator folder either.

[C. Sederqvist]

@HarshMehta it's ~/Library/Developer/CoreSimulator

[C. Sederqvist]

Note that my comments dating from before the post was updated regarding Xcode version > 11.3 (before September 29th) should not be considered correct for the obvious reasons. Also the simulator directory is the one to symlink, not the whole Developer directory.

[C. Sederqvist]

@Limpuls Try re-installing the simulators in Xcode AFTER you've symlinked the CoreSimulator directory.

[Limpuls]

@cseder I'm not sure I'm doing it correctly. I delete CoreSimulator directory from /Developer but when I relaunch Xcodes I still have the list of iOS devices in the menu. How do I reinstall them properly?

[C. Sederqvist]

@Limpuls What version of Xcode is this? In Xcode -> Preferences -> Components, do you have a separate tab for Toolchains? If so, you've installed alternative toolchains / simulators. They will probably live inside ~/Library/Developer/Toolchains/ and can be uninstalled from Xcode (right-click -> Action Menu -> Move to Trash) or just deleted from the mentioned location.

[C. Sederqvist]

I don't think this would work for modern MacBook Pro or other mac models with the T2+ security chip. Also you'd have to enable the option to boot from external drives and disable the os verification checking in the startup options while you're in recovery mode.

[multitudes]

I did the same and it works fine with a fast ssd. Make sure to download it from the developer website and copy the zipped files to the ssd, then unzip it. :j

[DeveloperSammy]

Hmmm, this might be the best option for me. Will try it out and report back!

[DeveloperSammy]

Noob Question, how to get the corrects paths for de symlink ? And will this move all developer files to the external drive? Including Simulators?

[rsa]

I installed Xcode 12.0.1 using this solution. My first iteration failed due to a ton of errors when running cpio. I'm pretty sure it was due to my hard drive not being formatted to HFS or APFS. Once I reformatted my drive to APFS and repeated, it worked. I created a symlink in /Applications and also ran xcode-select to the new path. A bit slow on my 2012 MacBook Pro, but works! Attempting on the new XCode 12.3 now. Thank you!

[BSUK]

Hi @DeveloperSammy, you can drag files or folders into the terminal window for quick and easy "typing" of the path. After seeing your reply, I also moved the simulators using the same method: ln -s /Volumes/ExternalSSD/Applications/Xcode\ Simulators/dyld /Users/bsuk/Library/Developer/CoreSimulator/Caches This saves another 10gb or so.

[Shyam]

@BSUK On an unrelated topic, hows the xcode performance with m1 chip? Is 256gb enough for mobile app development, or should i get 512gb version? Also, is 8GB RAM enough?

[BSUK]

I haven't had chance to use Xcode much yet, but in general this laptop is lightning fast, even with apps running under Rosetta "emulation" (re-compiled at first run of apps). The fact I can run real time audio applications with Rosetta (faster than my old Mac running them natively) is incredibly impressive. Apple silicon native apps are even faster too. Check compatibility for some niche apps or hardware, but in general, you're good to go. As Xcode is Apple Silicon native, I'd expect blazingly fast performance. Only you can answer the question about disk space, as it's a personal need.

[armand]

link is a dead link.

[armand]

I am running into this, as you did. Would you mind posting the full paths to the simulator your simlinked? I have about five different CoreSimulators folder for the different platforms. Aliased the IPhone at /Volumes/SSD/Applications/Xcode.app/Contents/Developer/Appli‌​cations/Simulator.ap‌​p then copied it to ~/Applications/Simulator.app. It shutdown immediately when I try to open it. Thanks.

[armand]

Figured it out. I had to open XCode since it was a fresh install. Once you do that and accept the license, clicking on the Aliased Simulator works. Should work just clicking on XCode but I did it through https://hacknicity.com/xclauncher since I was just reaching for something to make this work and remembered spending the $3 on this.

[ramz]

Ok, you were right, I've modified the link

[Robin Schmidt]

The OP asked for running Simulator.app from external drive too. Did you test this? You mentioned "Start Xcode w/o problems". Did you test building and running your project on the simulator, too?

[DeveloperSammy]

My simulators always end up under my user folder /libary/developer/CoreSimulator... Any ideas, it's driving me crazy

[C. Sederqvist]

This should not be possible if you use macOS > 10.15.2 with SIP enabled (as is the default) You may well be able to launch the app, but as soon as you need to build using the internal Xcode tool-chain this would blow up if those files have been moved away from the system volume's /Applications/Xcode location. The test is performed by libxcselect and if the tools are not in a safe / immutable system / SIP protected area, the checks fails and there is currently no way around it that I've found.

[C. Sederqvist]

Same as above: This should not be possible if you use macOS > 10.15.2 with SIP enabled (as is the default) You may well be able to launch the app, and probably because Cordova uses CocoaPods and Ruby to hook up various Ruby scripts into the process, you're able to bypass the SIP protected files. This is NOT the same as building a regular app using the Xcode Toolchain natively and IS NOT an answer to the OP's original question.

[C. Sederqvist]

You will not be able to build and sign native iOS or macOS apps using this method. Native apps are built by combining both Xcode projects (the native one and the one Unity generates) into a single Xcode workspace, then add the UnityFramework.framework file to the Embedded Binaries section of the Application target for the native Xcode project. When you try to build a signed release version, things will blow up if not before.

[C. Sederqvist]

> It was as ExFAT, which Xcode didn't like for some reason. SOME REASON: Because it depends on extended file-system attributes and permissions, which ExFAT knows nothing about.

[C. Sederqvist]

No, this is NOT possible using the latest versions of macOS and Xcode running on mac hardware. Big Sur won't boot from anything besides a APFS Signed System Volume "All the apps" as you say are totally irrelevant, because other apps ARE NOT GUARDED BY SIP. You could run those from an Amiga 500 Floppy drive if you wanted.

[C. Sederqvist]

Will NOT work using macOS versions > 11.x. Replicating an APFS volume group that includes a signed system volume and data volume will break, as It uses cryptographic hashes of all data and metadata in the file-system, as a seal so the replicated volume will be broken and the macOS UEFI boot routine will refuse boot from the volume.

[SoftWyer]

@cseder I'm running a standard install OSX 11.2.1 (20D74), it's booting fine off a cloned system drive with a Mac Mini, perhaps the constraint is not the version of OSX but rather the hardware?

[C. Sederqvist]

Regarding the problems that started with Xcode (enforcing of the "sanity checks" in the builds > 11.3) this makes no difference. The checks kicked in, and SIP doesn't care if you're "Admin". There is no longer a true root user accessible in the newer versions of the OS. Security chips on newer models, not affected by a user on the OS, UNLESS you kill SIP all together and copying every bit of information and extended attributes / permissions etc. But in 11.x even that doesn't cut it, The new "guarded system partition" encryption scheme makes the checks blow up no matter what. :(

[C. Sederqvist]

Yes. Also an important factor it seems. I was unsure about this because I only have an old iMac without the T1 / T2 security chip, there I can do pretty much what should have been possible still, to make my own calls. (old macOS High Sierra) But the newer Intel models sure ain't letting a cloned drive run as a system drive with the newer "immutable core" kinda partitioning where basically anything system related is read-only. Good for security, bad for tinkering. Guessing that the new ARM based models aren't very "tweaky" of nature either. Don't know.

[technolaaji]

I did something similar to my 128GB macbook pro where I bought a 512GB Pioneer M.2 SSD and a type C M.2 enclosure, it gives me around 950 MB/sec according to BlackMagic which is not bad but I had to download Xcode from the developer site (and linked Xcode using zsh by adding a link in my zshrc also worked out for me with Docker and WebStorm flawlessly)

[kode54]

It let me move it to an external SSD. Of course, this external SSD is an NVMe volume, and it's installed in a Thunderbolt enclosure, and for some reason, macOS doesn't consider it a removable drive. I was able to xcode-select -s a copy of Xcode.app on it just fine. Also, Xcode is not installed to read-only storage. Or at least, the .app bundle, the largest portion of the thing, is not. It's installed to the Data volume on most systems, which is a read-write overlay where all user modifiable state lives.

[C. Sederqvist]

> "It took a while to launch for the first time, but subsequently it's now fine. MacOS 11.1, M1 2020 Air." Interesting. Must behave differently on the M1 Architecture then.

[C. Sederqvist]

@kode54 All the executable are read-only shims, residing in a SIP protected area.

[C. Sederqvist]

/usr/lib /usr/libexec /usr/bin etc. Besides, if this is a new Mac with T2+ chip and macOS > 11, the checksum would change if you did anything to the files considered in the extended checks explained earlier.

[kode54]

Yes, and those shims are tiny. The bulk of Xcode is the /Applications/Xcode.app, which is over 33GB. You can move that to another partition. But, the App Store will lose its ability to update it.

[C. Sederqvist]

@kode54 have you even read what this answer is about? I'm telling you, you won't be able to do this on a NEWER as in Mac with T2 and newer security chips. An exception may seem to be if you have a brand new Mac with a M1 Arm CPU, but I don't own one so I can't confirm.Would I've gone through all this trouble if it "just works" like you claim? If so, good for you. Roger Out.

[C. Sederqvist]

@kode54 The Xcode.app is a container for Xcode specific files, and /Applications/Xcode.app/Contents/Developer is the place where most of the internals, the meat and potatoes of the macOS SDK lives, and these files are immutable for users and group wheelaka the admin user(s). If not or if they're moved, you won't be able to run xcodebuild and get a signed binary from an Xcode project. If you can do that, please provide proof.

[kode54]

And I am telling you, I literally shoved my Xcode.app on /Volumes/Massiv/Applications/, an APFS volume on a Thunderbolt attached drive, and it Just Works. Maybe the Thunderbolt and the fact that macOS doesn't register it as a removable drive matters? It may also have something to do with changing the boot options for my OS to "reduced" security, since I needed to do that to allow kext loading for things like MacFUSE and KBFS mounting to work.

[C. Sederqvist]

@kode54 Yes, that would make a difference. I actually missed the part about it being a TB drive. Is it a Samsung series TB3 drive? I've heard others say that the OS actually detects some TB disks as internal and if so, that makes all the difference, as this would be considered safe ground by the T2 chip, and probably works. I've heard others have no trouble doing this on an M1 ARM arch system, but some can't get it to work on Intel while others, the other way around... Go figure!

[C. Sederqvist]

As I mentioned as a response to another comment, there are cases where at least some brands, including Samsung TB3 external drives are actually detected as internal. If so, the checks are much less strict, and allowing both using it as a system drive or data drive. I know some spare parts and original drives are produced by Samsung, so that kinda makes sense, but I'm thinking this may be changed in a later OS update as per definition it is a bug to treat external storage as internal regardless of the connector / controller in use.

[Tanvirgeek]

What do you mean by this line: "Then login to the new user and install Xcode at ~/Applications directory not /Applications" ?

[sejn]

@C.Sederqvist While expanding the Xcode xip file, it not taking the external disk space. It takes the space of the internal disk already available in the machine. I have upto internal storage has 5GB, but the external device has upto 1TB.

[C. Sederqvist]

@sejn What are you trying to convey here? I don't understand this sentence: "While expanding the Xcode xip file, it not taking the external disk space. It takes the space of the internal disk already available in the machine. I have upto internal storage has 5GB, but the external device has upto 1TB"

[sejn]

I mean, I am trying to install the latest Xcode 13.2.1 on the machine. But it has less memory space. So tried to install the Xcode by downloading the xip using the external hard drive. But it failed to expand the xip file in the external drive. Any solution to expand the xip in the external drive?

[Gurzoni]

It's running nicely from the external hard drive, but I'm having issues to eject the disk, because the background task still using it. Anyone with that problem?

[abulka]

Just successfully installed Xcode_13.3.1 on my M1 Mac Mini (which only has 256GB internal storage) to an external drive using this technique. I downloaded the zip from developer.apple.com/download, expanded the zip directly to my external disk's Applications folder and double clicked on the resulting .xip which creates the final Xcode.app (delete the .xip). Then I created the symbolic link and ran xcode from the /Applications/Xcode.app alias. I can't believe it worked!

[andresmafra]

Thanks God for your comment my friend, you saved my life <3

[onurozcelik]

XCode v13.4 RC & Flutter v3.0.0 work like a charm. Thanks.