iOS 27 iPad Resizability: The Workaround Has a Cost

Apple’s iOS 27 release notes give a one-line workaround for iPad apps that are not continuously resizable: declare support for all four interface orientations in your Info.plist.¹ What the note omits is that the system intersects that app-wide declaration with each view controller’s supported orientations.² Widen the app-wide set and you widen it everywhere, iPhone included, unless every constrained view controller overrides supportedInterfaceOrientations.

The headline version of this change is also wrong about the current state. Apple’s intent is that declared orientations stop gating continuous resizability. The release note recording that intent is filed under Known Issues, because in Beta 4 they still gate it.¹

Both halves matter. The behavior is a bug on the way to a deliberate change, and the workaround for the bug has a side effect nobody documents in the same place.

TL;DR

In iOS & iPadOS 27 Beta 4, an iPad app built with the iOS 27 SDK whose UISupportedInterfaceOrientations omits any of the four orientations is treated as non-continuously resizable, which Apple lists as a known issue alongside the statement that orientations “should no longer be a condition for continuous resizability.”¹ The documented workaround is to declare all four. Doing so widens your app’s orientation set app-wide, and the system determines rotation by comparing app-wide orientations against each view controller’s.² Four further known issues involve UIRequiresFullScreen delivering continuous resize updates where discrete UIScreen changes are intended.¹ Neither UIRequiresFullScreen nor UISupportedInterfaceOrientations is deprecated.³⁴

What the Release Notes Actually Say

Six entries in the UIKit section of the iOS & iPadOS 27 Beta 4 notes bear on this, five of them open.¹

The gate itself, filed under Known Issues:

“On iPad, if your iPad app is built with the iOS 27 SDK and its UISupportedInterfaceOrientations doesn’t include all four interface orientations, the app is treated as non-continuously resizable. Beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability.”

Read the tense in the second sentence. “Should no longer be a condition” describes intended behavior. The entry exists as a known issue because the shipping behavior does not match the intent yet.

That distinction changes what you do. If orientations had genuinely stopped gating resizability, the advice would be to remove workarounds. Because they still gate it, the advice is to apply one, and to expect the reason for it to disappear.

Four known issues around UIRequiresFullScreen:

An iPad app built with the iOS 27 SDK that sets UIRequiresFullScreen receives continuous resize updates, where “each resize should instead be delivered as a discrete change to a new UIScreen with an updated bounds.” The same applies to an iPhone-only app running on iPad, and again inside iPhone Mirroring.¹

A fourth covers orientation handling in iPhone Mirroring: an app built with the iOS 27 SDK gets a scene supporting all orientations “regardless of the orientations declared in UISupportedInterfaceOrientations or returned by UIViewController.supportedInterfaceOrientations,” where those “should be honored until the user begins resizing the window.”¹

One resolved: an earlier issue where UIScreen.main bounds changed on resize under UIRequiresFullScreen now appears under Resolved Issues.¹ It was a live known issue in a previous beta. If you are working from notes taken a few weeks ago, check that one before repeating it.

What Continuous Resizability Buys You

Before weighing the cost, it is worth being precise about the thing being gated, because “continuously resizable” is doing specific work.

An iPad window can change size in two ways. It can jump between discrete states, which is what an app in compatibility mode gets: the system, in Apple’s words, “maintains a consistent scene size for your app, but doesn’t present your app’s scene full screen.”³ Or it can track the drag, receiving a stream of intermediate sizes as the user moves the resize control.

The difference shows up in the user’s hand. A continuously resizable app reflows while the window moves. A non-continuously resizable one holds its layout and snaps at the end, which reads as sluggish next to system apps that do not.

Apple has been narrowing the compatibility path for years. UIRequiresFullScreen arrived in iOS 9 to opt out of iPad multitasking and dynamic resizing entirely.³ Stage Manager in iPadOS 16 and Windowed Apps mode in iPadOS 26 each expanded what a window can do, and the documentation now describes compatibility mode in terms of what it withholds rather than what it grants.

So the question the workaround answers is whether your iPad app participates in modern windowing or sits in a mode Apple keeps shrinking. That is worth an Info.plist change. It is not worth an unguarded one, which is the point of the next section.

The Workaround’s Cost

Apple’s workaround is stated in a single sentence: declare all four interface orientations in Info.plist.¹ The consequence lives on a different page.

UIViewController.supportedInterfaceOrientations documents how rotation is decided:²

“To determine whether to rotate, the system compares the view controller’s supported orientations with the app’s supported orientations — as determined by the Info.plist file or the app delegate’s [method] — and the device’s supported orientations.”

Three sets, intersected. The Info.plist declaration is a ceiling, not an instruction. An app that has stayed portrait-only by listing one orientation in Info.plist and never overriding anything at the view controller level loses its constraint the moment it applies the workaround.

For a universal app, that lands on iPhone as well as iPad. And Apple’s own guidance argues against the wide declaration there: on the upside-down orientation, “It’s best practice to enable it for the iPad idiom. iOS devices without a Home button, such as iPhone 12, don’t support this orientation. You should disable it entirely for the iPhone idiom.”² The Info.plist documentation says the same from the other direction, noting the system ignores upside-down “on devices without a Home button.”⁴

So the honest instruction is two steps, not one:

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

Skip the second step and you have told a universal app to rotate upside-down on iPhone in order to obtain an iPad windowing behavior. The failure is not a crash or a build error. It is a camera view that flips while someone is using it.

Note also that supportedInterfaceOrientations defaults differ by idiom, and the system only consults it when shouldAutorotate returns true.² If you have overridden that, the interaction is worth re-reading before assuming your constraint holds.

Finding Out Whether You Are Affected

None of this produces a build error, so the audit is manual. Three checks, in descending order of how much time they save.

Check what your Info.plist actually declares, per target. The orientation keys are frequently set once at project creation and never revisited, and a universal app can carry different declarations for iPhone and iPad through UISupportedInterfaceOrientations~ipad. Read both.

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

PlistBuddy exits non-zero when a key is absent, which is itself the answer for UIRequiresFullScreen: no key means you were never in compatibility mode.

Find the controllers that constrain orientation in code. These are the ones that keep working after the Info.plist change, and their absence is what makes the change dangerous.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

An empty result combined with a narrow Info.plist declaration is the exact profile that breaks: the app is portrait-only entirely by virtue of the property list, so widening it removes the only constraint that existed.

Then look at the app, on both idioms. The failure is visual and the automated signal is weak. A UI test that drives a screen and asserts on its contents passes in any orientation. What you are looking for is a view rotating that previously could not, which means running the iPhone build and physically turning the device or simulator after the Info.plist change.

Media capture, document scanning, signature fields, games, and anything with a fixed-aspect canvas are where an unexpected rotation is most costly, and they are also where per-controller overrides most obviously belong.

UIRequiresFullScreen Is Being Hollowed Out, Not Deprecated

Four of the five open issues involve UIRequiresFullScreen.¹ The key that opts an app out of iPad multitasking is now the condition under which resize delivery behaves incorrectly.

It is not deprecated. The UIRequiresFullScreen documentation shows iOS 9.0 and iPadOS 9.0 availability with no deprecation, unavailability, or beta flag.³ Neither is UISupportedInterfaceOrientations, available since iOS 3.2.⁴

That combination is worth naming. An app setting UIRequiresFullScreen in 2026 compiles without a warning, ships without a migration notice, and lands in a compatibility mode Apple keeps narrowing. The documentation already describes what that mode means on modern systems: in iPadOS 26 and later on iPads supporting Windowed Apps mode, and in iPadOS 16 or later on iPads supporting Stage Manager, the system “maintains a consistent scene size for your app, but doesn’t present your app’s scene full screen.”³

The key no longer does what its name says. It has not been retired, and nothing in your build will tell you that.

The Pattern: SDK Linkage Decides

Every entry above shares a condition, and it is not the OS version. Each one applies to apps “built with the iOS 27 SDK.”¹

Same source, different binary, different behavior. That has come up repeatedly in this release: menu item images depend on which SDK you linked against, with three distinct behaviors across two SDK generations. And macOS 27’s cross-team container denial appears to be the opposite case, an OS-level policy with no SDK qualifier, which is exactly why the distinction is worth checking rather than assuming.

The practical consequence for testing: a build against the iOS 26 SDK and a build against the iOS 27 SDK are different subjects. If your CI matrix has one Xcode version, it tests one of them.

What To Do Now

Decide whether you need continuous resizability at all. If your iPad app already declares all four orientations, nothing here applies. The workaround is only relevant if you deliberately constrained orientations.

If you apply the workaround, pair it with per-controller overrides. The Info.plist change is a ceiling; the constraint has to move into supportedInterfaceOrientations on the controllers that need it, keyed on idiom.

Audit for UIRequiresFullScreen separately. Four open issues involve it, and it is not flagged in your build. Grep your Info.plist files, including any target you do not think of as an iPad app, since one of the issues covers iPhone-only apps running on iPad.

Expect the gate to disappear. Apple states orientations should no longer condition continuous resizability. When that lands, the reason for declaring all four goes away, but the widened orientation set stays in your Info.plist until someone removes it. Leave a comment explaining why it is there.

Re-check the notes before acting. One of these six entries has already moved from Known Issues to Resolved. This post reflects Beta 4 as of August 2, 2026.

Key Takeaways

For iPad app developers: - Declared orientations still gate continuous resizability in Beta 4, despite Apple stating they should not. Treat it as a bug with a workaround, not as the new behavior. - The workaround widens your app-wide orientation ceiling. Add per-controller supportedInterfaceOrientations overrides or your iPhone build starts rotating. - Four open issues involve UIRequiresFullScreen delivering continuous rather than discrete resize updates.

For anyone maintaining an older app: - UIRequiresFullScreen is not deprecated and produces no warning, while the behavior it requests keeps narrowing. Audit for it explicitly. - Every issue here is conditioned on building with the iOS 27 SDK, not on the OS the user is running.

FAQ

Have declared orientations stopped gating continuous resizability?

Not in Beta 4. Apple states that “beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability,” and files that statement under Known Issues because the current behavior still gates on them.¹

What is the actual workaround?

Declare all four interface orientations in UISupportedInterfaceOrientations.¹ Pair it with supportedInterfaceOrientations overrides on view controllers that must stay constrained, because the system intersects the app-wide set with each controller’s.²

Will this affect my iPhone build?

If you ship a universal app and rely on Info.plist alone to constrain orientation, yes. Apple recommends disabling upside-down entirely for the iPhone idiom, and notes the system ignores it on devices without a Home button.²⁴

Is UIRequiresFullScreen deprecated?

No. Its documentation shows iOS and iPadOS 9.0 availability with no deprecation flag.³ Four of the open issues here involve it, so the absence of a deprecation marker should not be read as an endorsement.

Should I remove the workaround once Apple fixes the gate?

Remove the part you no longer need, and keep the part that protects you. When declared orientations stop conditioning continuous resizability, the reason for listing all four disappears, and you can narrow UISupportedInterfaceOrientations back to what your app actually supports. The per-controller supportedInterfaceOrientations overrides should stay regardless, since expressing orientation constraints where the constraint belongs is more durable than relying on an app-wide ceiling.

The failure mode to avoid is the reverse: narrowing the Info.plist back while forgetting the overrides were the only thing keeping a capture screen upright.

How do I know if my app is currently continuously resizable?

Resize the window on an iPad and watch whether the layout tracks the drag or snaps at the end. Tracking means continuously resizable. If it snaps, check two things: whether UIRequiresFullScreen is set, which opts out of dynamic resizing entirely, and whether UISupportedInterfaceOrientations lists all four orientations, which is the condition this known issue describes.¹³

Does building against an older SDK avoid all of this?

Each entry is conditioned on building with the iOS 27 SDK.¹ An older SDK avoids these specific issues, and delays the eventual change rather than preventing it.

Sources