⬡ 開発ツール/2026-06-27中級

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

Rorkのエディタプレビューは整った環境で動くため、実機でしか出ない不具合を見逃しがちです。共有リンクで配布する前に潰しておきたい7つの実機差分と検証の順番、事前にコードへ仕込んでおく仕掛け、検証ログの残し方までを実体験からまとめました。個人開発での回し方も紹介します。

Rork⁵³⁹ React Native²²⁷ Expo¹⁷⁵ 実機テスト¹³ アプリ配布

✦ プレミアム記事

Rork で作ったアプリをエディタのプレビューで触っているときは、だいたい何も問題が起きません。ところが共有リンクを知人に渡して実機で開いてもらうと、上端がノッチに隠れていたり、通知の許可ダイアログがいきなり出て驚かれたり、という報告が返ってきます。プレビューは整った1台の環境で動くのに対して、共有リンクの先にあるのは世代も画面サイズもバラバラな実機だからです。

私自身、壁紙や癒し系の小さなアプリを個人開発で長く運用してきましたが、配布前の実機差分を軽く見たまま App Store や Google Play に出してしまい、レビュー欄で初めて不具合に気づいた苦い経験が何度もあります。共有リンクはその差分を「ストアに出す前」に拾える数少ない仕組みです。ここでは、リンクを配る前に潰しておきたい実機差分を、検証の優先順位とともに整理します。

エディタのプレビューと実機の間に落ちる不具合

プレビュー環境は、いわば最高条件のテスト機です。電波は安定し、画面は1サイズ、権限はすでに付与済み、メモリも潤沢です。この条件下では通る画面遷移が、電波の弱い古い Android では固まる、ということが平気で起こります。

落とし穴は、プレビューが「動いた」という体験を作ってしまう点にあります。動くものを見ると、人は検証を終えた気になります。けれども実機で初めて発火するコードパス、たとえばコールドスタートからのディープリンク復帰や、権限が拒否された後の分岐は、プレビューでは一度も実行されていません。ここを意識して検証の順番を組むことが、配布前の精度を決めます。

共有リンクで何が検証できて、何ができないか

Rork の共有リンクは、ビルドを丸ごと回さずに実機で挙動を確かめられる軽量な手段です。iOS と Android のフルビルドや審査提出の前に、複数の実機で同じ画面を触ってもらえるのが最大の利点です。レイアウト崩れ、初回起動フロー、権限ダイアログのタイミングといった「見ればわかる」差分は、ここでほぼ拾えます。

一方で、共有リンクで再現しにくい領域もあります。プッシュ通知の実配信、課金トランザクション、バックグラウンド処理、ストア固有のレビュー挙動などは、最終的にビルドや TestFlight・内部テストでの確認が必要になります。共有リンクは万能ではなく、「ビルドを消費する前に拾える差分を先に潰す関所」と位置づけるのが現実的だと考えています。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦エディタプレビューでは再現しない7種類の実機差分と、検証する順番

✦共有リンクを配る前に仕込む SafeArea・権限・ディープリンクの実装パターン（コード付き）

✦iOS と Android で割れやすい挙動の優先度表と、個人開発での検証ログの回し方

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

まず潰すべき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 の実機に配るとき、次の優先順で見ると効率的です。

確認項目	割れやすさ	主に見る OS
戻る操作（物理/ジェスチャー）	高	Android 物理戻る
キーボード回避レイアウト	高	iOS / Android 両方
セーフエリアの下端余白	中	iOS ホームインジケータ
権限ダイアログの文言と頻度	中	iOS（ATT が独立）
フォント表示と行間	中	Android（端末フォント差）
スクロール慣性とリスト速度	低〜中	低スペック Android

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

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

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

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

次の一歩

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