Apple’s annual SDK cycle keeps shipping silent breaking changes. The UIDesignRequiresCompatibility plist key is honored on Xcode 26 builds and ignored on Xcode 27 builds. iOS 27 collapses iPhone horizontal size classes to compact, breaking ten years of storyboard constraint variations with no runtime warning. Reality Composer Pro 3 imports projects from RCP 2 with timelines, behaviors, transforms, and synced audio missing. And the iPhone SE (2020) running iOS 27 beta refuses to charge, drains overnight, and bricks itself as a test device.

If you are responsible for an app that needs to keep working through 2027, you cannot wait until the App Store deadline to find these out. This is a planning guide for the iOS 27 SDK cliff and how to time your migration.

When the iOS 27 SDK becomes mandatory

Apple’s pattern for the last several cycles: announce the new SDK at WWDC in June, allow submissions built with either the new or previous Xcode through the autumn, then require the new SDK in late April of the following year. For iOS 27 that puts the App Store cliff in late April 2027, roughly ten months from the WWDC 2026 announcement.

This timing is the single most important fact for migration planning. It is also the source of the conflict on the UIDesignRequiresCompatibility thread (832543), where teams shipping end-of-life products are being told to plan a full visual redesign on a tight clock.

UIDesignRequiresCompatibility and Liquid Glass

The Info.plist key UIDesignRequiresCompatibility was Apple’s escape valve for apps not ready to adopt Liquid Glass. Set it to YES and your app keeps the pre-Liquid-Glass appearance.

The catch, documented in thread 832543: the key is honored only when your app is built against the iOS 26 SDK (Xcode 26). As soon as you build against the iOS 27 SDK, the key is silently ignored. There is no compile-time warning. Your navigation titles begin to clip because the Liquid Glass nav bar reserves more width for its glass material.

Two viable strategies

Strategy A: stay on Xcode 26 until the cliff. This is what Apple’s own forum reply recommends, and it is the right call for end-of-life apps. Keep UIDesignRequiresCompatibility = YES in Info.plist, build with Xcode 26.x, ship the same app you have today, and migrate only when the App Store requires the iOS 27 SDK in April 2027.

<key>UIDesignRequiresCompatibility</key>
<true/>

Strategy B: migrate, but treat title clipping as a per-screen fix. If you are moving to Xcode 27 anyway, the immediate visible breakage is navigation titles clipping. The fix is a custom titleView with auto-shrinking text:

let title = NSLocalizedString("screen.title", tableName: "Main", comment: "")
let navbarTitle = UILabel()
navbarTitle.text = title
navbarTitle.adjustsFontSizeToFitWidth = true
navbarTitle.minimumScaleFactor = 0.5
navigationItem.titleView = navbarTitle

This is not a full Liquid Glass migration, just the smallest patch that stops the clipping. The deeper redesign — rethinking depth, materials, and motion the way the design system expects — is a separate project.

iPhone horizontal size class collapses to compact on iOS 27

Thread 836088 reports that on iOS 27, willTransition(to:with:) and registerForTraitChanges(_:handler:) no longer fire when the iPhone interface resizes. The only callback that still runs is viewWillTransition(to:with:). iPad behavior is unchanged.

For storyboard apps, the consequence is severe: a decade of constraint variations keyed to wR hAny / wC hR no longer activate when expected on iPhone. Nothing warns you at compile time or runtime.

What to do

1. Audit storyboards for size-class variations. Open each storyboard, switch the bottom-bar device to iPhone, and check whether the constraint set you expect is the one being applied. If your layout relied on wR hC (regular-width landscape iPhone), assume it no longer fires.

2. Drive layout from viewWillTransition(to:with:) for now. Until Apple ships a fix or a documented migration, that is the one callback the framework engineer confirms still runs on iPhone:

override func viewWillTransition(
    to size: CGSize,
    with coordinator: UIViewControllerTransitionCoordinator
) {
    super.viewWillTransition(to: size, with: coordinator)
    coordinator.animate { _ in
        self.applyLayout(for: size)
    }
}

3. File feedback with a sample project. The Apple engineer in the same thread suggests the iPhone behavior may be a bug rather than an intentional design change. Sample projects with a clear regression are the only thing that move FBs.

If you are starting a new screen, skip size-class variations and write layout in code with UITraitChangeRegistration or constraints driven by view.bounds.size. Storyboard size-class variations are no longer reliable on iPhone.

Reality Composer Pro 3: lossy migration of two-year-old projects

Thread 836102 reports that opening RCP 2 projects in Reality Composer Pro 3 drops timelines, behaviors, transforms, spin and orbit actions, hide actions, and synced audio. There is no migration tool. Teams report losing two years of work.

There is no clean technical workaround. The damage-control plan:

1. Do not open a production RCP 2 project in RCP 3 without a backup. Duplicate the entire project folder first.
2. Stay on RCP 2 for current projects unless you have a specific reason to upgrade. Reality Composer Pro is shipped inside the Xcode bundle; pinning the Xcode version pins the RCP version.
3. Export critical asset configurations to USDZ where possible before any version migration. Timelines and behaviors do not round-trip, but geometry and materials usually do.
4. File feedback. RCP 3 needs an importer that preserves what RCP 2 produced, and the only way that gets prioritized is volume of FBs from affected projects.

This is the failure mode that scares me most about Apple’s “annual reset” cadence: when the tool is also the project format, a regression in the tool eats months of work.

Beta OS on your only device: do not

Thread 834834 reports the iPhone SE (2020) failing to charge on iOS 27 beta. A second developer corroborates reverse-charging issues on the iPhone 17e. DTS punted the case to Apple Support Communities — meaning even Apple’s own technical-support channel had no fix.

The rule for indie devs has not changed: never install a beta OS on a device you depend on. The asymmetry is brutal — a successful beta install costs you nothing, a failed one costs you your test device or your daily driver. Use a dedicated secondhand device for beta installs, or wait for the public release.

A beta-cycle playbook that actually works

Every June, after the WWDC keynote, I run the same sequence:

1. Read the “Deprecations” section of the release notes first. Then the “What’s New,” then the WWDC sessions. Deprecations are the only part that affects you whether you adopt the new SDK or not.
2. Keep the stable Xcode and the beta Xcode on separate Macs, or at least separate xcode-select paths. Switching toolchains mid-debug is where most of the strange regressions originate.
3. Build one of your shipped apps against the new SDK in week 1. Not to ship — just to surface the breaking changes early. Liquid Glass clipping, size-class regressions, and SwiftUI API drift all show up the first time you build against the new SDK.
4. Pin your CI to the App Store-required SDK, not to the latest. Move it forward only when you have decided to ship the new SDK.
5. Buy a dedicated beta device. A secondhand iPhone of the right generation is cheaper than the day you brick your only test device.
6. Plan the cliff date backward. If iOS 27 SDK becomes mandatory in late April 2027, you need a buildable Xcode 27 project in March, a TestFlight in early April, and the App Store submission by mid-April. Work backward from there.

Next steps

The toolchain bugs (Xcode 26.4 IB regressions, simulator orphans, Coding Assistant UX) compound the SDK transition. If you have not lined up your Xcode-version strategy yet, do that before you start the Liquid Glass and size-class audits — otherwise you will be debugging Xcode and the SDK at the same time, and you will not know which is causing what.

---