iOS 27: why iOS devs will have to make their apps adaptive (and start thinking iPad now)
With the iOS 27 SDK, UIScene becomes mandatory, UIRequiresFullScreen is on its way out on iPad, and iPhone-only apps become resizable everywhere. Apple never says the word “foldable,” yet everything converges: iPhone apps will have to learn to scale up gracefully, and the teams preparing now are getting a head start.

A note before diving in: every technical requirement covered in this article is officially documented by Apple (technotes, WWDC26 sessions, iOS 27 release notes). The foldable iPhone angle, on the other hand, rests on credible but unconfirmed reporting: Apple has never cited it as the reason behind these changes.
At WWDC25, Apple gave developers fair warning. At WWDC26, that warning became policy: the iOS 27 SDK enforces a modern way of building apps, and three long-standing assumptions of iOS development are now officially dead: the AppDelegate-centric life cycle, layouts designed around a fixed orientation, and the idea that an iPhone app will only ever live on an iPhone screen.
1. UIScene becomes mandatory with the iOS 27 SDK
Technote TN3187 spells it out: starting with iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27 and visionOS 27, an app built with the latest SDK must adopt the scene-based life cycle, or it simply won't launch. In the “Modernize your UIKit app” session (WWDC26), Apple puts it bluntly: “UIScene lifecycle is now required when building with the latest SDKs. Without it, your application will no longer launch.”
Two important nuances: existing binaries built with older SDKs keep working, and only the scene-based life cycle is required; full multi-window support is not. But since Apple eventually mandates a recent SDK for every App Store submission, no one will escape the migration for long. The cross-platform ecosystem is already feeling the squeeze: developers have filed issues on the Expo / React Native tracker after freshly generated projects failed to launch on iOS 27, the question is stirring debate in the Unity community, and Flutter has published its own UISceneDelegate migration guide.
2. On iPad: the end of the UIRequiresFullScreen shelter
For years, the UIRequiresFullScreen key let developers opt out of iPad multitasking altogether: forced full screen, a single screen size to support, case closed. That era is over. Technote TN3192 states that the key and its compatibility mode are deprecated as of iPadOS 26 and will be ignored in a future release. The iOS / iPadOS 27 release notes add a very concrete condition: to be “continuously resizable” on iPad, an app must declare all four interface orientations in its Info.plist. And this is no longer theoretical: developers are already seeing “UIRequiresFullScreen will soon be ignored” in the console, and some App Store submissions are being rejected with the warning “Support for all orientations will soon be required.”
It's important not to overstate the change, though: full screen is not going away for users. iPadOS still offers a “Full Screen Apps” mode in Settings, and any window can still be maximized. What disappears is the developer's ability to permanently opt out of the modern windowing system. Apple is even carving out a special arrangement for games, with stepped “discrete resizing” behavior on iPhone.
3. iPhone-only apps are no longer safe
This is the point that changes the game for many teams. Once rebuilt with the latest SDK, an iPhone-only app becomes automatically resizable in two contexts: iPhone Mirroring on the Mac, and running on iPad: “fully resizable like any other iPad app,” in Apple's own words from the UIKit session. The app technically stays in the “phone idiom,” but Apple is explicit that the idiom should no longer drive layout decisions: layout should now be based on size classes and the space actually available. In other words, an iPhone interface can no longer assume a single screen, a single size, a single orientation.
4. The elephant in the room: the foldable iPhone
Officially, Apple justifies all of this with iPhone Mirroring and iPhone apps on iPad. The word “foldable” appears nowhere. But the clues keep piling up. “foldState” and “angleDegrees” strings have been spotted in iOS 27 frameworks, along with a key that returns the number of built-in displays on a device (MacRumors, June 2026). On the reporting side, Bloomberg's Mark Gurman describes a foldable whose inner display would be close in size to an iPad mini's, with an iPad-style interface and two apps side by side, yet one that would not run iPad apps as-is (Bloomberg, March 2026). In April, Reuters reported engineering snags that could weigh on the timeline.
That detail in Gurman's reporting is decisive: Apple is not preparing an iPhone/iPad merger, but an iOS in which iPhone apps must know how to scale up gracefully: precisely what the iOS 27 SDK rules already enforce.
5. Toward iPhone apps designed like iPad apps
On paper, Apple does not require shipping a genuine iPad version, and no announcement points that way. But the boundary is becoming largely theoretical: once rebuilt with the iOS 27 SDK, an iPhone app will be displayed at iPad-class sizes and aspect ratios, whether its team planned for it or not. To stay presentable in 2027, an iPhone-only app will need to migrate to UIScene, drop any logic based on orientation or idiom, adopt size classes, declare all four orientations, and be tested windowed, in Stage Manager, in full screen, and through iPhone Mirroring. In practice, that amounts to 80% of the work of a real iPad app.
Starting early is also a matter of plain technical-debt math: every new feature built on non-adaptive screens is one more screen that will have to be reworked once the migration becomes unavoidable. The bigger the app grows, the heavier the bill, whereas an already-adaptive codebase absorbs new features at no extra cost. Every quarter of waiting, by contrast, adds views to fix, flows to re-test, and potential regressions.
There is a visibility angle, too. With every new form factor, Apple has consistently spotlighted the apps that embraced the hardware from day one: the first apps optimized for the Vision Pro or the iPad benefited heavily from App Store editorial featuring. If the foldable iPhone materializes, everything suggests Apple will give the same treatment to apps already at home on its large inner display. The teams that are ready on day one will start with a visibility lead that is hard to claw back.
The takeaway: since the adaptation work is unavoidable anyway, iPhone-only teams have every incentive to make it count: designing interfaces that genuinely take advantage of large displays (columns, sidebars, split views) now, rather than settling for a stretched-out iPhone UI. The day the foldable arrives (and the entire iOS 27 SDK seems built for it), those apps will be ready. In the meantime, they'll stop looking like blown-up phone apps on iPad.
Sources
- Apple – TN3187: Migrating to the UIKit scene-based life cycle
- Apple – TN3192: Migrating from the deprecated UIRequiresFullScreen key
- Apple – WWDC26, session 278 “Modernize your UIKit app”
- Apple – iOS & iPadOS 27 Release Notes
- Apple – UIRequiresFullScreen documentation
- Bloomberg (Mark Gurman) – Foldable iPhone: iPad-style interface, side-by-side apps
- MacRumors – iOS 27 hints at a foldable iPhone (foldState, angleDegrees)
- Reuters – Foldable iPhone: engineering snags
- GitHub Expo – iOS 27 project fails to launch without UIScene

