iPad support: claiming it is easy, having it is not
You do not have to support iPad. You do have to be honest about whether you do.
An app listed as iPad-compatible will be opened on an iPad, and the reviewer evaluates what they find there the same way they evaluate the phone build.
Three failures cover nearly all React Native cases:
1. A phone layout stretched across a large screen. Fixed widths, hard-coded dimensions, and a design that assumed roughly 390 points. It runs, and it looks like an oversight because it is one.
2. Orientation declared and not tested. The declaration lives in configuration, the testing does not, and an app claiming landscape support that breaks in landscape is a clean finding.
3. Modals and sheets sized for a phone. Full-screen on a phone, a small box or an unusable full-page overlay on an iPad.
And the metadata half: iPad screenshots must show the iPad layout. A scaled iPhone screenshot is visible instantly and suggests the support is nominal, which invites a closer look at the app. Screenshots and app previews.
Dropping iPad support is a legitimate decision, not an admission. Supporting it badly is worse than not supporting it.
Deciding whether to support it
Two honest questions:
Is the app better on a larger screen? Something with lists, documents, side-by-side content or drawing, usually yes. A quick-capture utility used one-handed, usually no.
Will you test it every release? If the answer is no, the support degrades silently and you find out through a rejection or a review.
If both answers are no, ship iPhone-only. In Expo that is a configuration decision, and making it deliberately is better than inheriting iPad support from a template and never opening it.
The checks
# what the app config declares
npx expo config --type public 2>/dev/null | \
grep -E 'supportsTablet|orientation|requireFullScreen|userInterfaceStyle'
# hard-coded widths that will not survive a large screen
grep -rnE 'width:\s*(3[0-9][0-9]|[0-9]{3})\b' src app --include=*.tsx | head -20
# Dimensions.get read once at module scope, which does not survive rotation
grep -rn "Dimensions.get" src app --include=*.tsx --include=*.ts | headThe third command finds the most common structural bug. Dimensions.get('window') evaluated once at import time gives you the launch size forever. On a phone that is almost always fine; on an iPad, rotation and multitasking change it, and the layout does not follow. useWindowDimensions re-renders on change and is the fix.
Testing it properly
On a real iPad or the simulator, in this order:
1. Launch in portrait. Does the layout use the width, or is it a
centred phone-width column with nothing beside it?
2. Rotate. Does anything overlap, clip, or stay the old size?
3. Open every modal, sheet and picker.
4. Open the camera or image picker, if you have one.
5. Try Split View, if you do not declare requireFullScreen.
6. Check the keyboard: it is proportionally smaller on iPad and
layouts tuned to phone keyboard height are wrong.Steps 2 and 3 find most of it. They are also the two nobody does, because the app "works" in portrait on first launch.
Where it gets reported
Usually under Guideline 2.1 App Completeness, with a screenshot of your app looking wrong on an iPad. Sometimes as a metadata problem when the screenshots are the giveaway.
Neither cites an "iPad guideline", which is why searching for one does not find the answer.
The related declarations
| Declaration | What it commits you to |
|---|---|
supportsTablet | An iPad experience that a reviewer will open |
orientation / supported orientations | Every orientation you list working |
requireFullScreen | Opting out of Split View, which is a choice to make deliberately |
| iPad screenshots | Showing the actual iPad layout |
Each of these is a line in configuration and a commitment in testing, and the gap between the two is the entire category of failure. The EAS submission checklist. · Why RN and Expo apps fail differently.
shipcheck reports the device and orientation support your resolved config declares alongside what the screenshots in your listing actually show, so a mismatch is a finding rather than a surprise. What it checks. · The first-submission checklist.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
Does my iOS app have to support iPad?
No. You can ship an iPhone-only app. What causes problems is listing the app as iPad-compatible and then not having an iPad experience, because a reviewer will open it on an iPad and evaluate what they find.
What do reviewers check on iPad?
That the app runs, that the layout uses the screen rather than stretching a phone layout, that rotation works if the app claims to support it, and that iPad screenshots show the iPad layout rather than a scaled iPhone one.
How do React Native apps usually fail on iPad?
Three ways: layouts built with fixed dimensions or phone-width assumptions, missing or wrong orientation handling, and modals or sheets that were sized for a phone and become unusable on a large screen.
Do I need separate iPad screenshots?
If the app supports iPad, yes, and they must show the iPad layout. A stretched iPhone screenshot is visible immediately and suggests the iPad support is nominal, which invites a closer look at the app itself.
What about landscape orientation?
If your app declares it supports landscape, it has to work in landscape. Declaring orientations you have not tested is a common and avoidable finding, because the declaration is in configuration and the testing is not.
Should a small team support iPad at all?
Only if the app is genuinely better on a larger screen and you will test it. Supporting it badly is worse than not supporting it, and dropping iPad support is a legitimate decision rather than an admission.
shipcheck. “iPad support: claiming it is easy, having it is not.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/rejections/ipad-and-device-compatibility/