Rork Companion で動いた画面を、私はまだ完成とは呼びません

壁紙アプリに新しい設定画面を足した夜のことです。Rork Companion で iPhone に送り、指で触れて、余白もスクロールも思ったとおりに動きました。その時点で私は「できた」と口に出しておりました。

段差に気づいたのは翌週です。配布用に組み直したビルドで同じ画面を開くと、見た目は寸分違わないのに、課金の導線だけが反応を返してくれませんでした。実機で動いていたのは確かで、けれど動いていたのは「開発中のビルド」であって、利用者の手元に届くビルドではなかったのです。

最初にお伝えしたいのは、これは Companion の欠点ではないということです。Companion は自分の役割をきちんと果たしています。私の側が、確かめた範囲を実際より広く見積もっておりました。

Companion に入れるまでの三つの操作と、つまずくのはたいてい三つ目

手順そのものは短いものです。

1. Rork のインストール用ページを iPhone の Safari で開きます
2. 表示されたリンクまたは QR コードから Companion を入れます
3. 「設定」→「一般」→「VPN とデバイス管理」で、開発者プロファイルを信頼します

引っかかるのは、ほぼ毎回この三つ目です。「信頼されていないデベロッパ」と出たまま先へ進めない、という相談をよくいただきます。ここで押さえておきたいのは、この表示はエラーではなく、iOS が正しく仕事をしている合図だということです。ストア以外の経路で入ったアプリを、端末の持ち主の明示的な同意なしに起動させない——それが iOS の既定の姿勢です。

もうひとつ、無料の Apple ID で署名された開発用のプロファイルは寿命が短く、数日から一週間ほどで期限を迎えます。昨日まで開けていたアプリが今朝は開かない、というのは壊れたわけではなく、期限が来ただけです。同じ手順で入れ直せば戻ります。

私はこの「入れ直し」を、面倒な作業ではなく、ちいさな棚卸しの機会だと思うようにしております。入れ直すたびに、自分がいま何を確かめようとしているのかを一度言葉にできるからです。

Companion が見せてくれるもの

実機に載せて初めて分かることは、想像よりずっと多くあります。

ここまでを Companion で潰しておけると、その後の作業がずいぶん楽になります。私自身、画面まわりの手直しはほとんどこの段階で終わらせております。

Companion では確かめられないもの

一方で、Companion のままでは答えの出ない問いがあります。私が実際に取りこぼした課金の導線も、ここに含まれます。

通知については、もう一行だけ足しておきます。開発中のビルドと配布ビルドでは通知の配送経路が別になりますので、テスト中にきれいに届いたことは、利用者の端末に届くことをほとんど保証してくれません。私はいま、「通知が届いた」と「本番の経路で通知が届いた」を、別々の日に確かめる別々の項目として扱っております。

表にすると当たり前に見えるのですが、実際の作業中には境目が溶けます。目の前で動いている以上、動いていない可能性を疑うのは、なかなか難しいことです。

「動くか」は Companion が答えられる問いで、「出せるか」は配布ビルドにしか答えられない問いです。 この一行を作業メモの先頭に置いてから、私は同じ取りこぼしをしなくなりました。

画面に「いまどのビルドか」を出しておきます

境目が溶けるなら、溶けないように印を付ければよいのだと考えました。開発中と内部配布のときだけ、画面の隅にビルド情報を出す小さな部品を置いています。

// components/BuildBadge.tsx
import { Text, View } from 'react-native';
import Constants from 'expo-constants';
import * as Application from 'expo-application';
import * as Updates from 'expo-updates';
 
export function BuildBadge() {
  const forced = Constants.expoConfig?.extra?.showBuildBadge === true;
  if (!__DEV__ && !forced) return null;
 
  const lines = [
    `env: ${Constants.executionEnvironment}`,
    `id: ${Application.applicationId ?? '-'}`,
    `ver: ${Application.nativeApplicationVersion ?? '-'} (${Application.nativeBuildVersion ?? '-'})`,
    `channel: ${Updates.channel ?? '(none)'}`,
    `embedded: ${String(Updates.isEmbeddedLaunch)}`,
  ];
 
  return (
    <View
      pointerEvents="none"
      style={{ position: 'absolute', right: 8, bottom: 8, padding: 6, borderRadius: 6, backgroundColor: 'rgba(0,0,0,0.6)' }}
    >
      {lines.map((line) => (
        <Text key={line} style={{ color: '#fff', fontSize: 10 }}>{line}</Text>
      ))}
    </View>
  );
}

読み方を補足します。Constants.executionEnvironment は、いま動いているのがストア配布のクライアント経由なのか、自分で組んだビルドなのかを教えてくれます。Updates.channel は、更新をどのチャンネルから受け取る設定で組まれたビルドかを示し、開発中は値が入りません。Updates.isEmbeddedLaunch が true なら、ビルドに同梱されたコードで起動していて、まだ OTA 更新を受け取っていない状態です。

有効にする条件は設定側に寄せておきます。

// app.config.ts
export default ({ config }) => ({
  ...config,
  extra: {
    ...config.extra,
    showBuildBadge: process.env.SHOW_BUILD_BADGE === '1',
  },
});

こうしておくと、内部配布のビルドを組むときだけ SHOW_BUILD_BADGE=1 を渡せば印が出て、ストアへ出す本番のビルドでは自動的に消えます。

この印は、不具合の報告を受け取るときにもう一度効いてくれます。テストをお願いしている方には、画面の隅の文字ごとスクリーンショットを送っていただくようにしています。以前は「購入ボタンが反応しません」という一文だけを頼りに、違うビルドで一晩再現を試みたことがありました。いまは報告の一行目が、その問いに先に答えてくれます。

以前の私は、この判定を __DEV__ だけで書いておりました。すると内部配布のビルドでは印が消えてしまい、テスターから届いた不具合の報告が、どのビルドの話なのか分からなくなりました。判定の軸を二つに分けたのは、そこで一度困ったからです。

私が通している順番

いまは次の順で確かめています。前の段で終えたことを、次の段でもう一度見ないための区切りでもあります。

意外だったのは、三列目が作業の速さを変えたことです。内部配布の段では余白を見ない、と先に決めておくのは雑に思えて、しばらくは落ち着きませんでした。けれども実際には、一度決着した画面を開き直さずに済み、テストの往復が短くなりました。すべてを見ようとする段は、結局どれも丁寧に見られないのだと思います。

段を分けておくと、不具合が出たときに疑う範囲が狭まります。公開後の配り方については段階的リリースとホットフィックスの進め方に運用の詳細を書いております。ビルドそのものが通らない段階でしたら、先にアプリがビルドできないときの確認事項を見ていただくほうが早いと思います。

無料の範囲でどこまで進めるか、有料プランへいつ移るかで迷っておられる方には、料金プランを実際に使って比べた記録が判断の材料になるかもしれません。

今日できること

もし手元に Companion で動かしているアプリがあるなら、まずビルド情報の表示だけを足してみてください。五分ほどの作業ですが、「いま自分が見ているのはどのビルドか」という問いに、画面の隅がいつでも答えてくれるようになります。

私も最初は勘で切り分けようとして、ずいぶん遠回りをしました。読んでくださってありがとうございました。同じ段差でつまずく方が一人でも減れば嬉しく思います。