Adapting Your Rork iOS App to iPhone Air and 17 Pro Series — Layout Patterns for 2026's New Resolutions

Centralizing Device Constants in a Single File

The first version of my iPhone Air fix scattered if (width === 420) branches directly inside individual screen components. It worked, but the affected code was spread across different files. The next new device size would require another search-and-update pass through the entire codebase.

Before building DeviceConfig.ts, my four apps had a combined 29+ places where device-specific values were computed inline using ternary operators and if-else chains. After centralizing, every component that previously had its own device-branching logic now imports from one file. A new iPhone means one file changes.

// src/config/DeviceConfig.ts
import { Dimensions } from 'react-native';
 
const { width, height } = Dimensions.get('window');
 
type DeviceProfile = {
  wallpaperWidth: number;
  wallpaperHeight: number;
  safeAreaTop: number;
  safeAreaBottom: number;
  thumbnailHeight: number;
  gridColumns: number;
};
 
const DEVICE_PROFILES: Record<string, DeviceProfile> = {
  'iphone-air': {
    wallpaperWidth: 420,
    wallpaperHeight: 912,
    safeAreaTop: 59,
    safeAreaBottom: 34,
    thumbnailHeight: 220,
    gridColumns: 3,
  },
  'iphone-17-pro': {
    wallpaperWidth: 402,
    wallpaperHeight: 874,
    safeAreaTop: 59,
    safeAreaBottom: 34,
    thumbnailHeight: 210,
    gridColumns: 3,
  },
  'iphone-pro-max': {
    wallpaperWidth: 440,
    wallpaperHeight: 956,
    safeAreaTop: 59,
    safeAreaBottom: 34,
    thumbnailHeight: 230,
    gridColumns: 3,
  },
  'iphone-standard': {
    wallpaperWidth: 393,
    wallpaperHeight: 852,
    safeAreaTop: 59,
    safeAreaBottom: 34,
    thumbnailHeight: 200,
    gridColumns: 3,
  },
  'default': {
    wallpaperWidth: width,
    wallpaperHeight: height,
    safeAreaTop: 44,
    safeAreaBottom: 34,
    thumbnailHeight: 200,
    gridColumns: 3,
  },
};
 
function detectDevice(): string {
  if (width === 420) return 'iphone-air';
  if (width === 402) return 'iphone-17-pro';
  if (width >= 430) return 'iphone-pro-max';
  if (width === 393) return 'iphone-standard';
  return 'default';
}
 
export const DEVICE = DEVICE_PROFILES[detectDevice()];
export const SCREEN_WIDTH = width;
export const SCREEN_HEIGHT = height;

The explicit DeviceProfile type provides a secondary benefit: if you add a new device to DEVICE_PROFILES and forget to specify a field, TypeScript flags it at compile time rather than failing silently at runtime.

Full-Screen Wallpaper Display and Aspect Ratio

The wallpaper display challenge is getting images to fill the screen without distorting their proportions or leaving visible gaps. iPhone Air's 420×912 aspect ratio is approximately 0.46 — nearly identical to the standard 393×852 model — which means resizeMode="cover" handles it cleanly for full-screen display. The visual difference between the two is minimal.

The more common issue emerges in thumbnail grids. When screen width drives column layout, a 3-column grid on a 420pt screen produces different column widths than the same grid on a 393pt screen. If those widths aren't integers, React Native may encounter sub-pixel rendering issues that show up as subtle image blurriness.

// ❌ May produce non-integer column widths
const columnWidth = SCREEN_WIDTH / 3;
 
// ✅ Round down and distribute the remainder as padding
const columnWidth = Math.floor(SCREEN_WIDTH / 3);
const totalGridWidth = columnWidth * 3;
const horizontalPadding = (SCREEN_WIDTH - totalGridWidth) / 2;

For the full-screen viewer itself:

<Image
  source={{ uri: wallpaperUrl }}
  style={{
    position: 'absolute',
    top: 0,
    left: 0,
    width: SCREEN_WIDTH,
    height: SCREEN_HEIGHT,
  }}
  resizeMode="cover"
/>

Absolute positioning with explicit dimensions ensures the image fills the viewport on any device without requiring device-specific style overrides.

FlatList Performance with Variable Screen Widths

A detail that often gets missed in resolution update discussions: changes to screen width affect how React Native computes layouts inside FlatList grids. iPhone Air's non-standard 420pt width can push layout calculations into paths that weren't exercised before, occasionally triggering extra recomputation cycles.

The most reliable performance optimization for grid views is implementing getItemLayout. This tells React Native the exact size and position of each item in advance, allowing it to skip measurement entirely during scroll.

const ITEM_HEIGHT = DEVICE.thumbnailHeight + 4; // height + vertical margin
 
<FlatList
  data={wallpapers}
  numColumns={DEVICE.gridColumns}
  keyExtractor={(item) => item.id}
  getItemLayout={(_, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * Math.floor(index / DEVICE.gridColumns),
    index,
  })}
  renderItem={({ item }) => <WallpaperThumbnail item={item} />}
/>

For getItemLayout to work correctly, all items must have the same height. Since DEVICE.thumbnailHeight is derived from DeviceConfig.ts, the value stays consistent as long as the centralized config is what drives the layout.

In Beautiful HD Wallpapers, adding getItemLayout to the main wallpaper grid eliminated the scrolling jank that appeared when a user had several hundred wallpapers loaded. The improvement was immediate and required no other changes.

Safe Area and Dynamic Island

Dynamic Island, present in iPhone Pro models since 2022 and now in iPhone Air as well, changes how the top Safe Area inset behaves. The useSafeAreaInsets hook from react-native-safe-area-context returns accurate values that account for Dynamic Island height automatically.

import { useSafeAreaInsets } from 'react-native-safe-area-context';
 
const HomeScreen: React.FC = () => {
  const insets = useSafeAreaInsets();
 
  return (
    <View style={{ flex: 1, paddingTop: insets.top, paddingBottom: insets.bottom }}>
      {/* Content is inset from Dynamic Island and home indicator */}
    </View>
  );
};

The provider setup is required, and Rork-generated code sometimes omits it:

// App.tsx — root component must be wrapped
import { SafeAreaProvider } from 'react-native-safe-area-context';
 
export default function App() {
  return (
    <SafeAreaProvider>
      <RootNavigator />
    </SafeAreaProvider>
  );
}

Without SafeAreaProvider, useSafeAreaInsets returns zeros for everything, which appears to work on most screens but breaks on devices where the notch or Dynamic Island actually overlaps content. When I tested on iPhone Air, insets.top returned 59pt — consistent with other Dynamic Island devices. A quick debug log during development confirms this.

if (__DEV__) {
  console.log('Safe Area insets:', JSON.stringify(insets));
  // Expected output: {"top": 59, "bottom": 34, "left": 0, "right": 0}
}

Splash Screen Configuration

New form factors occasionally cause splash screens to render incorrectly — usually as padding appearing on unexpected sides when resizeMode isn't set to cover.

{
  "expo": {
    "splash": {
      "image": "./assets/splash.png",
      "resizeMode": "cover",
      "backgroundColor": "#000000"
    }
  }
}

With resizeMode: "cover", the splash image scales to fill the screen on any device, cropping at the edges as needed. The design implication is that important visual elements should sit in the center of the splash image, away from the cropping zone at the edges.

I updated all four apps to this configuration in 2025, and no splash screen has needed adjustment for any device since. It's a small investment that compounds over time as each new iPhone generation arrives.

App Store Screenshot Requirements for 2026

Each new iPhone family adds a new screenshot requirement. The four primary device sizes for App Store Connect submissions in 2026 are:

• 6.9-inch (iPhone 17 Pro Max / 16 Pro Max): 1320 × 2868px
• 6.7-inch (iPhone Air): 1260 × 2736px
• 6.3-inch (iPhone 17 Pro): 1206 × 2622px
• 6.1-inch (iPhone 17 / 16): 1179 × 2556px

For four apps with five to ten screenshots each, that's up to 80 images to keep current whenever the UI changes. The only realistic approach at this scale is to build screenshots in a design tool that supports multi-size exports from a single master.

In Figma, I maintain master artboards at the largest size (1320 × 2868px for Pro Max) with UI elements as linked components. Smaller device artboards use the same components scaled down. When the app UI changes, updating one component propagates across all device sizes automatically. The iPhone Air artboard was added by creating a new frame at 1260 × 2736px and linking to the same components — the work took about 20 minutes per app.

Triage: Reading the Symptom Before Touching the Style

When something looks "slightly off" on a new device, editing styles at random tends to fix one device and break another. A fixed order of checks keeps that from happening.

1. Only the top or bottom edge is off — suspect a hardcoded Safe Area value. A leftover paddingTop: 44 should become the value returned by useSafeAreaInsets(). Don't consider it resolved until you've seen it on Dynamic Island hardware.
2. Grid columns or gutters look wrong, but nothing else — that's a width breakpoint. A single width > 400 threshold classifies iPhone Air (420pt) with the Pro Max models. Rather than adding another threshold, store the column count itself in DeviceConfig.ts and let the device category resolve it.
3. Only images crop or letterbox — that's aspect ratio, not layout. Changing resizeMode will always break one device or the other, so for full-bleed surfaces the durable fix is an asset requirement: compositions that hold up at any ratio.

Only when none of the three explains the behavior do I open the individual screen's styles. Having the order fixed in advance is what makes the debugging time predictable.

Syncing the Configuration Across Multiple Apps

When the same layout constants need to stay consistent across multiple Rork projects, a minimal shell script handles the sync without requiring a shared module infrastructure.

#!/bin/bash
# sync_device_config.sh
SOURCE="./src/config/DeviceConfig.ts"
TARGETS=(
  "../beautiful-wallpapers/src/config/DeviceConfig.ts"
  "../ukiyoe-wallpapers/src/config/DeviceConfig.ts"
  "../relaxing-healing/src/config/DeviceConfig.ts"
  "../law-of-attraction/src/config/DeviceConfig.ts"
)
 
for target in "${TARGETS[@]}"; do
  cp "$SOURCE" "$target"
  echo "Synced: $target"
done

Run this script when DeviceConfig.ts changes. It's simple and auditable — you can see exactly what changed in each app's repo history.

Running several apps in parallel, I keep arriving at the same principle: reduce the surface area of change. Device-specific constants in a centralized file, splash screens configured to handle any aspect ratio, screenshot templates that scale without redesign — each is a decision made once that keeps paying back on every future update.

Simulator vs. Device: What Each One Can Actually Tell You

The simulator will show you layout drift, image cropping, font rendering, and how many columns a grid resolves to. That covers most of what breaks on a new point size, and it covers it in seconds.

What it will not tell you reliably: how the Dynamic Island interacts with a floating header in practice, what the home indicator margin actually looks like against a full-bleed image, how scrolling behaves under memory pressure, and whether the wallpaper-setting flow completes. Those need hardware.

For devices you don't own, TestFlight beta testers are the practical answer. When asking, narrow the request to one or two lines — which screen, which orientation, what to look for. A vague "does it look OK?" comes back as "looks fine"; a specific "does the header overlap the island on the detail screen?" comes back as a screenshot.

Finding Resolution-Dependent Code Before You Start

The hardest part of a device update isn't the fix — it's not knowing where the assumptions live. Four patterns account for nearly all of them.

Direct dimension reads (Dimensions.get('window').width, useWindowDimensions) are the obvious ones. Platform branches (Platform.select, Platform.OS === 'ios') often hide an implicit device assumption inside them. Magic numbers inside StyleSheet.create — width: 393, height: 120 — are values that were correct for exactly one device. And fixed paddingTop / marginBottom values are usually a Safe Area inset someone hardcoded instead of measuring.

One command surfaces most of them:

grep -rn "Dimensions.get\|useWindowDimensions\|width: [0-9]\{3\}\|height: [0-9]\{3\}" \
  src/ --include="*.tsx" --include="*.ts" | grep -v "node_modules"

Across the four apps this returned more than seventy hits before consolidation. Afterwards it returned fewer than fifteen, and the remainder were imports and type definitions rather than live assumptions. That number is a useful proxy: the lower it is, the shorter next year's update will be.

PixelRatio and the Actual Pixels You're Shipping

Points are what layout code deals with, but image assets are consumed in real pixels. On iPhone Air, 1pt renders as 3px, so a 420pt × 912pt logical screen is 1260px × 2736px of actual display. If your assets were cut for a 393pt device, they're being upscaled on the widest full-screen surfaces — which is precisely where a wallpaper app gets judged.

PixelRatio converts between the two:

import { PixelRatio } from 'react-native';
 
const logicalWidth = SCREEN_WIDTH;   // iPhone Air: 420pt
const pixelWidth = PixelRatio.getPixelSizeForLayoutSize(logicalWidth);
// 1260px (420 x 3)
 
const imageUri = `https://cdn.example.com/wallpaper_${pixelWidth}w.jpg`;

Serving resolution-matched variants from a CDN — 1260px for Air, 1320px for Pro Max — keeps devices from downloading pixels they can't display. The bandwidth saving is secondary; the visible win is that the first paint arrives sooner on the screens where users are looking most closely.

Where to Start

If you're working through a similar update, begin by finding every place in your project that reads from Dimensions.get('window') directly.

grep -rn "Dimensions.get\|useWindowDimensions" src/ --include="*.tsx" --include="*.ts"

If that returns more than five results, consolidating those into a central DeviceConfig.ts will pay off immediately. The iPhone Air case is a good forcing function: it's different enough from prior devices to break conditional logic, but similar enough in aspect ratio that many full-screen layouts look fine at first glance. The subtle breakages — grid thumbnail misalignment, sub-pixel rendering issues in image lists, Safe Area assumptions — are worth tracking down and fixing before users on new devices file reviews about them.

Thanks for reading — I hope this helps you get ahead of the next new iPhone before it arrives.