アプリのアイデアを説明すると、Lovable が形にしてくれました。ユーザーはブラウザで使っています。次は App Store に出したい。これは別の仕事であり、Lovable 自身もそう説明しています。
結論から
Lovable が公開するのは Web アプリです。ネイティブ iOS アプリにするには、Web アプリをラップするか、React Native で作り直すか、SwiftUI で作り直すかのいずれかです。Rork、Bolt と Expo、Xcode と AI エージェント、AirBuild は、それぞれこのどれかのルートを取ります。違いは、何が出力されるか、誰がアプリをビルドして提出するか、誰が App Review に対応するかです。
Lovable でできること、できないこと
Lovable の公開に関するドキュメントは、iOS についての疑問に直接答えています。Lovable が作るのは Web アプリで、公開は常に Web の URL にデプロイされます。URL は yourproject.lovable.app か、独自ドメインです。プロジェクトをパッケージして App Store に提出する組み込みの仕組みはありません。
同じページでは、スマートフォンに近づける方法が 2 つ紹介されています。
- プログレッシブ Web アプリ(PWA)。 ユーザーがサイトをホーム画面に追加し、全画面で開きます。PWA だけでは App Store に出せるパッケージにはなりません。掲載するには、ラップするかネイティブアプリとして作り直す必要があります。
- Capacitor によるラッパー。 Lovable の外で公開 URL をネイティブのシェルで包み、そのシェルを自分で提出します。
Lovable は、React Native のプロジェクトを生成しないことも明記しています。React Native アプリが必要な場合は、Lovable で画面のプロトタイプを作り、Lovable の外で作り直すよう勧めています。また、Lovable のモバイルアプリはスマートフォンからプロジェクトを作るためのもので、プロジェクトをユーザー向けのアプリに変えるものではありません。
これは欠点ではありません。対象範囲がはっきりしているということです。問題は、App Store に届くまでに何を足すかです。
「ラップすればいい」が賭けになる理由
Apple の App Store Review ガイドラインは、セクション 4.2 で最低ラインを定めています。
ガイドライン 4.2 最低限の機能
「アプリには、Web サイトを再パッケージしただけのものを超える機能、コンテンツ、UI が必要です。特に有用でも独自でもなく、“アプリらしく”もないアプリは、App Store にふさわしくありません。」
公開 URL を読み込むだけのシェルは、4.2 に抵触するおそれがあります。審査で見られるのは、Web サイト以上に有用な機能、コンテンツ、UI があるかどうかです。中で使われている技術ではありません。Apple はラッパーアプリの承認率を公表していないため、結果を事前に知る方法はありません。確かなのは、却下されると審査がもう 1 回増えることです。ラップするなら、ネイティブ機能もあわせて計画してください。承認は当然ではなく、勝ち取るものと考えましょう。4.2 をはじめ、提出前に確認したい項目は、App Store Review ガイドラインのわかりやすい解説にまとめています。
5 つのルートを並べて比較
| ルート | 得られるもの | App Store までの道のり | Android にも対応? |
|---|---|---|---|
| Lovable + ラッパー | ネイティブのシェルに入った Web アプリ | Lovable の外でシェルをビルドし、自分で提出する | 対応。同じラッパーを使う |
| Rork | React Native と Expo(Rork Pro)、または SwiftUI(Rork Max) | 公開機能を内蔵。Rork Pro には Expo アカウントも必要 | Rork Pro は対応。Rork Max は iOS のみ |
| Bolt + Expo | Expo を使った React Native アプリ | 自分のコンピュータで EAS CLI を使ってビルドし、提出する | 対応 |
| Xcode + AI エージェント | あなたとエージェントが書いたコード。通常は Swift と SwiftUI | アーカイブ、アップロード、提出をすべて自分で行う | 非対応 |
| AirBuild | ネイティブの SwiftUI アプリ | AirBuild が掲載情報を用意し、提出し、App Review に対応する | 非対応。AirBuild はネイティブ iOS に特化 |
どのルートでも、アプリを公開するには Apple Developer Program のメンバーシップが必要です。
1. Lovable を使い続け、ラッパーを足す
今あるものから最短で進めるルートです。Capacitor は自らを Web アプリ向けのクロスプラットフォームなネイティブランタイムと説明しています。Web のコードがネイティブのコンテナ内で動き、デバイスの機能はプラグインで使います。
向いているケース: Web アプリそのものが製品で、ネイティブプロジェクトを保守できるデベロッパがいて、Web サイト以上のアプリにするためにネイティブ機能を加える準備がある場合。
トレードオフ: 画面は引き続き、ブラウザエンジンが描画する HTML です。ネイティブプロジェクト、署名、アップロード、審査はすべて自分の担当です。前述の 4.2 のリスクも、自分で管理することになります。
2. Rork
Rork の FAQ では、2 つの製品が紹介されています。Rork Pro は React Native と Expo でクロスプラットフォームのアプリを作ります。Rork Max は、クラウド上の実機の Mac で Xcode を使ってネイティブの SwiftUI アプリをコンパイルし、iPhone、iPad、Apple Watch、Vision Pro に対応します。Rork は App Store への公開機能を内蔵していると説明しています。Apple Developer アカウントが必要で、Rork Pro ではビルドに Expo アカウントも必要です。有料プランでは、GitHub との双方向同期でコードをエクスポートできます。提出前にビルドの却下リスクを確認する AI App Store Reviewer も用意されています。
向いているケース: プロンプトから新しいモバイルアプリを作り始めたく、ブラウザで使うビルダーが好みの場合。または、Rork Pro で iPhone と Android を 1 つのプロジェクトから作りたい場合。
トレードオフ: 新しいプロジェクトになり、Lovable のアプリを移行するわけではありません。プランはクレジット制なので、現在の上限は Rork の料金ページで確認してください。
3. Bolt と Expo
Bolt のドキュメントによると、モバイルアプリを依頼すると Bolt は Expo を使い、同じコードで iPhone と Android の両方で動くアプリを作ります。Bolt は、最初のプロンプトで「mobile app」と伝えるよう勧めています。Web 向けに作ったプロジェクトは簡単には切り替えられないためです。プレビューは Expo Go を使ってスマートフォンで行います。
公開は Bolt のエディタの外で行います。ドキュメントには、前提条件として Node.js LTS と Git が入ったコンピュータ、Expo アカウント、Apple Developer アカウントが挙げられています。コードをダウンロードし、EAS CLI をインストールして、ターミナルからビルドと提出を行います。
向いているケース: 両方のプラットフォームが必要で、いくつかのコマンドを実行することに抵抗がない場合。
トレードオフ: 既存の Bolt の Web プロジェクトが、そのままモバイルプロジェクトになるわけではありません。ビルド、ストアの掲載情報、App Review は自分の担当です。すでに Bolt の Web アプリがあるなら、AirBuild に持ち込めます。
4. Xcode と AI コーディングエージェント
Apple 自身のルートです。Xcode 27 では、Anthropic、Google、OpenAI のものを含め、好きなコーディングエージェントとモデルを使えます。Agent Client Protocol に対応したエージェントも使えます。また Apple は、App Store にアップロードするビルドを Xcode 26 以降でビルドするよう求めています。つまり、ネイティブ iOS アプリはどこかの段階で必ず Xcode を通ります。
向いているケース: コードを書ける、または学びたい人で、プロジェクトを完全に管理したい場合。
トレードオフ: Xcode は Mac で動きます。エージェントはコードを書きますが、デベロッパ登録、App Store Connect のレコード作成、プライバシーに関する回答、App Review への返信はしてくれません。この部分は App Store Connect ガイドで順に説明しています。このルートを選ぶなら、エージェント向けの Skill が役立ちます。SwiftUI Agent Skills ガイドをご覧ください。
5. AirBuild
AirBuild は、ネイティブ iOS アプリを作る AI チームです。プロダクト、デザイン、エンジニアリングのエージェントが SwiftUI でアプリを作ります。アプリは TestFlight であなたの iPhone に届き、変更は普段の言葉で依頼できます。準備ができたら、AirBuild が App Store の掲載情報を用意し、提出し、審査を追跡し、審査担当者に返信し、指摘された問題を修正して再提出します。
すでに Lovable のアプリがあるなら、AirBuild に持ち込めます。
リンクを残す
Lovable アプリの公開アドレス、または同期先の GitHub リポジトリ。それに加えて、iOS アプリで何をしたいか、誰のためのアプリかを 1 文で伝えます。
AI チームが SwiftUI で作り直す
エージェントがアプリの画面と操作の流れを読み取り、それをもとにネイティブ iOS アプリを作ります。Web アプリには手を加えず、引き続き Lovable で開発できます。AirBuild は変更を自動で同期することもできます。
iPhone で試す
アプリは TestFlight で届きます。変更は普段の言葉で依頼します。
App Review
AirBuild が掲載情報を用意し、提出し、審査担当者に返信し、指摘された問題を修正して再提出します。
バックエンドはそのままです。アプリの接続先が Lovable Cloud なのか、自分の Supabase プロジェクトなのか、API なのかを AirBuild に伝えれば、それに合わせて iOS アプリを設計します。Mac も Xcode も必要ありません。AirBuild は AI チームを Mac 上でもクラウドでも動かせます。公開には Apple Developer Program のメンバーシップが必要です。コードはあなたのものです。Lovable のコードも、AirBuild がそこから作る SwiftUI プロジェクトも、あなたのものです。
向いているケース: ネイティブの iPhone アプリが欲しく、App Review を任せたい場合。突き返されて自分で対応するのではなく、代わりに対応してほしい場合です。
トレードオフ: AirBuild はネイティブ iOS に特化しているため、Android アプリには向きません。Lovable からのプロジェクト持ち込みはアーリーアクセス中で、ウェイトリストからの招待制です。
選び方
ツールではなく、成果物から考えましょう。バイブコーディングで iOS アプリを作る場合、どのツールでも動くプロトタイプはすぐにできます。ルートを決めるのは、最終的に何が必要かです。
Web アプリで十分
Lovable を使い続けましょう。プログレッシブ Web アプリにすれば、ユーザーはホーム画面に追加できます。
iPhone と Android の両方
React Native と Expo のルートを選びます。Rork Pro か、Bolt と Expo です。ビルドとストアのアカウントは自分で管理することになります。
ネイティブ iPhone、自分でコードを書く
Xcode とコーディングエージェントを使います。すべてを自分で管理し、App Store の作業も自分で行います。
ネイティブ iPhone、コードは書かない
SwiftUI を出力するビルダーを選びます。Rork Max、または App Review のやり取りまで任せたいなら AirBuild です。
どのツールを選ぶ場合も、次の 3 つを確認しましょう。
- コードを持ち出せるか? エクスポートがすべてのプランで使えるのか、有料プランだけなのかを確認します。
- 誰が提出し、誰が App Review に対応するか? ビルドで止まるツールでは、掲載情報、プライバシーに関する回答、却下への対応が自分の担当になります。
- データはどこに置かれるか? Lovable アプリですでに Lovable Cloud や Supabase を使っているなら、そのまま使えるルートを優先します。
この分野のツールを幅広く知りたい場合は、iOS 向け AI アプリビルダーをお読みください。アイデアから承認までの全工程は、AI でアプリを作る方法で紹介しています。
よくある質問
Lovable でネイティブ iOS アプリを作れますか?
いいえ。Lovable のドキュメントには、Lovable が作るのは Web アプリであり、公開は常に Web の URL にデプロイされると書かれています。代わりに、プログレッシブ Web アプリにするか、公開 URL を Capacitor でラップする方法を提案しています。React Native のプロジェクトは生成しません。
iOS アプリを作るなら、最適な Lovable の代替手段は何ですか?
必要な成果物によります。1 つのコードベースで iPhone と Android の両方に対応したいなら、Rork Pro や Bolt と Expo など、React Native と Expo を使うツールを検討してください。ネイティブの SwiftUI アプリが欲しいなら、Rork Max、Xcode とコーディングエージェント、または AirBuild が候補です。
Lovable のアプリをラップしたら、Apple に承認されますか?
アプリによります。ガイドライン 4.2 は、Web サイトを再パッケージしただけのものを超える機能、コンテンツ、UI を求めています。公開 URL を読み込むだけのシェルは、このルールのもとでリスクが高くなります。Apple はラッパーアプリの承認率を公表しておらず、ネイティブ機能を加えても承認が保証されるわけではありません。
バイブコーディングで iOS アプリを作るには Mac が必要ですか?
必ずしも必要ではありません。Xcode は Mac で動くので、Xcode のルートでは Mac が必要です。Rork Max はクラウド上の Mac でビルドし、AirBuild は AI チームを Mac 上でもクラウドでも動かせます。どのルートでも、公開には Apple Developer Program のメンバーシップが必要です。
iOS 版を作っても、Lovable の Web アプリはそのまま残せますか?
はい。どのルートでも Web アプリを停止する必要はありません。AirBuild なら Web アプリはそのままで、引き続き Lovable で編集できます。