いまの運用の前提
iOS と Android の壁紙アプリを2014年から個人開発で運用してきました。累計5,000万DLという規模になっても、コードを書くのはずっと一人です。ここ数ヶ月は、Rork で素早く立ち上げる新規案件と、Claude on Xcode で既存ネイティブ iOS アプリを手当てする案件が、机の上に同時に並んでいます。
その並行運用を始めて1ヶ月ほど経った時点で、それぞれの「合う仕事」「無理をさせない方が良い仕事」がだんだん見えてきました。今回はその所感を、お盆前のメンテ作業の合間に整理した手帳の余白から拾い直しています。
どちらも残したまま使う、という選択
最初はどちらか一方に統一しようと考えていました。Rork でクロスプラットフォームに寄せれば、iOS と Android の両方を同じソースで保守できます。一方で Claude on Xcode に集約すれば SwiftUI 一本に統一できて、Apple のエコシステムに密着できます。
ですが2週間ほど触ってみて、私の場合は両方を残す形が一番無理なく回ることに気づきました。
理由は単純で、「新規に1から作るアプリ」と「既に App Store に出ている既存アプリ」では、求められる作業の質が違いすぎたからです。同じ AI 補助でも、向き合う相手が違えば手の入れ方が変わる、という当たり前の話に落ち着きました。
Rork が向いていると感じた場面
新規の壁紙アプリを試作する段階では、Rork に明確な強みがあります。
要件をプロンプトで伝えると、Expo Router を前提にした画面遷移、AsyncStorage を使ったローカル保存、AdMob のバナーとインタースティシャル、それから App Store / Google Play 双方の同時リリースを意識した構成が、最初から組み込まれた状態で立ち上がります。
私が「30個目以降の壁紙アプリ」と数えている案件群では、構造の8割は前作と同じです。Rork はその「同じ部分」を毎回ゼロから書かせない仕掛けが、肌で感じられるくらい効いていました。
具体的な数字を残しておきますと、1作目を要件入力からビルドが通る状態まで持って行くのに、以前は丸2日かけていた工程が、Rork だと半日で抜けられるようになりました。AdMob のメディエーション設定や Crashlytics の dSYM 連動はあとから手当てが要りますが、それは Rork の領分から少し外れた話です。
加えて気持ちの面でも、Rork は「新しい棚に最初の本を置く」ような身軽さで触れます。新規アプリは0から1の段階で迷いが多く、コードに手を入れる前に画面が動くのを見たい場面が続きます。Rork のプレビューが速いことは、私の場合は技術的な利点と同じくらい、気分の上で重要な要素でした。
Claude on Xcode に任せたくなった場面
一方で、すでに何年も運用している既存ネイティブ iOS アプリの保守には、Claude on Xcode の方が手に馴染みます。
理由は、コードベースが SwiftUI と UIKit の混在で、独自の Coordinator パターンや古い Objective-C のヘッダが残っているからです。ここで Rork に「再生成」させる発想は危険で、過去のユーザーレビューや課金導線をすべて壊しかねません。
Claude on Xcode を使うと、現状のファイル構成を保ったまま、変更したい1ファイルだけにフォーカスして手を入れられます。Xcode のビルドエラーをそのままチャットに貼って原因と修正案を相談する流れが、私の場合は一番事故が少ない作業手順になりました。
ここ1ヶ月で印象に残った仕事は、iOS 26 の挙動変更に追従したフォアグラウンド通知周りの修正です。Claude on Xcode はリリースノートを参照しつつ、UNUserNotificationCenter のデリゲートに付け足すべき条件分岐を出してくれて、その場で Cmd+R して挙動を確認できました。同じ流れを Rork に持ち込もうとすると、Expo ベースの再構築を提案されてしまいます。
// Claude on Xcode が提案して、その場で取り込んだ条件分岐の一部
func userNotificationCenter(
_ center: UNUserNotificationCenter,
willPresent notification: UNNotification,
withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void
) {
if #available(iOS 26.0, *) {
completionHandler([.banner, .list, .sound])
} else {
completionHandler([.alert, .sound])
}
}たった数行ですが、こうした「既存コードの文脈に正しく合わせる」修正こそ、ネイティブ保守の現場で一番欲しい支援でした。
「使い分けの境界線」を私はこう引いています
1ヶ月運用したうえで、自分の中ではこういう線引きに落ち着いています。
- 新規アプリ・モックの確度を上げる段階 → Rork
- 既存ネイティブ iOS アプリの保守・微調整 → Claude on Xcode
- AdMob のメディエーション周りや App Store Connect の手作業 → Claude in Chrome（参考）
特に最後の AdMob 関連は、UI の自動操作という別軸の作業なので、Rork でも Claude on Xcode でも担当外でした。各ツールに「向いている粒度」があるという当たり前の感覚を、運用しながら学び直した1ヶ月でした。
並行運用のために自分が決めたこと
道具を複数持つと、迷う回数も増えます。私は迷いを減らすために、3つだけルールを置きました。
- 朝の最初の30分は「今日の作業はどちらの机に乗せるか」だけを決める時間にする
- 1日の中で両方を使う時は、午前 = Rork、午後 = Claude on Xcode と物理的に時間で割る
- ビルドが通らないまま2時間悩んだら、その日はもう片方の作業に切り替える
特に3番目は、宮大工だった両祖父から自然と受け取った「手を止めず、向きを変える」という感覚に近いところがあります。一つの道具にしがみつくよりも、向きを変えて作業を続ける方が、結果としてアプリの完成度が上がる場面が多くありました。
ツール選定で大事にしている感覚
もう一つ書き添えておきたいのは、ツール選定で大切なのは「速さ」よりも「壊さないこと」だという感覚です。1年以上動いている既存アプリには、レビューや課金履歴、ユーザー層といった、コードの外側に積み上がった文脈があります。新しい AI が来るたびにそれを壊さないように、いま何をしてくれるかではなく、いま何をしないでいてくれるか、で道具を見るようになりました。
これから取り組みたいこと
並行運用が形になってきたので、次に試したいのは「両方の成果物を1つのリリースに束ねる」運用です。具体的には、Rork で構築した新規アプリのメニュー画面のテーマを、既存ネイティブアプリの設定画面に Swift Package として持ち込み、デザインのトーンを揃える試みです。
これはまだ着手段階で、来月の更新でうまくいったかどうかを、また同じ温度感で書き残せればと思っています。
道具に正解はなく、組み合わせて使う中で、自分の運用ルールが少しずつ磨かれていく感覚があります。同じように両方を試そうとされている方の参考になれば嬉しいです。お読みいただきありがとうございました。