---
title: "TN3192: Migrating your iPad app from the deprecated UIRequiresFullScreen key"
framework: technotes
role: article
role_heading: Article
path: technotes/tn3192-migrating-your-app-from-the-deprecated-uirequiresfullscreen-key
---

# TN3192: Migrating your iPad app from the deprecated UIRequiresFullScreen key

Support iPad multitasking and dynamic resizing while updating your app to remove the deprecated full-screen compatibility mode.

## Overview

Overview Prior to iPadOS 26, apps could request a compatibility mode that opted them out of multitasking and dynamic scene resizing through the UIRequiresFullScreen key. This key-value pair configures iPadOS apps only, and is ignored for iOS apps. Update apps that rely on UIRequiresFullScreen’s compatibility mode to handle resizing scenes so they can provide a better multitasking experience. note: Starting in iPadOS 26, UIRequiresFullscreen and its associated compatibility mode are deprecated and will be ignored in a future release. Apps that don’t update may experience broken layouts, UI elements positioned incorrectly, or content that doesn’t fit properly when the system resizes their scenes to accommodate multitasking scenarios they weren’t designed to handle. This guide will help you migrate away from UIRequiresFullScreen and handle dynamic resizing. For more information on the enhanced window resizing and improved multitasking, see WWDC25 session 282: Make your UIKit app more flexible. Determine if your app should update To support resizable scenes ensure that your app: Provides a Specifying your app’s launch screen. Starting in iOS 27 and iPadOS 27, a launch screen is required for App Store submission. See TN3208: Preparing your app’s launch screen to meet App Store requirements. Supports all interface orientations. Doesn’t include the UIRequiresFullScreen key in its Info.plist or INFOPLIST_KEY_UIRequiresFullScreen or its build settings. If you need to keep UIRequiresFullScreen to support earlier versions of iOS after you’ve made these updates,  add UIRequiresFullScreenIgnoredStartingWithVersion to your information property list to specify in which version of iOS you want the system to begin ignoring UIRequiresFullScreen in your app. For example, if your app is available on iOS 18 and relies on UIRequiresFullScreen to function correctly, add UIRequiresFullScreenIgnoredStartingWithVersion to your Info.plist with a value of 26. Then the system will begin ignoring UIRequiresFullScreen on iOS 26, iPadOS 26 and later, while supporting the full screen behavior on iOS 18, iPadOS or earlier. With these updates, your app will support resizable scenes and multitasking. To learn more about adopting scene-based life cycle, see TN3187: Migrating to the UIKit scene-based life cycle. Respond to scene size changes If your app layout relies on consistent scene size, or uses absolute values for its view geometry, consider using Auto Layout to calculate the size and position of its views through constraints placed on its views. By using Auto Layout, you’re able to replace static, frame-based layouts in your app with flexible constraint-based layouts that respond to size changes. For more information on Auto Layout, including layout constraints and attributes, see Auto Layout Guide. When transitioning away from the deprecated UIRequiresFullScreen key, ensure your app’s views adapt to dynamic size changes that occur when users resize windows or change device orientation. Each of these scenarios can cause your app’s scene bounds to change at runtime, potentially breaking layouts that assume fixed dimensions. To learn more about debugging Auto Layout issues, see Unsatisfiable Layouts. You can adjust your app’s layout when the environment changes, such as when size class, display scale, or layout direction changes occur. To detect these changes, use registerForTraitChanges(_:target:action:) or registerForTraitChanges(_:handler:) to register a list of traits to observe. To observe a scene’s geometry changing, use windowScene(_:didUpdateEffectiveGeometry:) and compare the coordinateSpace.bounds of both geometries. Additionally, use isInteractivelyResizing to handle interactive resizing of the scene specifically. For example: class SceneDelegate: UIResponder, UIWindowSceneDelegate {     var gameAssetManager = MyGameAssetManager()     var previousSceneSize = CGSize.zero

func windowScene(         _ windowScene: UIWindowScene,         didUpdateEffectiveGeometry previousGeometry: UIWindowScene.Geometry) {

let geometry = windowScene.effectiveGeometry         let sceneSize = geometry.coordinateSpace.bounds.size

if !geometry.isInteractivelyResizing && sceneSize != previousSceneSize {             previousSceneSize = sceneSize             gameAssetManager.updateAssets(sceneSize: sceneSize)         }     } } In this example, isInteractivelyResizing is queried to only update assets for a new scene size after the interaction finishes. This is helpful for games, where multiple assets may require resizing when the scene changes size or if there are elements of your app’s UI that are computationally expensive to draw. In SwiftUI, use onInteractiveResizeChange(_:) to adjust how your view behaves when a window is in the process of being resized by the user. Specify scene sizing preference To express a preferred minimum size of your scene’s content, use UISceneSizeRestrictions. For example: class SceneDelegate: UIResponder, UIWindowSceneDelegate {

func scene(_ scene: UIScene,                willConnectTo session: UISceneSession,                options connectionOptions: UIScene.ConnectionOptions) {

guard let windowScene = scene as? UIWindowScene else { return }         windowScene.sizeRestrictions?.minimumSize.width = 500.0     } } The example above specifies a preferred minimum width of 500 points. note: The UISceneSizeRestrictions object does not prohibit other resizing behavior like rotation. When people rotate their device and the scene changes orientation, the scene’s bounds will change as well, regardless of the preferences expressed through the sizeRestrictions property of your app’s window scene. After the rotation has completed, the system will re-evaluate the size restrictions against the scene’s new bounds. In SwiftUI, use the windowResizability(_:) modifier to allow your scene’s content provide sizing information. The value that you specify indicates the strategy the system uses to place minimum restriction on windows that it creates from that scene. For example: @main struct MyApp: App {     var body: some Scene {         WindowGroup {             ContentView()                .frame(minWidth: 100, maxWidth: 400, minHeight: 100, maxHeight: 400)         }         .windowResizability(.contentMinSize)     } } Request scene orientation lock Some apps may benefit from temporarily locking the orientation. For example, a driving game may want to lock the orientation when the device is expected to rotate for steering a vehicle or a camera apps may need to lock orientation during photo or video capture. To request orientation lock, override prefersInterfaceOrientationLocked in your view controller subclass. Whenever this preference changes, call setNeedsUpdateOfSupportedInterfaceOrientations(). For example: class MyRaceViewController: UIViewController {

override var prefersInterfaceOrientationLocked: Bool {         return isDriving     }

// ...

var isDriving: Bool = false {         didSet {             if isDriving != oldValue {                 setNeedsUpdateOfPrefersInterfaceOrientationLocked()             }         }     } } The value returned by prefersInterfaceOrientationLocked indicates to the system that the view controller prefers the scene’s interface orientation to be locked when shown. note: The system does not guarantee that prefersInterfaceOrientationLocked preference will be honored. If honored, the preference to lock the interface orientation lasts while the view controller is visible, or you call setNeedsUpdateOfPrefersInterfaceOrientationLocked again and return false as the value of prefersInterfaceOrientationLocked. If your app uses the camera, use AVCaptureDevice.RotationCoordinator to ensure that captures and camera preview interfaces are correctly oriented regardless of interface orientation lock. To observe the interface orientation lock, use windowScene(_:didUpdateEffectiveGeometry:) and check if the value of isInterfaceOrientationLocked has changed. For example: class SceneDelegate: UIResponder, UIWindowSceneDelegate {     var game = MyGame()

func windowScene(         _ windowScene: UIWindowScene,         didUpdateEffectiveGeometry previousGeometry: UIWindowScene.Geometry) {

let wasLocked = previousGeometry.isInterfaceOrientationLocked         let isLocked = windowScene.effectiveGeometry.isInterfaceOrientationLocked

if wasLocked != isLocked {             game.pauseIfNeeded(isInterfaceOrientationLocked: isLocked)         }     } } For more information about locking your scene to your preferred interface orientation and preventing rotation changes, see prefersInterfaceOrientationLocked. Revision History 2026-06-08 Added launch screen requirement for iOS 27 and iPadOS 27. 2026-02-06 Added information about back deployment support. 2025-09-08 First published.

## See Also

### Latest

- [TN3210: Optimizing your app for iPhone Mirroring](technotes/tn3210-optimizing-your-app-for-iphone-mirroring.md)
- [TN3211: Resolving SwiftUI source incompatibilities for State and ContentBuilder](technotes/tn3211-resolving-swiftui-source-incompatibilities-for-state-and-contentbuilder.md)
- [TN3212: Adopting gesture recognizers for Sidecar touch support](technotes/tn3212-adopting-gesture-recognizers-for-sidecar-touch-support.md)
- [TN3208: Preparing your app’s launch screen to meet App Store requirements](technotes/tn3208-preparing-your-apps-launch-screen-to-meet-app-store-requirements.md)
- [TN3205: Low-latency communication with RDMA over Thunderbolt](technotes/tn3205-low-latency-communication-with-rdma-over-thunderbolt.md)
- [TN3206: Updating Apple Pay certificates](technotes/tn3206-updating-apple-pay-certificates.md)
- [TN3179: Understanding local network privacy](technotes/tn3179-understanding-local-network-privacy.md)
- [TN3190: USB audio device design considerations](technotes/tn3190-usb-audio-device-design-considerations.md)
- [TN3194: Handling account deletions and revoking tokens for Sign in with Apple](technotes/tn3194-handling-account-deletions-and-revoking-tokens-for-sign-in-with-apple.md)
- [TN3193: Managing the on-device foundation model’s context window](technotes/tn3193-managing-the-on-device-foundation-model-s-context-window.md)
- [TN3115: Bluetooth State Restoration app relaunch rules](technotes/tn3115-bluetooth-state-restoration-app-relaunch-rules.md)
- [TN3151: Choosing the right networking API](technotes/tn3151-choosing-the-right-networking-api.md)
- [TN3111: iOS Wi-Fi API overview](technotes/tn3111-ios-wifi-api-overview.md)
- [TN3191: IMAP extensions supported by Mail for iOS, iPadOS, and visionOS](technotes/tn3191-imap-extensions-supported-by-mail.md)
- [TN3134: Network Extension provider deployment](technotes/tn3134-network-extension-provider-deployment.md)
