Supporting both orientations is one field in your app config. The lock was never the hard part.
In a React Native and Expo project, one setting decides this. The top level orientation field in your app config takes three values, default, portrait or landscape, and default means no lock. Set it to default and the app rotates. Whether the screens are usable after they rotate is a separate job, and that job is the reason people leave the lock on. What follows is where the field is, what each store actually says about a single orientation app, and why a lock you set two years ago may already be ignored on tablets. If you are still choosing a framework rather than living with one, we put Flutter against React Native elsewhere.
The short version of the surprise: neither store has a rule that forces you to support both. Both platforms have quietly stopped guaranteeing the opposite. Every figure and date below was read from Apple, Google and Expo documentation on 17 October 2026.
Start hereThe short version
The lock is turning into a request the system can refuse.
For ten years an orientation lock was a fact. You wrote it down once and the device obeyed. That has changed on both platforms, for the same reason: screens stopped being one size. A phone app now gets opened on a tablet, mirrored into a window on a Mac, and dragged half way across a foldable. A lock is awkward in all three situations, so the platforms started overriding it.
So the real question is not whether to support both orientations. It is whether your layout falls apart when the choice is taken out of your hands. If you have inherited a project you did not type, that is the thing worth checking this week, and it takes about twenty minutes on a tablet simulator.
Where is the orientation setting in a project you did not write?
In your app config, which is the app.json or app.config.js file at the root of the project. The key is called orientation and it sits at the top level, next to the app name and the icon, not inside the ios or android blocks. Expo describes it in one sentence: it “locks your app to a specific orientation with portrait or landscape”, and defaults to no lock. The valid values are default, portrait and landscape. That is the whole setting.
Two things about that reference are worth noticing, because they explain a lot of confusion later. It does not say which platforms the field applies to, and it does not mention that either platform may ignore it. There is a separate web.orientation key for the web build, and no android.screenOrientation key documented on that page at all. So the config gives you one honest knob and no warning label, and the warning labels live in the platform documentation instead.
Three nearby iOS settings matter if a tablet is in scope. ios.supportsTablet decides whether the build supports tablet screen sizes, and Expo documents it as false by default. ios.requireFullScreen says the app does not support Slide Over and Split View on iPad, also false by default. ios.isTabletOnly drops handset support entirely. None of these is a layout decision. They change which devices the build claims to support, and what the system is allowed to do with your window once it is installed.
If you are reading a generated project, check the field before you believe a bug report. An app that refuses to rotate on one tester's phone and rotates on another's is usually not a bug in your code at all. It is this field meeting two different devices, or a device with rotation lock switched on in the system settings.
Does either store require both orientations?
No. On Apple's side the answer is unusually clean, because the rule book does not mention the subject. We read the App Store Review Guidelines in full on 17 October 2026 and searched the whole document. The word orientation appears exactly once, in guideline 1.1.1, about discrimination, not about screens. The words portrait and landscape do not appear anywhere. The closest thing to a relevant rule is guideline 2.4.1, which says iPhone apps should run on iPad whenever possible, and encourages building so customers can use an app on all their devices. That is a nudge about devices, not a rule about rotation.
Apple's design guidance is where the expectation actually lives. The Human Interface Guidelines page on layout tells you to decide layout from size classes rather than from device type or orientation, because a size class describes the space you actually have and an orientation does not. It then makes the point that matters most to anyone keeping a lock: even an app locked to one orientation, a landscape only game for instance, still needs to resize well across devices and window sizes. Apple lists resizable windows on iPad and Mac, and iPhone Mirroring, among the characteristics an app has to handle.
Google puts its expectation in app quality guidelines rather than in store policy. In the Adaptive ready tier, last updated 3 October 2026, a test called T-Config_Orientation asks you to verify that the app is not letterboxed and not running in compatibility mode in portrait, in landscape, in multi-window mode, and on a large screen foldable unfolded in either orientation. Separate criteria require that state survives rotation, folding and window resizing, and that camera preview and media projection come out the right way round in both orientations. That page does not say it is a Play policy.
Being straight about the gap in this research: we did not find a Google Play policy that requires two orientations, and we are not going to call that an absence. Apple's absence we can state, because the review guidelines are one document and we searched all of it. Google's policy centre is many pages, and the honest sentence is that the requirement, if it exists, is not where we looked.
What happens when the platform ignores your lock?
Your app rotates anyway, and whatever you assumed about screen shape is now wrong. Android states it plainly. For apps targeting Android 16, API level 36, orientation, resizability and aspect ratio restrictions no longer apply on displays whose smallest width is at least 600dp. The ignored list is longer than people expect: the screenOrientation and resizeableActivity manifest attributes, both aspect ratio attributes, and the setRequestedOrientation and getRequestedOrientation calls. Screens under sw600dp are exempt, so phones behave as before.
There is a way out and it has an expiry date. Setting a property named PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY to true, on one activity or on the whole application, restores the old behaviour. Android calls that opt out temporary in the same breath. Its page on restrictions being ignored says Android 17 removes it for apps targeting API level 37, and names only two exceptions: games, identified by the appCategory flag, and users who opt in to an app's default behaviour through the device's aspect ratio settings. Both Android pages carried a last updated date of 16 October 2026 when we read them.
The iOS version of this arrives through resizing rather than through a target level. Expo's own ScreenOrientation reference has a section titled orientation locks on iOS 27 and later. It says that from iOS 27 an iPhone app can be resized, giving iPhone Mirroring on macOS and running on an iPad as the examples, and that while an app is resizable the system treats a supported orientation as a preference rather than a requirement. Two consequences follow: a lock request can simply be refused, and the orientation your app reads back may not describe the window it is drawing into. Expo notes that iPhone Mirroring always reports portrait regardless of the window shape. The library logs a warning in debug builds when the system refuses a lock, which is the cheapest way to find the screens that still depend on one.
On iPad this is not even new. Expo has long warned that since split view arrived an iPad app is treated as landscape unless two apps are open side by side, and that locking the orientation requires setting ios.requireFullScreen to true. The update is that from iOS 27 that flag no longer keeps the app out of being resized, so it can no longer reliably lock anything. Both of the escape hatches, one per platform, are being removed in the same twelve months.
Check yours
Does your orientation lock still hold?
Pick where the app is running. Every answer below comes from Apple, Google or Expo documentation read on 17 October 2026.
The lock is ignored, with a temporary way out.
Android documents that for apps targeting Android 16, API level 36, orientation, resizability and aspect ratio restrictions no longer apply on displays whose smallest width is at least 600dp. screenOrientation, resizeableActivity, minAspectRatio, maxAspectRatio, setRequestedOrientation and getRequestedOrientation are all on the ignored list. A property named PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY opts an activity or the whole application back out, and Android calls that opt out temporary.
Figures and target levels move. Read the dated sources before you plan work around any of them.
What does it cost to leave the app in one orientation?
On a phone, almost nothing. Plenty of good apps are portrait only and nobody minds. The cost arrives on larger screens, and it arrives in three forms. A letterboxed window, which is the thing Google's own test tells you to look for. Lost state, because a rotation is a configuration change and an app that was never rotated in testing has never had its state restored. And anything measured once at startup, which is now wrong for the rest of the session.
The third one is the quiet one. React Native publishes a hook, useWindowDimensions, whose reference says it updates all of its values when the screen size or font scale changes. A layout driven by that hook follows the window. A width read once into a constant does not, and the symptom is a screen that looks correct until somebody turns the device, then stays wrong until it is reopened. This is the single most common inherited bug in a project that was locked from day one.
If you need portrait on phones and cannot afford the landscape work yet, Android publishes the compromise itself. Leave the manifest permissive, either by not declaring screenOrientation or by setting it to fullUser, then restrict to portrait at runtime only when the screen width or height is below 600dp. Android calls that a temporary measure and still recommends supporting every configuration properly. The page was last updated on 22 September 2026. It is a staged retreat, not a fix.
Plan the change as a release rather than a patch. Expo describes its config plugin properties as settings that cannot be changed at runtime and that need a new app binary to take effect, and the iOS orientation property is one of them. So a flipped lock travels with a new build through both stores, which is a different queue from over the air updates and a different week. Layout fixes inside your own JavaScript are a separate matter and move faster.
The same question, answered differently by each platform
| The question | iOS and the App Store | Android and Google Play |
|---|---|---|
| A store rule demanding both orientations | No | None found in Play policy, see the caveat above |
| Where the lock lives in an Expo project | The orientation field in your app config | The same single field |
| Does the platform still honour a lock on a big screen | A preference only, once the app is resizable | Ignored at sw600dp and above from API 36 |
| Is there a documented opt out | ios.requireFullScreen, unreliable from iOS 27 | A manifest property, removed at API 37 |
| What the documentation tells you to do instead | Lay out by size class, resize well even when locked | No letterboxing in either orientation, keep state |
| Checked in a published test or checklist | No | Yes |
Read on 17 October 2026. The Android rows move with your target API level, so they are worth rechecking at every yearly bump.
Where this lands if a builder generated your app
Nothing above changes because an AI wrote the first version. The field has the same name, the stores have the same rules, and the platform ignores the lock on a tablet whoever typed the config. What does change is how quickly you can find the setting and how freely you can change it, and that depends entirely on whether you were handed a real project or a black box.
Newly generates a real React Native and Expo project that you own. That means the orientation field in your app config is the ordinary Expo field documented above, not a vendor toggle, and it behaves the way Expo says it behaves. There is two way GitHub sync, so changing it is a branch and a pull request rather than a support ticket. It is $25 a month, with no free tier. If the ownership question is the one you are actually asking, we wrote separately about who owns AI generated code.
Testing it is the part worth building into your routine. Newly uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android APK, so the rotation check happens on a real tablet before a stranger does it for you. Rotate every screen once per release. It is five minutes and it catches the measured once bug that no amount of reading will.
One limit to state plainly, because it shapes the whole workflow: Newly does not submit to the App Store for you. Apple requires the content owner to submit, so the final step is yours, and so is the answer you give if a reviewer opens your app sideways on an iPad. While you are reading the parts of the project you did not type, Hermes and the new architecture is the other default worth understanding before it surprises you.
Questions people ask about screen orientation
Set the top level orientation field in your app config to default, which Expo documents as no lock, and then make every screen survive the rotation. The field is an enum with three values: default, portrait and landscape. There is no separate switch for landscape left and landscape right at this level. Expo's app config reference, read on 17 October 2026, gives one sentence of description for the whole field, which is a fair reflection of how little work the setting itself is. The layout work afterwards is the real task.
Describe the app, then turn the device
Build it, open it on a tablet, and rotate every screen before you decide whether you need the lock at all. The answer is usually cheaper than the argument about it.
Start building