The rejection email arrives at 2 a.m., naturally. Not during business hours, not while you’re watching the pipeline — at 2 a.m., after the release manager has gone to bed and the on-call engineer discovers that a build which sailed through TestFlight all summer now bounces off App Store Connect with a signing error nobody has seen before. Welcome to the first production signing window for a new OS. Betas lie. Production tells the truth.
App Store Connect started accepting builds for iOS 27, iPadOS 27, macOS 27, tvOS 27, visionOS 27 and watchOS 27 today. So the question every release owner is asking: do I repoint my pipeline at Xcode 27 now, or keep shipping with the Xcode 26 toolchain I’ve spent a year hardening? Let’s run the two side by side on the things that actually get you paged, not the things that get keynote applause.
One caveat before the bell rings, because it changes how you should read everything below. The only thing Apple actually announced today is that the submission window is open. That page says nothing about new signing rules, new restricted entitlements, or changed notarization requirements. So treat what follows as an audit checklist grounded in how these APIs are documented and how prior OS cycles have behaved — not as a changelog of confirmed iOS 27 changes. If Apple has quietly tightened a requirement, it will surface in two places: the Xcode 27 release notes, and your own upload at submission time. Check both against your actual build. That is the job.
Round one: notarization and signing mechanics
This is where people expect drama and rarely get any. Notarization is Apple’s most stable surface — the whole point of it is predictability, and Apple doesn’t casually break the thing that lets Gatekeeper trust your Mac app. As documented, the workflow is what it has been: submit, wait, staple, verify.
The hardened runtime is still mandatory for Developer ID distribution, timestamps are still required, and your signing certificates don’t magically expire because a new OS shipped. I’ve seen nothing in today’s announcement or the notarization documentation to suggest that changed — but the way to be sure for your bundle is to run the commands above, not to trust me. What does bite on a fresh toolchain is boring and human: a new Xcode ships a new build of swift, and anything you link — Sparkle, a crash reporter, an embedded helper — needs to be signed with the same hardened runtime and a valid timestamp or notarization refuses the whole bundle. That failure is invisible in Xcode 26 if the dependency was already stapled. Rebuild on 27 and the linker pulls a fresh copy, and suddenly you’re re-signing frameworks at 2 a.m.
Neither toolchain wins on rules here, because nothing points to a rules change. Xcode 26 wins on known behaviour. Point one: Xcode 26, because you’ve already paid the tax.
Round two: the entitlements catalog and the Apple Intelligence question
This is the round everyone’s really here for, so let’s be blunt about it. Apple introduced the Foundation Models framework — on-device generative inference — in the previous cycle, iOS 26 / macOS 26, and it’s documented in the FoundationModels reference. Per that documentation, it does not require a special restricted entitlement to call the on-device model. It requires the device to support Apple Intelligence, the user to have enabled it, and your code to check availability instead of assuming it:
The shape above — SystemLanguageModel.default.availability, the .available / .unavailable(reason:) cases, LanguageModelSession — is what Apple documents for the framework. Confirm it against the FoundationModels headers in the Xcode 27 SDK before you build against it; that’s a thirty-second check and cheaper than a compile error in front of a reviewer. If you ship code that force-unwraps its way past that switch, it works on your desk and fails on an entire fleet of ineligible or opted-out devices. That’s not a signing problem — it’s a review-rejection and one-star-review problem. Nobody at Apple has to gate it with an entitlement for it to hurt you.
Here’s the discipline that survives any OS bump: don’t take my word for what’s in your bundle, or Apple’s marketing’s word. Diff your actual entitlements between the build that’s live and the build you’re about to ship.
If that diff shows an entitlement you didn’t add on purpose, stop the release. The place to cross-check what a given entitlement actually permits — and whether it now needs an explicit request through your account — is the Signing & Capabilities tab in Xcode 27, then the entitlements themselves in the Certificates, Identifiers & Profiles section of your Developer account. App Store Connect will tell you at upload time if you’re claiming a capability your provisioning profile doesn’t carry. It will tell you at the worst possible moment, but it will tell you.
This round goes to Xcode 27 — not because it invents restrictions, but because building against the new SDK is the only way the toolchain will flag a capability mismatch before the reviewer does. A stale SDK can leave you blind to a tightened requirement.
Round three: MDM and declarative device management
Enterprise is where “we tested the app” and “we shipped to the fleet” turn out to be different projects. Apple has been steering toward declarative device management for several cycles, and its device management documentation reflects the same trajectory: profile-based MDM commands keep giving way to declarations the device evaluates for itself and reports status on. If your MDM vendor is still leaning on legacy profile pushes for things that now have declarative equivalents — software update enforcement being the obvious one — a new OS is exactly when that debt comes due.
The audit here isn’t in Xcode at all. It’s confirming your MDM vendor has certified against the new OS, and that any configuration you ship as a profile still applies cleanly. A declarative software update enforcement configuration follows this documented pattern, and it’s the one to prefer over the old com.apple.SoftwareUpdate profile keys:
On Business Manager and Managed Apple ID federation with Entra, Okta or Google: check your vendor’s compatibility matrix, but don’t expect a new OS to force re-enrollment on its own, and nothing in today’s announcement suggests it does. Federation is an identity-layer relationship, not an OS build artifact — a device upgrading from 26 to 27 doesn’t renegotiate its Managed Apple ID. What forces churn is a policy change on your side or Apple deprecating an enrollment type, and that gets announced with lead time, not sprung on release day. This round is a draw between the toolchains because it isn’t a toolchain question. It’s a “did you read your MDM vendor’s release notes” question, and the answer is usually no.
Round four: biometrics and the Secure Enclave
LocalAuthentication and the Secure Enclave are, mercifully, another area Apple treats as load-bearing and leaves alone. As documented, your SecKeyCreateRandomKey call against kSecAttrTokenIDSecureEnclave works the same, and the access-control flags that matter for security still mean what they meant:
The one that catches teams out isn’t new to iOS 27 and never gets old: .biometryCurrentSet invalidates the key the moment the user enrolls a new face or fingerprint. That’s the correct, secure behaviour. But if you didn’t design a re-enrollment path, an OS upgrade that nudges users into re-scanning biometrics turns into a wave of “the app locked me out” tickets. Test the biometry-change path on real hardware before release, not the simulator. Draw again — same documented APIs, same discipline, both toolchains.
Round five: rollback safety
Here’s the one that decides it. Once you upload a build compiled against the Xcode 27 SDK, that’s your baseline; you can’t quietly revert to the 26 build for that version if the new toolchain introduced a regression, without cutting a fresh submission and eating review time. And historically — this is a pattern from every prior cycle, not a documented claim about Xcode 27 specifically — an x.0 Xcode release is the buggiest Xcode you’ll touch all year. The things that tend to break on a fresh x.0 are exactly the load-bearing ones: signing quirks, notarization retries that fail and then succeed, the odd dSYM upload that vanishes. I have no Xcode 27 defect list to point you at yet, and that’s precisely the point — the forum threads that catalogue this year’s specific breakage won’t exist until a week or two after GA, so nobody can hand you that list today. Xcode 26, several point releases deep, is the known quantity. Xcode 26 wins on rollback safety.
The verdict
Tally it up and it’s close: Xcode 26 wins on known behaviour and rollback, Xcode 27 wins on catching capability mismatches early, and the enterprise and biometric rounds are draws that come down to your own homework rather than Apple’s. On points, that’s a narrow edge to caution.
But ship against Xcode 27 anyway — for most people, most of the time. If your app touches anything in the current SDK, if you want the compiler and App Store Connect to flag entitlement drift before a human reviewer does, and if you’re going to submit against iOS 27 at all, do it on the toolchain that matches. Just don’t do it on the day x.0 drops. Let someone else find the notarization bug.
The case for staying on Xcode 26: you’re in a change freeze, you have a validated pipeline, you need zero iOS 27 APIs, and a critical fix has to go out now. Then keep the boring toolchain, ship the fix, and migrate to 27 once it’s had a point release and the forum threads have gone quiet. The most secure signing pipeline is the one you understand — and understanding takes a couple of point releases to earn.
