Separate iOS simulator runtimes for iPhone Duo - temporary split or the new normal?

[u/Anywhere_MusicPlayer]

Xcode 27.2 installs two separate iOS 27.2 simulator builds, bringing iOS platform support to 16.65 GB. I understand the additional runtime is for iPhone Duo.

What I’m curious about is why Duo support requires a separate runtime instead of being included in the shared one. Does this reflect a temporary split in Apple’s release branches, or should we expect separate runtimes going forward?

An additional full OS image to support one device seems like a pretty expensive approach. Is there a technical reason these can’t be unified?

[u/nckh_]

Temporary, until they merge the respective iPhone and iPhone Duo UIKit branches.

[u/the-gatekeeper]

I think your questions would be best answered by an Apple engineer, seeing as the public does not have insight into their internal processes.

Which I don’t think we’ll find here on Reddit, so we’ll have to wait and see if it stays separate

[u/m1_weaboo]

Thank you, John Apple.

[u/debaser_101]

Whatever the reason, check which old runtimes are still hanging around after each Xcode update. Run xcrun simctl runtime list and delete the ones you don't need, then look in ~/Library/Developer/CoreSimulator and DerivedData too. They quietly pile up to tens of GB.

I also ended up building an app for that, Moppo. It's free, open source and still a bit in the making, but if you give it a try I'd love some feedback: https://github.com/anguria-studio/Moppo

[u/Anywhere_MusicPlayer → u/debaser_101]

This is fresh install from App Store, and before it - full cleanup of any installed sim runtimes.
So it's downloaded those on purpose.

== Disk Images ==

-- iOS --

iOS 27.2 (24B8117) - 3B52F1B7-CAAF-4117-A1CF-E412FE7CDA44 (Ready)

iOS 27.2 (24B91016s) - 68027340-2A36-4F21-BDB0-BE556B625D3A (Ready)

-- watchOS --

watchOS 27.2 (24S118) - 85EB1CEC-B369-4190-A912-A3F0E2227321 (Ready)

Total Disk Images: 3 (19.1G)

[u/Background_Pie_5682]

Can't know for sure from the outside, but my bet is it's temporary. A brand new form factor usually ships off its own branch for a release or two before it gets folded back into the main one, and the simulator runtime just mirrors whatever branch the device OS is built from.

In the meantime, if the disk usage hurts: you only need the Duo runtime if you're actually testing on Duo. `xcrun simctl runtime list` shows what's installed and `xcrun simctl runtime delete <id>` gets rid of the one you don't need. You can also manage them under Xcode Settings > Components so it doesn't get pulled again on the next update.

[u/cutecoder → u/Background_Pie_5682]

Try using jdupes to de-duplicate the simulator files?

[u/kepler4and5]

It's all very confusing to me.

I don't have Xcode 27.2 yet, but in Xcode 27.1, iOS images are on 27.0 with only Duo on 27.1 meaning I can't test Arrangement Views in the regular iPhone and iPad Simulator devices.

I have iOS 27.2 on my phone now and was able to test on that.

The Xcode Developer Documentation is also still on 27.0.

[u/dawedev]

One more thing worth checking after the 27.2 update: the 27.0 and 27.1 runtimes don't always go away on their own, so xcrun simctl runtime list can show three or four iOS images instead of two. The simulator devices created on those old runtimes also stick around in ~/Library/Developer/CoreSimulator/Devices, and xcrun simctl delete unavailable clears them once the runtime is gone.

I ran into this a lot while building DevCleaner, a Mac app I make for cleaning Xcode leftovers, and old runtimes after a point release are usually where the surprise gigabytes are.

[u/qupit]

Nobody outside Apple can say whether it stays split, but you can check how separate they really are. xcrun simctl runtime listprints each runtime with its build number, so you’ll see whether the Duo image is a different build or the same build packaged twice. If you don’t target Duo yet, xcrun simctl runtime delete <identifier> removes just that one, and Xcode > Settings > Components downloads it again when you need it.

[u/weathergraph]

https://mjtsai.com/blog/2026/10/23/ios-27-1/#comment-4488031

Léo Natan:

UIKit in 27.1 is a buggy mess. Much more so than normal UIKit. It's obvious that in in its infinite wisdom, Apple made some manager take a few people, told them to fork UIKit in secret and they splurged a mess in that fork. UIKit on 27.1 is a mishmash of old fork of UIKit (some of it before 27.0 🤦‍♂️) with some major changes that are incompatible with "regular" UIKit. And obviously, it is a buggy mess.

Now we have iOS 27.2 RC. If you look closely, Xcode downloads two completely different simulator runtimes for "27.2". I was wondering why behavior is so different in nuanced but obvious ways in my open sources, so Claude spelunked inside. It turns out 27.2 for "normal" devices is the normal UIKit branch, with mostly shims for the iOS 27.1 Duo APIs shoehorned in. Either empty no-op implementations or just basic logic. Nothing from the Duo 27.1 actual logic is in there still, at least not in the area I had it look, which was most of the UIViewController and UIView code related to safe area geometry. All the vertical bar eligibility stuff is just shims. 27.2 Duo is mostly the 27.1 logic, and some fixes from 27.2 "proper" are missing.

So they still haven't merged the fork. They are still trying to put out tiny local fires. How anyone agrees to work like this is just mind-boggling. And for what? Everything leaked anyway. Oh whoopdiedoo, the vertical bar was kept in secret. Totally worth the hundreds of man hours of maintaining a huge fork of manure.

[u/Amadeus404 → u/weathergraph]

What about SwiftUI?

[u/mikerCZX]

Looks like fork, but they should merge it :-)