Android 17 Will Ignore Your Portrait Lock — Getting Rork-Built Expo Apps Ready for Large Screens Ahead of Time

Unwinding the Lock — app.json and Per-Screen Locking

The first structural change is moving from a global lock to "lock only the screens that truly need it." Here is the app.json change:

{
  "expo": {
    "orientation": "default",
    "android": {
      "softwareKeyboardLayoutMode": "pan"
    },
    "plugins": [
      ["expo-screen-orientation", { "initialOrientation": "DEFAULT" }]
    ]
  }
}

Removing the global lock raises an immediate question: what about camera screens or video players that genuinely want a fixed orientation? Lock those per screen with expo-screen-orientation — and skip the lock on large screens, where it would be ignored anyway:

// useConditionalPortraitLock.ts — lock portrait on phones only
import { useEffect } from "react";
import { useWindowDimensions } from "react-native";
import * as ScreenOrientation from "expo-screen-orientation";
 
export function useConditionalPortraitLock() {
  const { width, height } = useWindowDimensions();
  // Treat shorter side >= 600dp as large screen: locking there is futile
  const isLargeScreen = Math.min(width, height) >= 600;
 
  useEffect(() => {
    if (isLargeScreen) {
      ScreenOrientation.unlockAsync();
      return;
    }
    ScreenOrientation.lockAsync(
      ScreenOrientation.OrientationLock.PORTRAIT_UP
    );
    return () => {
      ScreenOrientation.unlockAsync();
    };
  }, [isLargeScreen]);
}

Writing "do not lock on large screens" explicitly may look redundant, since the OS ignores the lock anyway. I prefer it this way: code that encodes the platform's intent keeps working even if enforcement details shift, while code that depends on an ignored setting is a latent bug.

Rebuilding Layouts Around Size Classes

With orientation unlocked, layout comes next. Scattering if (isTablet) checks across screens is how maintenance dies. I centralized the decision into a single size-class hook, so screens only ever read a class name:

// useSizeClass.ts — define size classes in exactly one place
import { useWindowDimensions } from "react-native";
 
export type SizeClass = "compact" | "medium" | "expanded";
 
export function useSizeClass(): SizeClass {
  const { width } = useWindowDimensions();
  if (width < 600) return "compact";    // phone portrait
  if (width < 840) return "medium";     // unfolded foldable, small tablet portrait
  return "expanded";                    // tablet landscape, desktop window
}

The 600 / 840 thresholds match the Material Design window size classes. Borrowing a published standard instead of inventing your own makes it far easier to stay aligned with designers and with other libraries.

A list screen then becomes a small mapping problem:

// WallpaperGrid.tsx — switch column count and navigation by size class
import { FlatList, View } from "react-native";
import { useSizeClass } from "./useSizeClass";
 
const COLUMNS: Record<string, number> = {
  compact: 2,
  medium: 3,
  expanded: 5,
};
 
export function WallpaperGrid({ items }: { items: Item[] }) {
  const sizeClass = useSizeClass();
  const numColumns = COLUMNS[sizeClass];
 
  return (
    <View style={{ flexDirection: sizeClass === "expanded" ? "row" : "column", flex: 1 }}>
      {sizeClass === "expanded" && <SideNavigation />}
      <FlatList
        key={numColumns}            // force re-layout when column count changes
        data={items}
        numColumns={numColumns}
        renderItem={renderThumbnail}
      />
    </View>
  );
}

One trap worth calling out: FlatList throws if you change numColumns on the fly, so you must pass the column count through key to force a remount. Fold/unfold transitions can trigger this remount repeatedly, so on screens where scroll position matters I also restore it via initialScrollIndex across the transition.

Verification Without Owning a Foldable

Not buying a foldable just to test is, frankly, the indie developer's honest preference. The following routine got me essentially all the way there:

1. Create a Resizable device. In Android Studio's Device Manager, the "Resizable" profile lets you switch between phone, foldable, and tablet shapes from the running emulator's toolbar
2. Replay fold and unfold. The same emulator's fold/unfold button exercises the dimension-change events and re-layout while the app stays alive
3. Drag-resize in a desktop window. Continuously resize the window across the 600dp and 840dp boundaries and confirm the layout crosses thresholds in both directions without breaking
4. Rotate through every screen. Once the lock is gone, landscape variants of screens you never designed for become reachable. Walk all of them once

This routine surfaced exactly four issues in my apps: a splash image stretched in landscape (fixed with contain sizing), modals growing absurdly tall on wide screens (capped at 560dp max width), keyboard covering inputs (revisited softwareKeyboardLayoutMode), and the FlatList column error above. Each fix took well under half a day — but every one of them would have shipped broken without this pass.

My Suggestion — Do One Full Pass Before the Deadline Does It for You

Android 17 is expected to roll out to Pixel devices first this summer, but nothing about the preparation requires waiting for the OS. The resizable emulator, the size-class refactor, the per-screen locks — all of it runs in today's tooling.

Across my six apps the budget worked out to: 10 minutes for the impact assessment, half a day for app.json and per-screen lock rework, one to two days for size classes and layout fixes, and half a day for verification. At most three days per app to turn the tablet and foldable experience from "visibly broken" into "actually uses the screen" strikes me as a clearly worthwhile trade.

Start by opening your current build in a Resizable emulator and watching how it breaks — the right starting point becomes obvious once you see it. For individual layout-breakage patterns, see Fixing Screen Orientation and Rotation Issues in Rork-Built Apps, and for the design thinking behind large-screen retrofits on the Apple side, Three Weeks of Adjusting a Rork-Generated App for iPad: Design Notes pairs well with this article.