The Resizable iPhone Era: Ready Your App Before September

How do you prepare an iPhone app for resizable screens? The SDK you link against is the line Apple draws – Xcode 27’s Device Hub explicitly treats resize mode as unsupported for apps linked against iOS 26 or earlier, and every resizability entry in the iOS 27 release notes is conditioned on “built with the iOS 27 SDK.”¹² Then: audit every fixed-size assumption (UIScreen.main.bounds reads, hard-coded frames, orientation-gated layouts), lean on size classes and layout-adaptive SwiftUI containers, and test continuously in Xcode 27’s Resizable Canvas previews and Device Hub resize mode.² The orientation prerequisite that gated continuous resizability is marked Fixed in the current release notes, so the path is clear.¹

Apple’s fall betas have spent the summer converging on one message for iPhone developers: stop assuming a fixed rectangle. The evidence is in the tooling and the release notes rather than the keynotes – resizability arrives with the iOS 27 SDK link, the preview canvas resizes freely, and the release notes cleared the last structural obstacle as the beta cycle matured. Whatever hardware ships this fall, the software contract has already changed.

TL;DR: iOS 27 brings continuous resizability to apps built with the new SDK; Xcode 27 ships the test surfaces for it (Resizable Canvas previews, Device Hub resize mode); and the current release notes – the beta 7 edition, with beta 7 released August 24 – list the orientation gate Fixed: it moved out of Known Issues between the beta 4 and beta 6 editions, and declared orientations no longer decide whether your app resizes.¹ The work is mostly subtraction: find the places your layout believes in one screen size and remove that belief. Below, the checklist, in the order I’d run it.

Why Now

Three dated facts set the clock:

1. Beta 7 landed August 24 with the cycle in its stability phase – Apple’s late betas fix rather than add, and final releases have landed in September every year.¹
2. The resizability boundary is the SDK link. Xcode 27’s release notes describe entering Device Hub’s resize mode “with an app linked against an iOS 26 or earlier SDK” as “unsupported.”² The pattern runs through the iOS notes too: every resizability entry is conditioned on “built with the iOS 27 SDK.” Rebuild and you are on the resizable side of that line; stay on the old SDK and you are opting out of where the platform is going.
3. The last structural gate has cleared. In the beta 4 era, an iPad app whose UISupportedInterfaceOrientations omitted any of the four orientations was treated as non-continuously resizable – a known issue whose documented workaround had an undocumented cost I covered in the resizability workaround post. That issue moved out of Known Issues between the beta 4 and beta 6 editions of the notes, and the current edition lists it Fixed: “Beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability.” UIKit’s known-issues list in the beta 7 notes is empty.¹

Put together: the platform now expects your layout to be a function of its container, not of a device spec sheet. iPad taught this lesson first with multitasking; iOS 27 extends the same contract to iPhone.

The Checklist

1. Rebuild with the iOS 27 SDK, then actually look

The opt-in is the rebuild. Before changing a line of layout code, build with Xcode 27, open Device Hub’s resize mode, and drag. Most well-factored SwiftUI apps survive this first contact better than their authors expect; what breaks is instructive, and it breaks in the same handful of places every time – which is what the rest of this checklist is.

2. Hunt the fixed-size beliefs

The classic offenders, in the order they usually bite:

• UIScreen.main.bounds used as “the screen size.” In a resizable world there is no the screen size, and UIScreen.main is formally deprecated as of iOS 26. Derive sizes from your window scene or, in SwiftUI, from the container via GeometryReader used sparingly or containerRelativeFrame(_:) used deliberately.
• Hard-coded frames and magic numbers calibrated to specific devices (“390 points wide means iPhone”). Any if width == <number> device inference will lie to you.
• Layout gated on orientation instead of size. Orientation checks were always a proxy; with iOS 27 decoupling orientations from resizability, the proxy is officially dead weight. Branch on horizontal and vertical size classes, which is what they were for.
• Launch-time caching of dimensions. Anything measured once at startup and stored is stale after the first resize.

3. Let the adaptive containers do their job

SwiftUI’s modern layout kit was built for exactly this: ViewThatFits for choosing between arrangements, containerRelativeFrame for sizing against the container rather than the screen, grids and flexible frames for everything between. If your app dates to the fixed-rectangle era, the highest-leverage refactor is usually replacing one load-bearing GeometryReader-plus-arithmetic layout with these primitives. UIKit apps get the same result from size classes plus UICollectionViewCompositionalLayout’s environment-driven sections.

The toolbar and layout changes in iOS 27 push the same direction – the framework now hands you explicit control at the points where space runs out, and space now runs out dynamically.

4. Test where the resizing actually happens

Xcode 27 gives you two purpose-built surfaces, both matured early in the beta cycle:

• Resizable Canvas mode in previews – no longer constrained to specific size ratios (the constraint lifted in beta 2), so you can drag through the full range of shapes your app might inhabit.²
• Device Hub resize mode for running apps, with the escape hatches fixed since beta 3 (exiting resize mode by crash or backgrounding no longer wedges the device’s screen until reboot).²

Make one pass through every primary screen in each. The bugs you find will cluster in the screens that cached, assumed, or inferred.

5. Re-examine the flags you set years ago

UIRequiresFullScreen and narrow UISupportedInterfaceOrientations declarations are how apps historically opted out of iPad multitasking’s demands. Neither is deprecated, but both are now load-bearing in new ways – the beta cycle spent several editions working out how they interact with continuous resizability, and the beta-4-era known issues around UIRequiresFullScreen resize behavior are now marked Fixed under Resolved Issues.¹ If those keys are in your Info.plist because of a decision made in 2019, this is the month to re-make the decision on purpose. The workaround-cost analysis covers the orientation-set side effects to check before you widen anything.

6. Budget for the second-order effects

Resizable means your text wraps differently, your images crop differently, your NavigationSplitView collapses and expands on someone’s whim, and your carefully tuned empty states show at aspect ratios you never previewed. None of this is hard individually. All of it is why the checklist starts now instead of the week the hardware ships.

What I’d Skip

Skip speculating about specific devices. The resizability contract is in the SDK you can download today, documented in release notes you can read today, testable in tooling that shipped in the first Xcode 27 beta. If a folding iPhone arrives this fall, apps that did the list above are ready; if it arrives next spring, the same work pays off immediately on iPad multitasking and whatever else the platform resizes next. Preparing for the mechanism beats preparing for the rumor.

Key Takeaways

• The opt-in line is the SDK link. Rebuild with the iOS 27 SDK and resizability is your app’s problem and opportunity; Device Hub treats older-SDK apps in resize mode as unsupported.²
• The orientation gate is cleared. Declared orientations no longer decide resizability – the issue is marked Fixed in the current notes, and UIKit’s known-issues list is empty.¹
• The work is deleting assumptions, not adding features. Screen-size reads, magic-number layouts, orientation proxies, launch-time caches: find, replace with container-derived layout, done.
• Test in the real surfaces. Resizable Canvas previews and Device Hub resize mode exist precisely for this; a pass through each per screen finds most of what will bite.

FAQ

Does my app become resizable automatically?

The SDK link is the boundary Apple draws – Xcode 27’s release notes call resize mode with iOS-26-or-earlier-SDK apps unsupported, and the iOS notes condition every resizability behavior on building with the iOS 27 SDK.¹² What happens next depends on your layout: container-driven SwiftUI mostly adapts; fixed-size assumptions surface as bugs.

Do I still need to declare all four orientations to be continuously resizable?

No – the current release notes mark the orientation condition Fixed (it cleared between the beta 4 and beta 6 editions), stating that “supported interface orientations should no longer be a condition for continuous resizability.”¹ Earlier betas required the all-four workaround, which had app-wide side effects worth understanding if you shipped it.

Is UIRequiresFullScreen deprecated now?

No. It remains a supported key, and the beta-cycle known issues around its resize behavior are marked Fixed under Resolved Issues in the current notes.¹ But it is exactly the kind of years-old opt-out worth re-deciding deliberately in a resizable-first platform.

When does this become urgent?

The final iOS 27 releases are expected in September, and Apple’s fall SDK requirement cycle means new submissions move to the iOS 27 SDK on Apple’s usual schedule after that. The checklist above is a focused week of work for most apps – comfortably done before launch season if started now.

Sources