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.

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.

Twelve years into maintaining multiple apps simultaneously, the principle I keep returning to is: 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 of these is a decision made once that continues to pay back on every future update.

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.