Xcode Versions

The NeXT lineage and Project Builder origin

Xcode is genuinely old. Its codebase descends from Project Builder, the IDE that shipped on NeXTSTEP starting in 1989, written by NeXT to bootstrap its own NeXTSTEP and OPENSTEP applications. Project Builder paired with Interface Builder (separate app, built around the same idea of editable interface freeze-dries that the Mac OS classic Resource Editor pioneered) to form the canonical NeXT developer toolchain. When Apple acquired NeXT in December 1996 — the deal that returned Steve Jobs to Apple and seeded what would become Mac OS X — Project Builder and Interface Builder came along for the ride.

Through Mac OS X Cheetah (March 2001) and through Jaguar (August 2002), Project Builder + Interface Builder were the official toolchain on the new platform. Cocoa apps were built in Project Builder; Carbon apps could use it too via the C-bridged toolchain. Xcode 1.0 in October 2003 was the rebrand that signaled Apple’s ownership of the IDE direction. Project Builder went away as a name but its DNA carries forward through every Xcode release since — the project file format (.xcodeproj), the build-settings inheritance model, the workspace concept, the way targets composed into products. (Cross-link: the Mac page’s NeXT acquisition section.)

Interface Builder remained a separate app for almost another decade. It only merged into Xcode itself with Xcode 4 in March 2011 — the unified-window era that has held since.

Xcode 4 and the unified-window era (March 2011)

Xcode 4 was contentious. The redesign collapsed the multi-window NeXT-lineage IDE into a single unified workspace window, integrated Interface Builder directly into the same window, and reorganized the navigation panes around a left-rail navigator + right-rail inspector model. Longtime developers who had learned Project Builder + Interface Builder as separate apps over the previous decade found the new unified UI dense and unfamiliar. The release was widely, if grudgingly, taken as a step backward in the short term and a foundation in the long one.

The long term argued for the redesign. Every Xcode release since 2011 has built on the unified-window foundation. The single-window architecture made possible the Assistant Editor, the unified Build Settings inspector, the Issue Navigator, the integrated Source Control UI, and most recently the embedded SwiftUI Preview canvas. Splitting any of those across multiple top-level windows would have produced a worse experience.

Xcode 4 also flipped two compiler defaults that mattered structurally: LLVM became the default compiler toolchain (replacing GCC, which had been the BSD/Mach default since the OPENSTEP era), and Clang became the default Objective-C front-end. Chris Lattner had brought LLVM into Apple in 2005; by Xcode 4 it was the toolchain. The investment in LLVM as a platform — rather than a one-off C compiler — is what made Swift (announced 2014, open-sourced 2015) implementable inside Apple at all. (Cross-link: the Swift Versions page on Lattner’s lineage.)

The iPhone SDK and the App Store-shaped Xcode

The iPhone shipped in June 2007 with no official third-party SDK; Apple’s public position at launch was that web apps in mobile Safari would be the third-party developer story. The reversal came on March 6, 2008, at the iPhone Software Roadmap event, where Apple previewed iPhone 2.0 and announced the immediate availability of the iPhone SDK beta — and with it the App Store, the Apple Developer Program, and the entire ecosystem that has shaped Xcode releases ever since. (This is often misremembered as a WWDC announcement; WWDC 2008 came three months later, in June.) That beta SDK shipped as Xcode 3.1; Xcode 3.1 GA followed alongside the App Store launch in July 2008. (Cross-link: the iOS Versions page’s App Store launch section.)

Every Xcode release from 3.1 onward is shaped by the iPhone (and later iPad / Apple Watch / Apple TV / Vision Pro) SDK release cycle far more than by the Mac SDK cycle. A new Xcode in September every year tracks the September iOS release; the macOS release in October usually fits inside the same Xcode major. The iOS-shaped cadence has held for nearly two decades.

Swift — closed in 2014, open in 2015

Swift launched at WWDC 2014 — closed-source at first, bundled inside Xcode 6, designed by Chris Lattner’s team. Apple positioned it as the eventual successor to Objective-C; the immediate effect was a confusing 2014–2016 period when the same project might have a mix of Objective-C source files (.m), Swift source files (.swift), and bridging headers connecting them.

In December 2015, Apple open-sourced Swift — including the compiler, standard library, REPL, and Swift Package Manager — under the Apache 2.0 license. The Swift project moved to open evolution through the Swift Evolution process, with formal SE-NNNN proposals reviewed by a community-and-Apple committee. (Cross-link: the Swift Versions page’s open-source section.)

The deliberate Swift 3 source-incompatible reset shipped with Xcode 8 (September 2016) — cleaning up the Swift API guidelines for the open-source era, reformulating naming conventions, and breaking source compatibility one last time before committing to the long-term backwards-compat guarantee. Subsequent Xcode releases have bundled the matching Swift major: Swift 4 with Xcode 9, Swift 5 with Xcode 10.2 (with ABI stability), Swift 5.5 (concurrency) with Xcode 13, Swift 6 (with its data-race-safe language mode as an opt-in) with Xcode 16.

The Apple Silicon transition (Xcode 12, 2020)

Apple announced the Apple Silicon transition at WWDC 2020 and shipped the first M1 Macs in November 2020. Xcode 12 was the bridge release: it ran natively on Apple Silicon (arm64) Macs and on Intel (x86_64) Macs, and its build output was the new Universal 2 binary format that bundles both arm64 and x86_64 slices into a single executable.

Universal 2 echoed the original Universal binary format from Xcode 2.1 (2005) — that one bridged the PowerPC→Intel transition. The architectural pattern is identical: Apple ships a transition Xcode that can build for both architectures, gives developers a 2–3 year window to migrate, and then drops the older architecture from the bundled SDK once the migration is complete. The end of the Intel side of that window is no longer a forecast. Xcode 26 still installs and runs on Intel Macs; Xcode 27, which shipped on September 14, 2026, does not. Apple’s Xcode 27 release notes say it in one line — “Xcode 27 will only install and run on Apple silicon Macs” — and the same notes drop x86_64 from ARCHS_STANDARD for anything deploying to macOS 27.0 or DriverKit 27.0, so those targets stop building Universal by default. Intel as a target outlives Intel as a host: the macOS 27 SDK still back-deploys Universal binaries to macOS 12 and later, x86_64 can be added back to ARCHS by hand, and the same notes add that “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”

Three separate clocks are in play — two ran out this fall and the third now has a date — and Apple’s own posts compress them into one sentence often enough to be worth untangling. (1) Intel as a development host ended with Xcode 27, above. (2) Intel as a machine that runs macOS ended with macOS 26 Tahoe: macOS 27 installs only on Apple silicon — every Mac on Apple’s compatibility list for the September 14 macOS 27 release is an Apple silicon model, and the September 9, 2026 developer post states it outright: “macOS 26 is the final release supporting Intel Mac computers and Rosetta — macOS 27 will be Apple silicon only.” (3) Rosetta, the translation layer that lets an Intel binary run on an Apple silicon Mac, ends one release later. On September 1, 2026 Apple published Upcoming changes to Rosetta support for Intel-based macOS apps, which is the more specific source and says: “macOS 27: Final release to support Rosetta — Intel-only apps will no longer run on Mac computers with Apple silicon after this update,” with a carve-out for older, unmaintained gaming titles that depend on Intel-based frameworks. On macOS 26.4 and later, in the same post’s words, “Users may receive a system notification when launching apps that rely on Rosetta.” So the September 9 post’s “Intel Mac computers and Rosetta” phrasing folds two different deadlines together; the Xcode 27 notes’ own “macOS versions that support Rosetta like macOS 27” is the tell that Rosetta outlives Intel hardware by a release. (Cross-link: the Mac page’s Apple Silicon transition section.)

The Apple Silicon transition also accelerated Xcode-the-product. Compile times improved substantially on M1+; the local on-device debugger workflow got faster; the iOS Simulator got dramatically faster (it now runs as a native arm64 process rather than translated x86_64). Xcode 16’s on-device predictive code completion is only viable because the Apple Silicon NPU and unified-memory architecture make large-model inference cheap on the developer’s own machine.

Xcode Cloud (2021–)

Xcode Cloud opened as a limited beta on June 7, 2021, announced by Apple as “Built into Xcode 13,” and became available to all Apple Developer Program members on June 6, 2022 — while Xcode 13 was still the current release, three months before Xcode 14 shipped. It’s Apple’s hosted CI/CD service, integrated with Xcode and App Store Connect: pushed branches trigger builds, build results render inside Xcode itself, and successful builds can flow directly into TestFlight and App Store submissions. The service replaced the older Xcode Server / Bots feature (which had shipped in Xcode 5 and stagnated through the 2010s) with a fully managed alternative. Adoption has been measured — teams using GitHub Actions, Bitrise, or Circle for cross-platform CI tend to stay on those rather than fragmenting their pipeline — but for iOS-only shops, Xcode Cloud is now the default Apple-recommended CI path.

The App Store submission-floor pattern

Apple periodically announces a submission-floor change — a date after which an upload has to be built against a newer platform SDK — on developer.apple.com/news, months ahead of the date the floor takes effect. Two worked examples, and they bracket the notice window rather than confirming a fixed one. The floor in force today was posted as Upcoming SDK minimum requirements on February 3, 2026 for enforcement on April 28, 2026 — just under three months. Its successor was announced much earlier in the cycle: on September 9, 2026, the day the App Store opened for the 27 releases, for enforcement “Starting April 2027” — roughly seven months, and with a month rather than a day attached to it. Plan on months of warning, not on a fixed interval. Submissions below the floor are rejected at upload time with a generic “invalid bundle” error and an opaque support-page link.

Note where the Xcode number actually lives. The announcement itself is phrased purely in SDK terms — “iOS and iPadOS apps must be built with the iOS 26 & iPadOS 26 SDK or later,” then the same line for tvOS, visionOS, and watchOS — and never names an Xcode version at all. The entry Apple keeps afterward on its Upcoming Requirements list does: “built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26.” So a team that reads only the announcement is left to map SDK versions onto an Xcode version itself — which is the mapping the matrix above exists to supply.

The pattern matters operationally because the failure mode is silent. There’s no in-IDE warning when you build with an Xcode that’s about to fall below floor. There’s no email reminder. The only way to discover that your CI pipeline produces unsubmittable builds is to attempt a submission and have it rejected. Teams whose CI is pinned to a specific Xcode version (and most are, for reproducibility) tend to discover this only when a release blocks at upload time.

The current floor is surfaced in the strip near the top of this page and re-checked whenever Apple announces a change — the floor cell is the most volatile element on the page, so it is verified on a tighter sub-cadence than the rest of the matrix.

The Android-side counterpart

The cascade pattern this page documents — an IDE that pins a minimum OS to install, a bundled language version, a bundled platform SDK, and a downstream submission floor — isn’t Apple-specific. The same shape exists on the Android side, where Android Studio pins a minimum AGP, AGP pins a minimum Gradle and a minimum Kotlin Gradle Plugin, all of them pin a minimum JDK, and Google Play Store has its own target-SDK submission floor that escalates roughly annually. The two stacks differ in their specifics — Android’s split toolchain (Studio is JetBrains-derived, Gradle is independent, Kotlin is JetBrains’ language, JDK is OpenJDK) creates more vendor flexibility but more compatibility surface; Apple’s monolithic toolchain reduces the matrix but makes the macOS upgrade itself the binding constraint — but the mental model is the same: floor not target, do the least you can get away with. (Cross-link: Android Studio Versions.)