Rork で作った iOS アプリを iPhone Air と 17 Pro シリーズに対応させる — 2026年の解像度ごとのレイアウト調整パターン

デバイス別レイアウト定数を一箇所で管理する

最初は各画面コンポーネントに if (width === 420) のような分岐を直接書いていました。しかしそれでは変更箇所が散らばってしまいます。私が最終的に採用したのは、デバイス別の定数を DeviceConfig.ts として一元管理する方法です。

以前、複数の画面に三項演算子が29箇所以上散らばっていた状態から、このファイルに集約したことで、次の機種対応は1ファイルの変更で完結するようになりました。

// 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;

DEVICE オブジェクトをアプリ全体で参照すれば、解像度関連の分岐を各コンポーネントに書く必要がなくなります。型定義（DeviceProfile）を明示しておくことで、新しいデバイスを追加したとき、プロファイルに必要なフィールドが欠けていると TypeScript がエラーを出してくれます。これが地味に助かります。

壁紙アプリ特有のフルスクリーン表示問題

壁紙アプリを作っていると、「画像をいかにきれいにフルスクリーン表示するか」は最重要課題の一つです。iPhone Air の幅 420pt という中途半端な数値がここで問題になります。

従来の壁紙画像は多くの場合、標準解像度（393pt × 852pt 相当）または Plus/Max 系（440pt × 956pt 相当）向けに最適化されていました。iPhone Air（420pt × 912pt）はこのどちらでもありません。フルスクリーン表示での resizeMode の選択が重要になります。

// ❌ アスペクト比が崩れる
<Image
  source={{ uri: wallpaperUrl }}
  style={{ width: SCREEN_WIDTH, height: SCREEN_HEIGHT }}
  resizeMode="stretch"
/>
 
// ✅ 壁紙アプリで推奨：全面を覆う
<Image
  source={{ uri: wallpaperUrl }}
  style={{
    position: 'absolute',
    top: 0,
    left: 0,
    width: SCREEN_WIDTH,
    height: SCREEN_HEIGHT,
  }}
  resizeMode="cover"
/>

resizeMode="cover" は画面全体を覆うように画像を拡大・縮小しますが、画像の端が少し切れることがあります。壁紙アプリとしては通常これが望ましい挙動です。iPhone Air の場合、縦横比（420:912 ≈ 0.46）が標準機（393:852 ≈ 0.46）とほぼ同じため、cover モードでの見た目の差は最小限です。

一方、グリッド一覧のサムネイル表示は要注意です。幅に依存する計算をしていると、デバイスごとにサムネイルの高さや余白がずれます。

// サムネイルサイズの動的計算（DeviceConfig を活用）
import { DEVICE, SCREEN_WIDTH } from '../config/DeviceConfig';
 
const GUTTER = 8;
const THUMBNAIL_WIDTH = (SCREEN_WIDTH - GUTTER * (DEVICE.gridColumns + 1)) / DEVICE.gridColumns;
const THUMBNAIL_HEIGHT = DEVICE.thumbnailHeight;

Beautiful HD Wallpapers では、グリッドのサムネイルに整数ピクセルを使うことで、画像の僅かな滲みを防いでいます。React Native では Math.floor() か PixelRatio.roundToNearestPixel() でポイントを整数化しておくのが安全です。

Safe Area と Dynamic Island の実装

2022年以降の iPhone Pro シリーズに搭載された Dynamic Island は、従来の notch とは Safe Area のインセット値が変わります。iPhone Air にも Dynamic Island が搭載されているため、safeAreaTop の値が機種ごとに異なる可能性があります。

react-native-safe-area-context の useSafeAreaInsets が最も確実な取得方法です。

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,
      }}
    >
      {/* コンテンツ */}
    </View>
  );
};

注意点は、SafeAreaProvider でアプリのルートをラップしないと動作しないことです。Rork が生成するコードでは、このプロバイダーが欠けていることがあります。

// App.tsx のルートコンポーネントを必ずラップする
import { SafeAreaProvider } from 'react-native-safe-area-context';
 
export default function App() {
  return (
    <SafeAreaProvider>
      {/* ナビゲーション・画面コンポーネント */}
    </SafeAreaProvider>
  );
}

iPhone Air での実機テストで確認したところ、insets.top は 59pt でした。iPhone 17 Pro でも同じ値です。この確認はデバッグビルドで console.log を仕込んでおくのが手軽です。

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

壁紙の詳細表示画面など「Safe Area も含めてフルスクリーン表示したい」ケースもあります。その場合は insets.top や insets.bottom を考慮せずに表示し、代わりにホームインジケーターや Dynamic Island が表示されてもコンテンツが隠れても問題ないデザインにするのが最もシンプルです。

FlatList と ScrollView のパフォーマンスへの影響

スクロールリストやグリッド表示はほぼすべてのアプリに存在します。解像度対応の文脈でよく見落とされるのが、スクロールパフォーマンスへの影響です。iPhone Air の幅 420pt は中途半端な値のため、FlatList でグリッドを組んでいると、各行のレイアウト計算が既存デバイスと異なるパスを通ることがあります。

特に numColumns と columnWrapperStyle を組み合わせて使っている場合、各列の幅が小数点以下を含む値になると React Native の内部でレイアウトが再計算を繰り返すことがあります。

// ❌ 小数点が出ることがある（iPhone Air で 132.67pt など）
const columnWidth = SCREEN_WIDTH / 3;
 
// ✅ 整数に丸めて安定させる
const columnWidth = Math.floor(SCREEN_WIDTH / 3);
const totalGridWidth = columnWidth * 3;
const horizontalPadding = (SCREEN_WIDTH - totalGridWidth) / 2;

Beautiful HD Wallpapers では、グリッド表示のパフォーマンスを保つために getItemLayout も実装しています。これにより、スクロール位置のジャンプや、大量の壁紙画像リストでのちらつきが大幅に改善されました。

<FlatList
  data={wallpapers}
  numColumns={3}
  keyExtractor={(item) => item.id}
  getItemLayout={(_, index) => ({
    length: THUMBNAIL_HEIGHT + 4,  // 高さ + マージン
    offset: (THUMBNAIL_HEIGHT + 4) * Math.floor(index / 3),
    index,
  })}
  renderItem={({ item }) => <WallpaperThumbnail item={item} />}
/>

getItemLayout を実装するには、全アイテムの高さが一定である必要があります。デバイスごとに THUMBNAIL_HEIGHT を変えている場合は、DeviceConfig.ts から取得した値で計算するようにしてください。

Launch Screen と Splash Screen の対応

新機種のシミュレーターを使って初めて起動したとき、スプラッシュ画面が崩れていることがあります。resizeMode: "contain" を設定していると、iPhone Air の縦横比に合わせた不要な余白が目立つことがあります。

Rork（Expo）の app.json では以下のように設定します。

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

resizeMode: "cover" にすることで、どの解像度でも画面全体を覆う表示になります。ロゴや重要な視覚要素は画像の中央付近に配置するデザインが必要ですが、一度そのテンプレートを作ってしまえば、以後の機種追加でも対応不要になります。

私は2025年に4本のアプリ全てのスプラッシュを cover モードに切り替えました。それ以来、新機種が追加されてもスプラッシュ画面の再設計が必要になったことはありません。小さな事前投資が、毎年の更新コストを削減しています。

App Store スクリーンショットの更新と効率化

新機種が追加されるたびに App Store のスクリーンショット要件が変わります。2026年現在、App Store Connect では以下の主要サイズへの対応が求められます。

• 6.9インチ（iPhone 17 Pro Max / 16 Pro Max）: 1320px × 2868px
• 6.7インチ（iPhone Air）: 1260px × 2736px
• 6.3インチ（iPhone 17 Pro）: 1206px × 2622px
• 6.1インチ（iPhone 17 / 16）: 1179px × 2556px

4本のアプリで各アプリ5〜10枚 × 4サイズ = 最大40〜80枚の更新が必要になります。手動で全て再作成するのは非現実的です。

私が採用しているのは Figma を使ったマスタースクリーンショット管理です。最大サイズ（1320 × 2868px / Pro Max）でマスターを作成し、各機種サイズのフレームをコンポーネントリンクで展開します。アプリの UI に変更があった場合も、マスターコンポーネントを更新するだけで全サイズに反映されます。

Rork プロジェクトで Fastlane が直接使えない場合の代替として、EAS Build でビルドしたアプリを各機種のシミュレーターで起動し、スクリーンショットを取る方法もあります。ただし自動化の仕組みをゼロから構築するコストを考えると、Figma ベースの管理の方が個人開発規模では現実的です。

テスト戦略と機種確認の落とし穴

新解像度のシミュレーターで動作確認するときに注意したいのが、Safe Area の値が実機と異なる場合があるという点です。特に Dynamic Island の挙動は実機でしか確認できないことが多いです。

シミュレーターで確認できること・できないことを整理しておくと、テストの優先順位が立てやすくなります。シミュレーターで確認できるのは、レイアウトの大まかなずれ、画像の切れ方、フォントサイズの表示、グリッドの行列数などです。一方、実機が必要な確認は、Dynamic Island との実際のレイアウト干渉、ホームインジケーター周辺の余白の実際の見た目、高負荷時のスクロールパフォーマンス、壁紙設定機能の実際の動作などです。

実機を持っていない機種は、TestFlight のベータテスターに確認を頼むのが現実的です。Beautiful HD Wallpapers では日本語圏以外の利用も多く、英語・韓国語・スペイン語のユーザーから「この機種で余白がおかしい」という報告が先に届くことがあります。手元にない機種の目は、外から借りるしかありません。依頼するときは「どの画面を、どの向きで見てほしいか」を1〜2行に絞って伝えると、返ってくる情報の精度が上がります。

症状から原因へ — 崩れたときに見る順番

新機種で「なんとなくずれている」と感じたとき、闇雲にスタイルを触ると別の機種を壊します。私は次の順で切り分けています。

1. 上端または下端だけがずれている → Safe Area の値を固定値で書いている箇所を疑います。paddingTop: 44 のようなハードコードが残っていれば、useSafeAreaInsets() の戻り値に置き換えるのが確実な対処です。Dynamic Island 世代の実機で確認するまで解決とみなさないのが安全です。
2. グリッドの列数や余白だけがおかしい → 幅のブレークポイント判定が原因です。width > 400 のような単一しきい値は iPhone Air（420pt）を Pro Max 側に分類してしまうため、機種カテゴリを定数化して回避します。しきい値を増やすより、DeviceConfig.ts に列数そのものを持たせるほうが後々崩れません。
3. 画像だけが見切れる・余白が出る → アスペクト比の問題であり、レイアウトの問題ではありません。resizeMode を変えるとどちらかの機種で必ず破綻するため、フルスクリーン表示では「どの比率でも成立する構図」を素材側の要件にするのが根本的な解決です。

この3つで説明がつかない場合だけ、個別画面のスタイルを読みにいきます。順番を決めておくと、原因の切り分けにかかる時間が読めるようになります。

4本同時対応のワークフロー

4本のアプリのコードベースで DeviceConfig.ts を同期するための簡単なシェルスクリプトを用意しています。

#!/bin/bash
# sync_device_config.sh — 4つのアプリ間で定数ファイルを同期する
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

このスクリプトを新解像度対応のたびに実行するだけで、4本のアプリに同じ変更が反映されます。Rork Max を使って複数アプリを管理している方には、同様のアプローチが効果的だと思います。

複数のアプリを並行して運用していると、何度でも同じ結論に戻ってきます。鍵は「変更の影響範囲をできるだけ小さくすること」。今回の解像度定数の一元管理も、その考え方の延長線上にあります。新機種のたびに触る箇所が1ファイルで済むなら、次の対応にかかる時間はほぼ読めるようになります。

毎年の解像度対応を「短くする」ための考え方

新機種対応をひととおり終えたあとに残るのは、達成感よりも「来年もまた同じことをやる」という感覚です。管理すべき解像度は、標準・Plus・Pro・Pro Max・Air と増え続けていて、減る見込みはありません。

ここで問うべきなのは「作業をなくせるか」ではなく「1回あたりを何分にできるか」だと考えています。解像度対応そのものは避けられません。避けられるのは、対応のたびにコードベース全体を探し回る時間のほうです。

判断の目安として、私は次の3点を見ています。新機種を1機種追加するとき、変更するファイルは何個になるか。変更後に目視確認が必要な画面は何画面か。その確認をシミュレーターだけで終えられるか。この3つの数字が小さいほど、次回の作業は短くなります。今回の対応前は「4本のアプリ × 十数ファイル」でしたが、DeviceConfig.ts に集約したあとは1ファイルの定数追加と、フルスクリーン系の3画面の目視だけで済むようになりました。

Rork でアプリを作ると、最初のバージョンは驚くほど早く形になります。そのぶん、長く運営するアプリでは「地味だが確実に必要な作業」をどれだけ短くできるかが差になります。書いた本人が「どこを変えれば何が変わるか」を即答できる構造にしておくこと。これが、翌年の自分への一番実用的な引き継ぎだと感じています。

既存コードの解像度分岐を見つけ出す

Rork でプロジェクトを作り込んでいると、どこに解像度依存のコードが潜んでいるか見えにくくなります。新機種対応の作業を始める前に、影響範囲を把握する点が肝心です。

解像度に関連するコードを探すための主なキーワードは4種類あります。最初は Dimensions 関連で、Dimensions.get('window').width や useWindowDimensions を使っている箇所が解像度に直接依存しています。次に Platform.select や Platform.OS === 'ios' の中に暗黙的な解像度仮定が埋まっているケースです。3番目は StyleSheet.create の中の固定値で、width: 393 や height: 120 のように特定の機種を想定して書かれたマジックナンバーです。最後は paddingTop や marginBottom に設定された固定値で、Safe Area の代わりに決め打ちされているパターンです。

以下のコマンドで一通り洗い出せます。

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

出力が5件以上あれば DeviceConfig.ts への集約を検討してください。私が最初にこの調査をしたとき、4本のアプリ合計で70件以上ヒットしました。集約後は15件以下になりました（import 文と型定義のみ）。

日本語ユーザーへの特有の考慮点

Beautiful HD Wallpapers や Ukiyo-e Wallpapers では日本語ユーザーが多く、App Store のレビューを読んでいると「新しい iPhone に変えたら壁紙がおかしい」というフィードバックが他地域に比べて多い傾向があります。日本では iPhone の普及率が高く、毎年新機種に買い替えるユーザーが多いため、解像度対応の速さがレビュー評価に直結しやすいです。

Ukiyo-e Wallpapers のように日本文化をテーマにしたアプリでは、縦横比へのこだわりが視覚的品質に大きく影響します。縦長の版画を iPhone Air の横幅が広くなった画面に表示するとき、resizeMode の選択だけでは対応しきれないケースがあります。画像ごとに最適な表示方法をユーザーが選べるオプションを提供することが、日本のアート系アプリでは特に重要だと感じています。浮世絵のような縦長構図と、横長のパノラマ壁紙では求められる表示ロジックが根本的に異なります。そのどちらにも対応できる設計にしておくと、ユーザーの多様な好みに応えられます。

Relaxing Healing のような音楽・ヒーリング系アプリでは、没入感のある画面全体を使ったビジュアルが重要です。iPhone Air の横幅が広くなったことで、背景画像が横長に感じられる場合があります。背景素材はどの比率でも破綻しないデザインで一本化しておくことで、機種別のアセット管理が不要になります。

PixelRatio を使った高解像度対応

もう一つ見落とされがちな観点として、3x Retina 画面での実ピクセル数があります。iPhone Air では 1pt = 3px なので、420pt × 912pt の論理解像度は実際の画面ピクセルでは 1260px × 2736px になります。画像素材をこの実ピクセルサイズで用意しているかどうかが、ズームしたときの鮮明さに影響します。

PixelRatio を使うと、論理サイズから実ピクセルサイズを計算できます。

import { PixelRatio } from 'react-native';
 
const logicalWidth = SCREEN_WIDTH;   // iPhone Air: 420pt
const pixelWidth = PixelRatio.getPixelSizeForLayoutSize(logicalWidth);
// → 1260px (420 × 3)
 
// CDN から解像度に最適な画像を取得する例
const imageUri = `https://cdn.example.com/wallpaper_${pixelWidth}w.jpg`;

Beautiful HD Wallpapers では CDN から解像度別の画像を動的に取得しています。iPhone Air（1260px幅）と Pro Max（1320px幅）で別ファイルを配信することで、不必要に大きな画像をダウンロードせずに済み、表示速度が改善されます。

全体を振り返ってと次のアクション

今回の対応で最も効果があったのは、DeviceConfig.ts のような定数管理ファイルを作成したことでした。コード全体に散らばっていた Dimensions.get('window').width への直接参照を、このファイルからの参照に置き換えるだけで、今後の新機種対応は1ファイルの変更で完結するようになります。

繰り返し実感しているのは、「今の作業が楽になる構造」より「次の作業が楽になる構造」を選ぶほうが割に合う、ということです。解像度定数の一元管理は、作る当初にひと手間かかります。その手間は、新機種が出るたびに少しずつ返ってきます。アプリを長く運営するというのは、こうした地味なメンテナンスを毎年積み重ねることでもあります。その1回を軽くしておくことが、作りたいものに向ける時間を守ることにつながります。

まず試してほしいのは、既存プロジェクトで Dimensions.get('window') を使っている箇所を grep で探し出すことです。

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

この出力が5件以上あれば、一元管理ファイルへの移行を検討する価値があります。同じ課題に取り組んでいる方の参考になれば幸いです。