Xcode 26.1
Xcode 26.1 includes Swift 6.2.1 and SDKs for iOS 26.1, iPadOS 26.1, tvOS 26.1, macOS 26.1, and visionOS 26.1. Xcode 26.1 supports on-device debugging in iOS 15 and later, tvOS 15 and later, watchOS 8 and later, and visionOS. Xcode 26.1 requires a Mac running macOS Sequoia 15.6 or later.
It might be just me, but Xcode 26.1 seems to have thrown a grenade into the visionOS build process. Getting things to build with the right deployment targets and the correct images in the assets catalog is a mess
PSA: from what I’ve seen, Xcode 26.1 ignores your minimum deployment target for visionOS apps, and sets it to 26.1. Re-setting it to the intended version does seem to work. Saw this across a bunch of my projects. I haven’t checked if it does this for iOS or other platforms, but that’s a nasty bug to slip through…
Xcode 26.1 still doesn’t seem to let you get rid of the AI icon from the Toolbar, but hey at least it still works on Sequoia.
Xcode 26.1 seemingly removes the undocumented “—enable-icon-stack-fallback-generation=disabled” flag for actool, which enabled you to supply different icons for older systems.
It also means if you have lots of alternative icons, you’re back to extensive rebuild times as it re-renders all those icons every single time you touch your asset catalog.
I do not recommend updating to Xcode 26.1 if you, like me, are relying on this flag.
Previously:
Update (2025-11-06): Avi Drissman:
Since several folks noted it, while “enable-icon-stack-fallback-generation” still exists as a string in Xcode 26.1, it is no longer parsed as a flag in
-imageCatalogCompilerOptionsFromToolArguments:…, and it is no longer processed in_IBICIconStackCommonCreateNamedAssetImportInfos(). I have no further details nor advice.
Update (2025-11-10): Artem Mirzabekian (via Fatbobman):
If you’re noticing unusually high CPU usage when running the iOS 26.1 simulator, you’re not alone.
It appears that a process called MercuryPosterExtension is repeatedly crashing, which in turn triggers ReportCrash to spin up constantly - flooding the system and causing heavy CPU load.
7 Comments RSS · Twitter · Mastodon
> Xcode 26.1 seemingly removes the undocumented “—enable-icon-stack-fallback-generation=disabled” flag for actool, which enabled you to supply different icons for older systems.
Not again..........
Can someone at Apple please show us on the doll where the icons hurt them? I genuinely don't understand why they are committing to this bad idea so very much.
I wouldn’t let these people pick my shower curtains. Pretentious designers puffing their chests out. They think this is fucking HGTV. They hit the lotto they’re dumber than a bag of fucking rocks “let your content SHINE”… by displaying the shit underneath!”
“Ohhh you going against platform design language.” Maybe their manager needs to borrow my Swift paddle
Am I misunderstanding the usage of —enable-icon-stack-fallback-generation?
Understandably, you may not like the new icon guidelines and requirements, but as a developer isn't it better for maintenance and consistency to simply adopt the new macOS 26 icon approach as the single approach for your app and drop previous icons?
Sure, it means users on earlier macOS versions also get the ugly, but they are going to have to eventually. It's inevitable, for security reasons amongst many others, that you need to keep relatively up to date with later macOS versions.
Is usage of —enable-icon-stack-fallback-generation at this stage of macOS Tahoe's release simply a form of civil disobedience towards Apple?
> Is usage of —enable-icon-stack-fallback-generation at this stage of macOS Tahoe's release simply a form of civil disobedience towards Apple?
@Matthew the fallback icon looks different when xcode generates it from the icon composer file. I think the fallback icns must be using the pre Tahoe corner radius?… but in Icon Composer when you design your icon you are seeing the new Tahoe corner radius? Is that what’s happening? So you don't have WYSIWYG. You have a situation where you might be surprised after updating your app on the older OS because you’re looking at an icon that’s using a shape you didn’t even see at design time.
> Sure, it means users on earlier macOS versions also get the ugly, but they are going to have to eventually. It's inevitable, for security reasons amongst many others, that you need to keep relatively up to date with later macOS versions.
I don’t really agree with this. Prior versions of macOS are still eligible for security updates but I don’t really get the analogy anyway. The icons don’t belong to Apple. They belong to the developer. Apple can mandate the shape of icons on their platform sure, but to essentially change the icon shape for earlier macOS versions? If I want to stick my own PNGs in my asset catalog as the fallback icon why can’t they just use that? What difference does it make to them? Who’s being the asshole here really?
It’s like if you drove a Civic and then Honda released a new model. Then they came and spray painted an X on the hood of your car and said upgrade to our new design language you fing peon. This behavior would never be acceptable if we were talking about physical products and it really shouldn’t be acceptable for digital products like software either.
