Rork の共有リンクで配布前に実機差分を潰す手順 — プレビューで気づけない不具合の検証順

まず潰すべき7つの実機差分（検証の順番）

検証は、影響が広く修正コストが低いものから順に当てます。以下の順で見ていくと、後工程での手戻りが減ります。

1. セーフエリアとノッチ／Dynamic Island

最初に見るべきは画面の四隅です。上端のタイトルがノッチや Dynamic Island に潜り込む、下端のボタンがホームインジケータと重なる、という崩れはプレビューの1サイズでは気づけません。react-native-safe-area-context のインセットを使い、固定値の余白を避けます。

2. 権限プロンプトの初回タイミング

通知やカメラ、トラッキングの許可を起動直後に求めると、文脈のないまま拒否されがちです。実機で「いつダイアログが出るか」を必ず体験します。価値を見せた後に求める設計へ寄せるだけで、許可率は目に見えて変わります。

3. ディープリンクとコールドスタート

共有リンクや通知から特定画面へ飛ばす場合、アプリが完全に終了した状態（コールドスタート）からの復帰が最も壊れやすい箇所です。起動中のリンクは拾えてもコールドスタートだけ取りこぼす、という非対称がよく起こります。

4. 電波の弱い状態とオフライン

機内モードや地下鉄を想定し、通信が切れた状態で各画面を開きます。ローディングが永遠に回り続ける、エラーで真っ白になる、という挙動は実機でしか出ません。オフライン時の表示を一つ用意しておくだけで体感品質が上がります。

通信が「ある」状態だけでなく、「遅い」状態も忘れがちです。電波はつながっているのに応答が数秒返らないとき、ボタンを連打したユーザーが二重送信してしまう、という不具合は弱電界の実機で初めて見えます。送信中はボタンを無効化し、応答待ちの状態を画面に出す。この一手間を配る前に入れておくと、後から届く「反応しない」という報告の多くを未然に防げます。

5. キーボードによるレイアウト崩れ

入力欄をタップしたときに、キーボードが送信ボタンを覆い隠していないかを確認します。Android と iOS でキーボードの挙動が違うため、両方の実機で触る価値があります。

6. ダークモードと文字サイズ拡大

端末をダークモードにし、システムの文字サイズを最大付近まで上げて開きます。文字が枠からはみ出す、背景と文字のコントラストが消える、といった崩れは、アクセシビリティ設定を上げたユーザーの実機で初めて見えます。

7. 低スペック Android の体感速度

最後に、できるだけ古い Android 端末で開きます。一覧のスクロールがカクつく、画像の表示が遅れる、といった体感差はハイエンド機やプレビューでは絶対に出ません。私はここで一番多くの修正点を見つけてきました。

共有リンクを配る前にコードで仕込んでおくこと

検証で崩れを見てから直すより、配る前に守りのコードを入れておくほうが手戻りが減ります。Rork が生成する React Native（Expo）のコードに、以下のような土台を足しておきます。

セーフエリアは固定余白ではなくインセットで取ります。

import { useSafeAreaInsets } from 'react-native-safe-area-context';
import { View } from 'react-native';
 
export function ScreenContainer({ children }) {
  const insets = useSafeAreaInsets();
  return (
    <View
      style={{
        flex: 1,
        paddingTop: insets.top,
        paddingBottom: insets.bottom,
        paddingLeft: insets.left,
        paddingRight: insets.right,
      }}
    >
      {children}
    </View>
  );
}

権限は起動直後ではなく、価値を体験してもらった後に求めます。

import * as Notifications from 'expo-notifications';
 
// 例: お気に入りを1件保存した直後など、文脈のある瞬間に呼ぶ
export async function askNotificationWhenRelevant() {
  const current = await Notifications.getPermissionsAsync();
  if (current.granted) return true;
  if (!current.canAskAgain) return false; // 二度目は OS が出さない
  const result = await Notifications.requestPermissionsAsync();
  return result.granted;
}

ディープリンクは、コールドスタートと起動中の両方を取りこぼさないように二系統で受けます。

import * as Linking from 'expo-linking';
import { useEffect, useState } from 'react';
 
export function useIncomingLink() {
  const [url, setUrl] = useState(null);
  useEffect(() => {
    // コールドスタート時の初期 URL
    Linking.getInitialURL().then((initial) => {
      if (initial) setUrl(initial);
    });
    // 起動中に届くリンク
    const sub = Linking.addEventListener('url', (event) => setUrl(event.url));
    return () => sub.remove();
  }, []);
  return url;
}

オフライン検知を1か所に集約し、各画面が同じ判定を参照できるようにします。

import NetInfo from '@react-native-community/netinfo';
import { useEffect, useState } from 'react';
 
export function useOnline() {
  const [online, setOnline] = useState(true);
  useEffect(() => {
    const unsub = NetInfo.addEventListener((state) => {
      setOnline(Boolean(state.isConnected && state.isInternetReachable));
    });
    return () => unsub();
  }, []);
  return online;
}

この4つを土台に入れておくと、共有リンクでの検証は「崩れを探す作業」から「想定どおり守れているかの確認」に変わります。

iOS と Android で割れやすい挙動の優先順位

同じコードでも、iOS と Android で結果が割れやすい箇所は決まっています。共有リンクを両 OS の実機に配るとき、次の優先順で見ると効率的です。

Android の物理戻るは特に見落とされがちで、モーダルを閉じるつもりがアプリごと終了してしまう、という事故が起きます。私は配布前に必ず、各画面で戻る操作だけを連打して挙動を確かめるようにしています。

検証ログをどう残すか（個人開発での回し方）

一人で開発していると、検証は頭の中で済ませがちです。けれども共有リンクは複数人に配れるので、フィードバックが断片的に返ってきます。私の場合は、端末・OS バージョン・画面・症状の4項目だけを1行で書き留める簡単なメモに集約しています。凝った課題管理は要りません。むしろ軽いほど続きます。

返ってきた報告は、前述の7項目のどれに当たるかで仕分けます。同じ症状が複数端末から来たら、それは個別の不具合ではなく実機差分の構造的な穴です。私は壁紙アプリの段階公開でこの仕分けを習慣にしてから、ストアのレビューで不具合報告を受ける回数が明らかに減りました。AdMob のような広告表示まわりも、実機差分が体感品質に直結するので、同じログに混ぜて追っています。

次の一歩

まずは手元の Rork プロジェクトで共有リンクを1本だけ作り、古い Android 端末を1台用意して、上の7項目を上から順に触ってみてください。最初の1台で見つかる崩れの多さに、検証の費用対効果を実感できるはずです。私自身もここで毎回学び直していて、配布前の数十分が、公開後の数日分の対応を肩代わりしてくれると感じています。