iOS 27 for developers: the changes that break builds

Most “what’s new in iOS 27” coverage is a feature list. This isn’t one. It covers what changes when you rebuild an existing app with the iOS 27 SDK — the changes that turn a routine build into a failed launch, a compile error or a crash.

Xcode 27 ships with Swift 6.4 and requires a Mac running macOS Tahoe 26.6 or later. You will be rebuilding with it whether you want to or not: from April 2027, Apple only accepts App Store uploads built with the iOS 27 SDK or later.

1. Apps that don’t use scenes fail to launch

This is the one to plan for. It sits under UIKit → Deprecations in the iOS 27 release notes:

Apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch.

Apple has been warning about it since iOS 18.4, when UIKit started logging a message for apps without scene support. In iOS 26 the message said adoption would soon be required. In iOS 27 it is.

A developer building an unmodified Expo SDK 56 app with Xcode 27 quoted the runtime error in expo/expo#46664. Expo has since fixed this — SDK 58 beta uses scenes by default, and SDK 57 can opt in behind one flag, which the Expo SDK 58 beta post covers — but SDK 56 still fails exactly like this:

Application failed to launch: UIScene life cycle is required for apps built
with this SDK. See Technote TN3187 for more information on migration.

Two details keep this from being as alarming as it sounds:

• Existing binaries keep working. The requirement applies to apps built with the new SDK. What’s in the App Store today is unaffected until you ship an update.
• Only the life cycle is required. TN3187 is explicit: supporting multiple scenes is encouraged, but only adopting the scene life cycle is required.

Does your app need to migrate?

TN3187 gives two tests. You need to migrate if either is true:

• Your Info.plist has no UIApplicationSceneManifest key, or it has no configurations.
• Your app delegate doesn’t implement application(_:configurationForConnecting:options:).

SwiftUI apps that use the App protocol and WindowGroup are already scene-based.

The migration, in Apple’s code

First, declare a scene configuration in Info.plist. This is TN3187’s example, with the storyboard line removed for apps that build their UI in code:

<key>UIApplicationSceneManifest</key>
<dict>
    <key>UIApplicationSupportsMultipleScenes</key>
    <false/>
    <key>UISceneConfigurations</key>
    <dict>
        <key>UIWindowSceneSessionRoleApplication</key>
        <array>
            <dict>
                <key>UISceneConfigurationName</key>
                <string>Default Configuration</string>
                <key>UISceneDelegateClassName</key>
                <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
            </dict>
        </array>
    </dict>
</dict>

Second, move window creation into a scene delegate. The window is now created from the scene rather than from the screen:

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let windowScene = scene as? UIWindowScene else { return }

        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = YourRootViewController()
        window?.makeKeyAndVisible()
    }
}

Third, move UI life-cycle logic. After migrating, UIKit sends UI state changes to the scene delegate, not the app delegate. TN3187 maps the four methods:

Where migrations actually go wrong

The steps above are short. The breakage is in everything that quietly depended on the old structure. In our experience these are the places to look first:

• Code that reads the app delegate’s window. In a scene-based app the window belongs to the scene. React Native hit exactly this: facebook/react-native#53602 was a crash in code that still expected a window on the app delegate.
• Deep links and universal links. Once a scene delegate exists, URLs opened while the app runs arrive at the scene through UIOpenURLContext, and a URL that launched the app arrives in the scene’s connection options. A handler that only lives in the app delegate stops seeing them. A commenter on the Expo issue reports exactly this breaking React Native’s initial-URL handling.
• Third-party SDKs initialised from UI callbacks. Analytics, attribution and session-replay SDKs often hook app-delegate activation events. Check each one’s release notes for iOS 27 support.
• Anything keyed to a single window. A scene-based app can have more than one window, and on iPhone Duo — the first iPhone to support multiple instances of an app’s UI — that is no longer theoretical. Don’t turn on multiple scenes until your state model can cope. TN3187 notes this “may require restructuring your app.”

After migrating, test in every multitasking mode you support. TN3187 recommends Split View, Slide Over and Stage Manager on iPad, and on iPhone Duo Split View applies to every app.

Framework status

If your app is built on a cross-platform framework, the framework owns most of this migration — and the frameworks are in very different places:

The framework guides cover the practical steps: React Native and Expo on iPhone Duo and iOS 27, Expo SDK 58 beta, iOS 27 scenes and iPhone Duo and Flutter on iPhone Duo and iOS 27.

2. The new @State can stop code compiling

Xcode 27 replaces SwiftUI’s @State property wrapper with a Swift macro. The change is good: a @State private var model = Model() no longer re-runs Model.init() every time the view struct is recreated. Apple says the new behaviour back-deploys to iOS 17-aligned OS versions.

It is “largely source compatible” — with exceptions that surface as build errors.

Assigning a @State in init when the declaration already has a value. The initializer value was always discarded, but this now fails to compile. Apple’s example:

struct StickerPageView: View {
    @State private var page = StickerPage()
    let title: String

    init(title: String) {
        // `title` won't have any effect
        // this also won't compile with @State macro
        self.page = StickerPage(title: title)
        self.title = title
    }
}

The fix is to drop the initial value from the declaration:

struct StickerPageView: View {
    @State private var page: StickerPage // no initial value expression
    let title: String

    init(title: String) {
        self.page = StickerPage(title: title) // works!
        self.title = title
    }
}

Also no longer supported:

• The synthesized initializer. The macro disables it for structs whose stored members are all private, so an extension that called self.init(page:title:) must assign each member explicitly.
• Generic inference. It is less flexible, so write the type out in full.
• Composing @State with other property wrappers or macros isn’t supported.

3. Behaviour changes when you rebuild

These don’t fail the build. They change what the app does once it’s built with the iOS 27 SDK.

• TabView enforces a visible selection. Apple warns that TabView “might crash” if its selection is set to a hidden or unavailable tab. Check any code that restores a saved tab, or selects a tab you sometimes hide.
• Selectable text uses the system selection UI. Text with .textSelection(.enabled) now uses system text selection instead of a callout menu, and may add gestures. If you attach custom gestures to selectable text, Apple suggests .highPriorityGesture().
• AsyncImage now caches downloaded images using standard HTTP caching headers. A custom URLSession can be set for a subtree with .asyncImageURLSession(_:). If your server sends aggressive cache headers, images may now stay stale where they previously refreshed.
• Status bar styling from SwiftUI: .toolbarColorScheme(_, for: .statusBar) sets it directly, and .toolbarVisibility(_, for: .statusBar) hides it.

4. MetricKit: two crashes you avoid by recompiling

These two run the other way from everything else in this post: the risk is to builds you haven’t recompiled. Apple flags both with the same instruction — recompile with the latest SDK:

• HitchTimeMetric.ratio changed type to the new HitchTimeRatio. Apple says to recompile “to pick up this type change and avoid any crashes on launch.”
• ScrollHitchTimeMetric is no longer part of the new Swift MetricKit API. Code that references it risks “a missing symbol crash” until rebuilt; use HitchTimeMetric instead.

Separately, the original MXMetricManager, MXMetricManagerSubscriber, MXMetricPayload and MXDiagnosticPayload APIs are no longer recommended for new adoption. Their replacement, MetricManager, delivers MetricReport and DiagnosticReport values through AsyncStream.

5. Deprecations to schedule

• canOpenURL: is deprecated. Apple’s guidance is to attempt to open the URL and handle failure, or to use universal links so no check is needed.
• On Demand Resources and NSBundleResourceRequest are deprecated. Move to Background Assets, which in iOS 27 also supports localized asset packs.
• The Neural Engine in the background needs an entitlement. The system now restricts background access, similar to GPU restrictions. Background inference requires com.apple.developer.background-tasks.continued-processing.inference.

6. Enterprise: stricter TLS for device management and app installation

In 27.0 operating systems, selected system processes enforce stricter TLS. The affected processes handle MDM, declarative device management, Automated Device Enrollment, configuration profiles, app installation and software updates. Servers must support at least TLS 1.2, with cipher suites and certificates that meet App Transport Security requirements.

This doesn’t affect your app’s own network calls. It does matter if you distribute apps in-house from your own server or run device management — check those servers before your fleet updates.

7. Xcode 27: Device Hub

In Xcode 27, simulated and physical devices are managed from Device Hub. Some changes affect day-to-day work and tooling:

• Scripts that assumed the old Simulator app can break. Expo CLI’s run:ios failed on the Xcode 27 beta because it looked for Simulator.app (expo/expo#46882); Expo has merged a fix in its CLI. Check any in-house build or test scripts that launch or activate the simulator by app name. simctl and devicectl still work, and both gained a reboot command.
• Mac mouse and trackpad gestures now drive standard UIKit components. Scrolling emits UIEvent.EventType.scroll, pinching and rotating emit UIEvent.EventType.transform, and you may see pointer effects. Apple is clear this hybrid behaviour exists for Device Hub and does not reflect real devices.
• Downloaded app data containers land in a folder named after the bundle identifier, not an .xcappdata bundle. Apple’s release notes give the rename workaround.

Xcode 27’s release notes don’t mention iPhone Duo. Apple directs developers to Xcode 27.1 for the iPhone Duo simulator, and that shipped as a beta on 18 September 2026 — build 27A9269, carrying the iOS 27.1 SDK. Install it alongside Xcode 27 rather than over it, and read what its simulator cannot do before you plan a test pass around it.

A rebuild checklist

1. Build with Xcode 27 on a branch, early, before you need to ship on it.
2. Adopt the scene life cycle — or upgrade to a framework version that has — and retest deep links, notifications and every third-party SDK.
3. Fix @State compile errors, then check TabView selection restoration.
4. Recompile anything using MetricKit hitch metrics.
5. Replace canOpenURL: checks and plan the On Demand Resources migration.
6. Update scripts that depended on the Simulator app.
7. Test on the iPhone Duo simulator, which you can do now — it is in the Xcode 27.1 beta. Our owner’s guide to iPhone Duo and iOS 27 covers what to look for.