Guideline 2.4.1 Hardware Compatibility: How to Fix iPad Rejections for iPhone and Universal Apps

What Guideline 2.4.1 actually means

Guideline 2.4.1 is short. Its key sentence: "iPhone apps should run on iPad whenever possible" (App Store Review Guidelines, 2.4.1). Apple adds that it encourages building apps customers can use on all of their devices. In practice that creates two situations:

• Your app is iPhone-only. iPads can still download it and run it in compatibility mode, an iPhone-sized viewport on the iPad screen (Apple's QA1623). App Review may test it there, and it has to work.
• Your app is universal (iPhone and iPad). It runs natively on iPad, with iPad presentation rules, different screen sizes, both orientations and resizable windows. All of that has to work.

Check the Review device details at the bottom of the rejection. If they name an iPad, the reviewer hit the problem there. The same iPad problem may also be cited under another guideline: a crash or broken login often arrives as 2.1 App Completeness, a cramped layout as 4.0 Design. The fixes below apply to all of them.

Common reasons apps fail on iPad

The first row deserves emphasis: an action sheet or share sheet without an anchor makes UIKit throw an exception on iPad, which is a hard crash. On iPhone your share button works, so you never notice until App Review taps it on an iPad.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a 2.4.1 rejection step by step

1. Reproduce on the reported device. Read the review device details, screenshots and any crash log. In Xcode (Window > Devices and Simulators), add a simulator for that iPad model with the iPadOS version named in the rejection (or the closest runtime available) and run the same commit you submitted in the Release configuration. Symbolicate crash logs with the dSYM from your archive.
2. Anchor every popover. Search for UIActivityViewController, .actionSheet and UIImagePickerController. Before presenting, set popoverPresentationController?.sourceView = shareButton and sourceRect = shareButton.bounds, or use barButtonItem or sourceItem (iOS 16 and later). In SwiftUI, prefer ShareLink and confirmationDialog, which handle iPad anchoring. Watch for helpers that present a share sheet from the root view controller with no anchor. For photo picking, move to PHPickerViewController or SwiftUI's PhotosPicker: the iOS 27 SDK deprecates UIImagePickerController's .photoLibrary source type in favor of PHPicker.
3. Make iPhone layouts survive compatibility mode. Put forms and long content in scroll views, pin primary buttons to the safe area and remove heights tuned to one iPhone model.
4. Adapt universal layouts. Use size classes, Auto Layout or SwiftUI stacks and cap content width. A split view (NavigationSplitView, UISplitViewController) often fixes "stretched iPhone UI" better than constraint tweaks.
5. Remove iPhone-only assumptions. Check canOpenURL before offering calls or SMS, handle reduced location accuracy and never branch on device model names. Check that login and purchase also work with a hardware keyboard attached.
6. Ship a new build. Increment the build number, upload, install via TestFlight on a real iPad, then resubmit with review notes that explain the fix.

TARGETED_DEVICE_FAMILY, UIRequiredDeviceCapabilities and why there is no opt-out

The first instinct after an iPad rejection is often to remove iPad support. Here is why that rarely works.

TARGETED_DEVICE_FAMILY

In Xcode, Target > General > Supported Destinations writes the TARGETED_DEVICE_FAMILY build setting, which Xcode turns into the UIDeviceFamily key in your Info.plist: 1 is iPhone, 2 is iPad, 1,2 is universal (Build settings reference). Setting it to 1 does not keep your app off iPads. Per QA1623, the app "will still run on an iPad in compatibility mode", and App Review can still test it there.

If your live app is already universal, you can't go back. Per QA1623, App Store Connect does not accept an update that runs on fewer devices than the current App Store version; the upload fails because bundles "must continue to support any devices previously supported."

UIRequiredDeviceCapabilities

Adding telephony to UIRequiredDeviceCapabilities does stop the App Store from offering a new app on iPad. It is still not a real fix:

• Apple's documentation says to "specify only the features that your app absolutely requires" (UIRequiredDeviceCapabilities). A note-taking app does not need the Phone app.
• Apple's documentation also says that for app updates "you can only maintain or relax capability requirements", so this route is closed for an app that is already live.
• The bug behind the rejection stays in your code.

Only declare capabilities your app truly can't work without; Apple's Required Device Capabilities page shows which devices support each one.

Going universal affects metadata

Apple's screenshot specifications list 13-inch iPad screenshots as "Required if app runs on iPad", which applies once your build declares iPad support. Use real iPad UI, not stretched iPhone captures; see Guideline 2.3.3 Screenshots.

Universal apps: sizes, orientations and iPadOS 26 windowing

iPadOS 26 introduced freely resizable windows. Apple's TN3192 says UIRequiresFullScreen and its compatibility mode are deprecated starting in iPadOS 26. Starting in iOS 27 and iPadOS 27, apps built with the iOS 27 SDK that still set the key no longer opt out of resizing; the system resizes their scene discretely instead. What to do in a universal app:

• Support all four iPad orientations in UISupportedInterfaceOrientations~iPad (build setting INFOPLIST_KEY_UISupportedInterfaceOrientations_iPad). TN3192 lists support for all orientations as a prerequisite for resizable scenes. If one screen needs a fixed orientation, request it with prefersInterfaceOrientationLocked (iOS 26 and later) on that view controller instead of locking the whole app; TN3192 notes the system does not guarantee to honor it.
• Stop reading the screen size. Lay out against view or window scene bounds and react to trait changes; a resized window can be as narrow as an iPhone.
• Set a minimum size with sizeRestrictions?.minimumSize on the window scene (UIKit) or windowResizability(.contentMinSize) (SwiftUI) if your layout has a hard lower limit.
• Watch the window controls. In windowed mode, iPadOS 26 draws close, minimize and resize controls in a top corner of your window, and custom top bars can end up underneath them. For custom UIKit headers, constrain to view.layoutGuide(for: .margins(cornerAdaptation: .horizontal)); in SwiftUI, use the containerCornerOffset(_:sizeToFit:) modifier. Both are available from iOS 26.
• Provide a launch screen. Per Apple's TN3208, App Store Connect rejects uploads built with the iOS 27 SDK or later whose Info.plist has no launch screen key (UILaunchScreen or UILaunchStoryboardName, for example) with error ITMS-90870. This applies to iPhone-only apps too.

Flutter, React Native and Expo specifics

Expo and React Native

• Expo's ios.supportsTablet defaults to false: your app ships iPhone-only and runs in compatibility mode on iPad. Setting it to true commits you to native iPad layouts and screenshots, which you can't undo for a live app.
• If your Expo config sets ios.requireFullScreen, it relies on the deprecated UIRequiresFullScreen behavior described above. Plan for resizable windows instead.
• React Native's Share.share() and ActionSheetIOS accept an anchor option, documented as "used for iPad". Pass the node of the button that opened the sheet.

Flutter

• Flutter's default iOS runner sets TARGETED_DEVICE_FAMILY = "1,2", so new Flutter apps are universal unless you changed it.
• With share_plus, pass sharePositionOrigin from the tapped widget's render box. Current versions fall back to the screen center; older versions could crash or freeze on iPad without it.
• Use LayoutBuilder breakpoints instead of device checks, and wrap long forms in a scroll view.

WebView content needs to be responsive at iPad widths as well; a desktop layout inside an iPad WebView looks broken to a reviewer.

How to test on iPad before you resubmit

Simulators

Run your app on an 11-inch and a 13-inch iPad simulator, in portrait and landscape. For an iPhone-only target you can still pick an iPad simulator as run destination; the app launches in compatibility mode, just as the reviewer sees it. xcrun simctl list devices available shows the models your Xcode version offers.

CI UI tests

Add iPad destinations to your test job, for example xcodebuild test -scheme App -destination 'platform=iOS Simulator,name=[iPad simulator name]', one per size. Write a UI test that taps every share, export and "more" button; on iPad, an unanchored popover crashes the run. Rotate with XCUIDevice.shared.orientation = .landscapeLeft and assert that primary buttons stay hittable.

Real devices

Install the TestFlight build on a real iPad with the current iPadOS, ideally a small one like an iPad mini. Walk through onboarding, login, purchase and sharing, then resize the window to its narrowest width. Check Xcode Organizer > Crashes and TestFlight feedback for iPad-only crashes.

How to reply, resubmit or appeal

Reply in App Store Connect

Open your app, click the unresolved issues link, choose Resolve next to the submission, then Reply to App Review. Replies are limited to 4,000 characters and can include attachments (App Store Connect Help), such as an iPad screen recording of the previously failing flow.

Resubmit with a new build

Almost every 2.4.1 rejection needs a code change, so a reply alone won't help. Upload a fixed build and explain in App Review Information > Notes what broke, on which device, and how to verify the fix.

Appeal or ask for a consultation

Appeal to the App Review Board only if you can show the submitted build works on the reported iPad and iPadOS version; Apple allows one appeal per rejected submission (App Review). Unsure what the reviewer saw? On the same page, Apple offers 30-minute video appointments with App Review to discuss the guidelines.

If your rejected submission is a bug-fix update for an app that's already live, App Review may offer to approve it and let you resolve the additional issues in your next submission, as long as there are no legal or safety concerns. To accept, reply to the offer message in App Store Connect. A crash introduced by the update itself still has to be fixed first.

How to avoid 2.4.1 next time

• iPad in every CI run: UI tests on at least one iPad simulator per pull request.
• Presentation lint rule: a SwiftLint custom rule or script that flags UIActivityViewController or .actionSheet code without popover configuration.
• Snapshot tests at iPad sizes: key screens at compact width, 11-inch and 13-inch, in both orientations.
• Guard device settings: fail the build if the TARGETED_DEVICE_FAMILY build setting, UIRequiredDeviceCapabilities or the iPad orientation list changes unexpectedly, or if the launch screen key is missing from the Info.plist.
• Real-iPad smoke test of every release candidate via TestFlight.

AI-assisted checks help here, from scanning code for unanchored presentations to comparing screenshots across device sizes, but human testing on real hardware still catches what automation misses. If you'd like help setting this up, book a free consultation call with appsubmitter.io, or let our team handle CI/CD, submission and review communication, even if your code isn't 100% ready. Code changes aren't included; they're discussed and quoted upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline 2.4.1 - Performance - Hardware Compatibility on [iPad model from review device details] running [iPadOS version].

We reproduced the issue on iPad and fixed it in build [new build number]:

1. [Issue, e.g. the share sheet crashed on iPad] – [fix, e.g. all share and action sheets are now presented as anchored popovers].
2. [Issue, e.g. the "Continue" button was cut off at iPhone resolution on iPad] – [fix, e.g. onboarding screens now scroll and buttons are pinned to the safe area].

We tested the new build on [iPad simulators and real device models] with [iPadOS versions], in portrait and landscape.

To verify: [steps, e.g. sign in with the demo account below, open any item, tap Share].

Demo account: [username] / [password]
A screen recording from an iPad is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• The issue was reproduced and fixed on the iPad model and iPadOS version from the review device details.
• Every share sheet, action sheet and photo library picker has a popover anchor.
• iPhone-only build: tested in compatibility mode on an iPad simulator, no cut-off buttons, every long screen scrolls.
• Universal build: tested on an 11-inch and a 13-inch iPad in portrait and landscape, and in a resized window.
• Universal build: all four orientations are declared in UISupportedInterfaceOrientations~iPad.
• Login, onboarding and purchase work on iPad, with a hardware keyboard and without telephony.
• TARGETED_DEVICE_FAMILY and UIRequiredDeviceCapabilities match the live version unless deliberately changed, and the Info.plist contains a launch screen key (required for iOS 27 SDK builds).
• CI UI tests that tap every share and export button pass on an iPad simulator.
• The TestFlight build was smoke-tested on a real iPad, and 13-inch iPad screenshots are uploaded if the app is universal.
• App Review notes explain what was fixed, on which device, and how to verify it.

Frequently asked questions

Official source: App Store Review Guidelines – 2.4.1 Hardware Compatibility. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.