Rork のドキュメントで Expo のページを開いたとき、本文より先に黄色い警告枠が目に入りました。そこには、Rork では Expo(React Native)のプロジェクトを新しく作れなくなった、と書かれておりました。
驚いたのは、その次の一文のほうでした。すでに Expo プロジェクトを持っている方は、これまで通りビルドも公開も GitHub へのエクスポートもできる、と続いていたのです。
つまりこれは「動かなくなる」という話ではありません。新しく始める道が閉じただけで、いま走っているものは走り続けます。 そのぶん判断が難しくなります。壊れていないものを、自分の意思で作り直すかどうかを決めることになるからです。
私自身、個人開発で長く同じアプリを運用しておりますので、この種の選択がいちばん手が止まるところだと感じております。ここでは、何が変わって何が変わっていないのかを整理したうえで、続けるか作り直すかを自分の条件で決めるための材料をお伝えします。
いま変わったこと、変わっていないこと
まず一次情報を確認いたします。Rork のドキュメントの「What happened to Expo?」には、新しいアプリは iPhone なら Swift、Android なら Kotlin、Web なら React になる、と明記されております。切り替えた理由も書かれており、社内のベンチマークでエージェントが React Native よりも良い Swift のコードを書いたから、というものでした。
同じページには、Expo も本物のネイティブのスタックであり、多くの本番アプリがその形で出荷されている、という一文も添えられております。Expo を否定する書き方にはなっておりません。
| 項目 | いまの扱い |
|---|---|
| Expo プロジェクトの新規作成 | できません |
| 既存 Expo プロジェクトのビルド | これまで通りできます |
| 既存 Expo プロジェクトの公開 | これまで通りできます |
| GitHub へのエクスポート | これまで通りできます |
| 新規 iPhone アプリ | Swift(SwiftUI) |
| 新規 Android アプリ | Kotlin |
| 新規 Web アプリ | React |
ひとつ、正直に書き残しておきたいことがあります。この切り替えがいつ行われたのか、ドキュメント本文には日付が入っておりません。 Rork のドキュメントは本文に日付を持たない形式ですので、「いつから」を断定できる材料が手元にないのです。ですので本記事では、時期ではなく現在の状態だけを扱います。
「作り直す」を選ぶと、プロジェクトの形そのものが変わります
ドキュメントは、既存の Expo プロジェクトについて Swift へ移すことを推奨しております。プレビューの隣に「Add iOS app」というボタンが出ており、押すとエージェントが画面・ナビゲーション・データの流れ・デザインを SwiftUI で作り直します。Android は、プレビュー上部の「+」から Kotlin のアプリを足す形です。
ここで大事なのは、元の Expo アプリが消えないことです。同じプロジェクトの中に残りますので、並べて見比べられます。
そして、作り直したあとのプロジェクトは次のような構造になります。
- コードベースは2つになります。iPhone は Swift、Android は Kotlin で、同じファイルではありません
- バックエンドは1つのままです。Rork Cloud や Supabase を使っていれば、両方のアプリが同じデータベースを見ます
- チャットと文脈も1つです。「両方にダークモードを足して」という依頼が、それぞれのアプリに届きます
- 公開の窓口も1つで、App Store・Google Play・Web を同じ Publish メニューから扱えます
ドキュメントはこのあと、目を引く一文を置いております。二つのアプリはずれていく可能性がある、というものです。Swift の変更は Kotlin の変更とは別のファイルですので、同期を保つ役目はエージェントが担うことになります。React Native の共有コードベースとは、そこが違います。
この一文は、都合の悪いことを隠していない書き方だと感じました。そして私にとっては、判断の核心もここにありました。
個人開発で iOS と Android を並行して触っていた時期に、同じ文言の修正を片方にだけ当てて、しばらく気づかずにいたことがあります。機能の違いなら気づけるのですが、文言や余白や並び順のずれは、両方を同時に開かないかぎり見えません。ずれは壊れないので、誰も教えてくれないのです。 それに気づいたのは、たまたま両方を並べて開いた日でした。
判断を分ける四つの問い
続けるか作り直すかは、機能の優劣では決まりませんでした。次の四つで分かれると考えております。
| 問い | 「続ける」に傾く答え | 「作り直す」に傾く答え |
|---|---|---|
| Android も出していますか | 出している、または出す予定がある | 当面 iPhone だけ |
| いま出荷を止められますか | 審査や告知の予定が詰まっている | 次の更新まで間がある |
| ウィジェット・Live Activities・センサー系が要りますか | 当面は要らない | いま必要、または近く必要 |
| コードを自分で読み書きしていますか | エクスポートして自分で手を入れている | ほぼエージェントに任せている |
三つめについて補足いたします。ドキュメントの比較ページでは、Swift ならホーム画面のウィジェット、Live Activities、高度なモーションやボディトラッキング、AR、ゲームの描画性能、センサーへの細かいアクセスといった領域に届く、と説明されております。ここに用事がある方にとっては、作り直しは遠回りではなく近道になります。
逆に、Android を並行して出していて、しかもコードを自分で触っている方の場合、二つのコードベースを持つ負担が先に来ます。Rork Max と標準版のどちらが要るかという判断は、料金ではなく必要な機能の棚卸しで決まるという話をRork Max が要るかどうかは、料金表ではなく権限の棚卸しで判断できますに書きました。今回の判断も、考え方の筋は同じです。
作り直す前に、いまの画面を棚卸ししておきます
作り直しを選ぶとしても、押す前にやっておくことがあります。いまの画面の一覧を、自分の手元に持っておくことです。
エージェントは画面を再構築してくれますが、再構築できたかどうかを判定するのは私たちの側です。そして判定には、突き合わせる相手が要ります。
エクスポートした Expo プロジェクトで、次のように書き出しました。
# Expo プロジェクトの画面(ルート)一覧を書き出します
# 突き合わせ表の材料になるので、作り直しを押す前に取っておきます
cd path/to/exported-expo-project
find app -name '*.tsx' -not -name '_*' \
| sed 's|^app/||; s|\.tsx$||; s|/index$||' \
| sort > screens.txt
wc -l screens.txt期待する出力は、次のような1行です。
14 screens.txt
ここからもう一歩進めます。画面名だけでは足りないからです。
# 画面ごとに、確認する4つの状態を並べた表にします
# 列: 通常表示 / 中身が空のとき / 通信が失敗したとき / 権限を断られたとき
while read -r r; do
printf '%s\t未確認\t未確認\t未確認\t未確認\n' "$r"
done < screens.txt > rebuild_checklist.tsv
head -3 rebuild_checklist.tsv出力はこうなります。
(tabs)/home 未確認 未確認 未確認 未確認
(tabs)/settings 未確認 未確認 未確認 未確認
detail/[id] 未確認 未確認 未確認 未確認
なぜ四つの状態まで並べるのかをお伝えします。作り直しで抜け落ちるのは、画面そのものではないからです。画面は目立ちますので、無ければすぐに気づきます。抜けるのは画面と画面のあいだにある処理のほうでした。
壁紙アプリを作り直したときに最後まで気づかなかったのは、通信が切れているときの表示でした。一覧は出ます。詳細も開きます。ただ、電波の無い場所で開いたときに何も言わない画面になっておりまして、それを見つけたのはずいぶん経ってからでした。目で追える不具合より、何も起きない不具合のほうが長く残ります。
この表を作っておけば、作り直したアプリを開きながら一つずつ埋めていけます。四つの列が全部埋まるまでは、まだ移し終わっていないと考えるようにしております。
どちらを選んでも、先に GitHub へ出しておきます
続けるにしても作り直すにしても、先にやっておくと安心できることがひとつあります。いまの Expo のコードを GitHub へ出して、印を付けておくことです。
# 作り直す前の状態に、あとから戻れる印を付けます
git tag expo-before-swiftui-rebuild
git push origin expo-before-swiftui-rebuild
# 印が付いたことを確認します
git tag --list 'expo-*'出力はこうなります。
expo-before-swiftui-rebuild
タグを打つ理由は、戻すためというより、見比べるためです。SwiftUI 側で「この挙動は元からこうだったか」と迷ったとき、確実に当時のコードを開ける場所がひとつあるだけで、迷う時間が短くなります。
なお、エクスポートしたコードを最初に git へ入れるときは、git init より先に .gitignore を用意しておくほうが後の手間が減ります。この手順はRork のコードをエクスポートしたら、git init より先に .gitignore を用意しますにまとめました。SwiftUI へ移したあとのビルドから配信までの流れは、Rork Max でネイティブ iOS アプリを作るが近い内容になっております。
私なら、こう決めます
いま Expo プロジェクトを持っていて、Android も出していて、次の更新が近いのであれば、私は当面続けます。動いているものを止める理由が、まだ足りないからです。
一方で、iPhone だけを出していて、ウィジェットや Live Activities に用事があり、次の更新まで間があるのであれば、作り直す側に傾きます。同じプロジェクトの中に Expo 版が残るというのは、思っていたより大きな安心でした。片道ではないのです。
そして、どちらを選ぶにしても先に決めておきたいことがあります。移すかどうかより、移したあとに何を見比べるかを先に決めます。 この順番だけは、急いでいる日ほど崩さないようにしております。
まずは手元の Expo プロジェクトで app ディレクトリのルート一覧を書き出して、四つの列を付けた表にしてみてください。作り直すかどうかは、その表を眺めてからでも遅くありません。
最後までお読みくださり、ありがとうございました。同じところで迷っている方の、手を動かす最初の一歩になれば嬉しく思います。