Future Tech Blog
フューチャー技術ブログ
Mobileカテゴリ

【PC不要】Cursor + GitHub Actionsを活用してスマホだけでiOSアプリ開発

app_icon_1024x1024.png

1. はじめに

スマホだけでスマホアプリ作れたらカッコよくないですか？楽しそうですよね？

PCを触らずスマホ縛りというルールで開発したアプリは、こちらです。

trim.481CC9C1-352C-460C-9E1E-7A7E94481E0B.gif

リポジトリは、こちら。
https://github.com/yu1Ro5/BabySteps

本記事では、どうやってここまで辿り着いたか紹介します。

こんにちは。HealthCare Innovation Group (HIG) の清水です。夏の自由研究2025のブログリレーの5日目です。普段手をつけられなかったけど、この連載を機にiOSアプリを作ってみました。以前の夏の自由研究企画では、SwiftUIのカスタムアラートダイアログについて考えるという記事を書いていました（2年経つの早い）。

本記事では、Cursor(Background Agents)+GitHub Actionsを使って、ソースコードを書かずに、スマホだけでiOSアプリをApp Storeに公開できるか、というテーマの自由研究をしてみました。

ソースコードは自動生成しましたが、本記事は執筆者によるタイピングで生成しています。

2. 背景と課題

2024年の2月、初めてMacBook Airを購入し、Apple Developer Programにも登録しました。しかし、実際にはMacBookを開いてiOSアプリ開発をしたのはふた月程度で、いつの間にか夕飯の時にYouTubeを見るくらいしか使わなくなっていました。

思い返せばプライベートも忙しくしていたので、充実していたから仕方ないかという言い訳はさておき、気が付けば生成AIのサービス・ツールもたくさん出てきて、出社する日の通勤時間や移動中の空き時間を有効活用してiOSアプリ開発できる世の中になっていました。

そんな中、ちょうどこの自由研究連載があったので、やってみることにしました。作ってみたいアプリがあったので、今回は「終了」ではなく「手をつけた回数」をチェックするTODOリストアプリを作ってApp Storeに公開できるか記事です。

基本的なiOSアプリ開発では、MacBookとXcodeを使って、ビルド・テスト・配布までを行います。これらの課題を解決できれば、移動中でも効率的にアプリ開発ができるのではないかと考えました。

3. 研究テーマの設定

「ソースコードを書かずにスマホだけでiOSアプリをApp Storeに公開できるか？」

これが今回の夏の自由研究のテーマです。

空いた時間に開発することがどれだけ難しいか体験してみようと、MacBookはもちろん、PCを使わずに「スマホだけで」iOSアプリ開発がどこまでできるか挑戦しました。

具体的には、以下の技術的要素に取り組みました。

  1. Cursor: Background Agentsを利用して、Swiftのソースコードを生成する
  2. XcodeGen: iOSアプリのプロジェクト設定をYAML形式で記述し、プロジェクトファイルを自動で生成する
  3. GitHub Actions: macOS イメージのGitHub Hosted Runnnerを利用して、生成されたコードを自動でビルド・テスト・配布するパイプラインを構築する

つまり、人間はアプリの仕様を考えるだけで、あとは全て自動化されたシステムが処理するというフローを目指しました。

うまくいけば、MacBookを買わなくてもiOSアプリ開発ができ、AIエージェントを用いた開発の可能性を自ら検証できるはずです。

4. 技術的課題と解決策

スマホだけで完結させるために、苦労したのが大きく次の5点です。

4.1 ソースコード生成

まず最初に取り組んだのは、どうやってソースコードを書くかという課題でした。

Claude CodeやGemini CLI、Codexなどのエージェントモード使ってソースコードを生成しようとしましたが、それらを動かすマシンのセットアップをする場合、スマホだけで完結しないなと思いました。そこで、DevinやManus AIなど、セットアップ不要で実行環境を気にせず使えるサービスを中心に検討しました。今回は、元々契約していたCursorのBackground Agents機能を利用して、Swiftのソースコードを生成することにしました。

4.2 ビルド環境

次に直面したのは、どこでビルドを行うかという課題でした。

iOSアプリをビルドするためには、通常Xcodeが必要であり、XcodeをインストールするためにはmacOSが必要です。普段は、MacBookにXcodeをインストールしてGUIアプリ上でビルドしていますが、今回はルール上選択できません。自分のMacBookにSSH接続することも考えましたが、スマホ縛りに反すると思い、MacBookを持たない人でもできる方法を考えました。可能な限りコスト掛けずに実現したいと思い、Amazon EC2 Mac インスタンスなど、クラウド環境を用意することは考えませんでした。Xcode Cloud※の利用も視野に入れましたが、スマホだけでセットアップすることは難しいと考えて選びませんでした。今回はGitHub ActionsのmacOS イメージを使用することで、Xcode環境が整った状態でビルドを行うことにしました。GitHub Actions の使用は、パブリックリポジトリの標準の GitHub ホステッドランナーの場合は無料1なので、存分に使う方針を取っています。

※Xcode Cloudについての記事はこちら。

4.3 ビルド方法

ビルド方法についても検討が必要でした。Xcodeから新規にプロジェクトを作成すると、{プロジェクト名}.xcodeprojというをプロジェクトファイル含んだフォルダを生成します。ファイルにはプロジェクトの設定情報が格納されているのですが、とても書けるものではありません。Xcode上で操作した結果（ファイルの並び順だったり、ビルドの設定だったり）が保存されているものなので、通常書くものではありません。Xcodeを使わずにXcodeのプロジェクト設定ファイルを生成する必要があります。今回は、XcodeGenを使用することで解決しました。XcodeGenを使うことで、プロジェクト設定をYAML形式で管理し、CI/CDパイプラインでの自動生成を行うことにしました。

4.4 動作確認

ソースコードを書き、実行環境を用意し、アプリがビルドできるようになったのですが、実態は見知らぬクラウドマシン上でiOSアプリがビルドされるようになっただけで、アプリがどうなっているか確認することはできません。この構成でアプリがどうなっているか確認するためには、次の2つの方法が思いつきました。

  • ①UITestを実装して、想定する動きになっていることを確認する
  • ②アプリをTestFlightにリリースして、手元のiPhoneにインストールする

UITestを書いて、動作が想定通りか確認したり、UITestで取得したスクリーンショットをPullRequest上に添付するワークフローを作成したり、CI上で完結する①を試みました。しかし、ボタンの位置変更やアニメーションの待機時間など、UIの些細な変更で頻繁に失敗する（フリーキーになりやすい）というUITestを画面なしでデバッグすることが難しすぎたので、途中から②に切り替えました。（最初から②でよかった）

②については、[iOS]Github Actionsを使用してプッシュ時にビルドを行いtestflightへ配信する | DevelopersIOを参考に、GitHub のSecretsにApp Store Connect APIキーなどの情報を登録して、デプロイするワークフローを整えました。

4.5 審査準備

最後に、App Storeでの審査への対応も自動化する必要がありました。TestFlightにリリースしたアプリを審査に提出するため、連絡先やアプリ名、対象年齢などのアプリに関する情報を登録する必要があります。必須項目でひと手間かかったのが、スクリーンショットとプライバシーポリシーURLです。

4.5.1 アプリのスクリーンショット

アプリを審査に提出するためには、最低1枚スクリーンショットを提出する必要があります2。この時、どんなサイズでもいいわけではなく、サイズの指定があります3。iPhoneだと6.5インチサイズのスクリーンショットを、iPadだと13インチのスクリーンショットを提出しなければなりません。手元のiPhone 15 Proは、6.3インチなので要件に合わず、iPadはそもそも持っていませんでした。そのため、CI上で要件にあう機種のシミュレータを立ち上げて、スクリーンショットを取り、それを提出することにしました。普段ならUITest上で任意の操作をさせて、撮りたい画面を残すことができますが、前述した通り画面なしでデバッグすることは既に心が折れている状態でした。そこでxcrun simctlコマンドを使い、シミュレータを直接制御してアプリ起動後のスクリーンショットを取得することにしました。これでUITestを使わずに要件を満たすサイズのスクリーンショットを（その場しのぎ的に）取得することができました。作成したワークフローは、こちら。次のxcrun simctlコマンドを利用して、スクリーンショットを取得しています。

# iPhone 16 Pro Maxシミュレータを起動
xcrun simctl boot "iPhone 16 Pro Max" || echo "iPhone simulator already booted"

# シミュレータが完全に起動するまで待機
echo "Waiting for iPhone simulator to fully boot..."
sleep 10

# アプリをインストール
xcrun simctl install booted "build/Build/Products/Debug-iphonesimulator/BabySteps.app"

# アプリを起動
xcrun simctl launch booted com.yu1Ro5.BabySteps

# アプリが完全に起動するまで待機
echo "Waiting for app to fully launch..."
sleep 8

# スクリーンショットを撮影
xcrun simctl io booted screenshot "screenshots/iphone_6.5inch.png"

アップロード時に気付いたのですが、iPhone 16 Pro Maxは6.5インチではなく、6.9インチでした。しかし、6.9インチのスクリーンショットがあれば縮小版が使用される仕様のため、6.9インチがあればOKでした。

要件
アプリがiPhone対応で、かつ6.9インチのディスプレイ用スクリーンショットを提供しない場合は必須
注
規定サイズのスクリーンショットが提供されない場合は、6.9インチディスプレイ用のスクリーンショットの縮小版が使用されます。

4.5.2 プライバシーポリシーページ

審査提出の最後のハードルは、プライバシーポリシーページです。審査提出のためにプライバシーポリシーURLが必須項目になっている＝プライバシーポリシーページの用意が必要です。初めて作るため、何を書いて良いのやらという状態でしたが、「個人・法人を問わず、どなたでも自由にご利用いただけます（商用利用可）。」である次のページの雛形を参考にさせていただきました。（2025/08/29時点）

https://kiyaku.jp/index.html

内容は決まってもホスティングする方法を決めなければいけません。ここまで全てGitHub Actionsでやってきたので、ここも同様にGitHub Actions & GitHub Pagesで作成しました。使ったことはなかったのですが、①リポジトリの設定を操作し、②リポジトリのトップにdocs/フォルダを作成して、index.htmlを配置するだけでプライバシーポリシーページを公開することができました。

これらの課題を解決することで、App Store審査への準備も完全に自動化できるようになりました。

6. 成果と結果

6.1 完成したアプリ

今回の研究で完成したアプリは、こちらです。審査提出をゴールとしていたため、タスクと着手回数の登録と約3ヶ月分の着手回数を色で可視化する2画面だけ実装しています。

trim.481CC9C1-352C-460C-9E1E-7A7E94481E0B.gif

6.2 自動化パイプライン

構築した自動化パイプラインにより、以下の作業が自動化されました。

  1. Cursor Background Agentでソースコードを生成
  2. GitHub Actionsで自動ビルド・テスト・デプロイ
  3. 審査提出のための、（最低限の）スクリーンショットの自動生成
  4. プライバシーポリシーページの公開

6.3 App Store審査への提出

成果として、ソースコードを書かずに審査提出まで完了し、記事執筆時点では「審査待ち」です。（App StoreのURLを載せたかったですが、間に合わず。）

スクリーンショット_2025-08-30_18.59.42.png

6.4 自由研究の結果

「ソースコードを書かずにスマホだけでiOSアプリをApp Storeに公開できるか？」

この研究テーマに対して、AIエージェントによる実装とCI/CDの組み合わせにより、macOSマシンが手元になくても、移動中でも、iOSアプリ開発ができることを確認しました。

7. やってみての感想

良かったこと

  • 通勤時間や移動中にアプリ開発する環境の整え方を学べたこと
    • 当初の目的は叶えられたと思います
    • なんだかんだ言ってやれてなかったアプリ開発が技術の進歩によって、どこにいてもできるようになって楽しいです
  • 自前でmacOSマシンを用意せずに、スマホ縛りで審査提出までできたところ
    • 前述の通り、通常はiOSアプリをビルドするためにmacOSマシンが必要なのですが、macOSマシンがなくてもiOSアプリ開発ができることを確認しました
    • MacBook　Air 1台でも、15万円以上するので買わずにリリースできるのはコスト的に大きいかなと思います
  • 実際にアプリが動いたこと
    • 技術ブログ執筆駆動で久しぶりに自分だけのために開発した気がします。楽しかった。（ソースコード書いてないが）

大変だったこと

  • CIのビルドエラーを解消すること
    • 今回、実行環境はGitHub Actionsのワークフロー上でやっていたため、アプリのビルドやTestFlightリリースなどのコマンドを手元で試すことができなくて辛かったです
    • エラーをコピーして貼り付けるだけじゃ解決しないときは、参考になるページのURLも添付してあげるとうまくいくケースがいくつかありました。指示とセットで成果物イメージ渡すのは大事
  • Cursor Background　Agentsの内部エラー
    • 基本的に、Background Agentsに指示を出す→diffを確認して方向性を修正する→（CIとか通って）問題なさそうであればマージするフローで進めていました
    • 会話の途中でエージェント側の作業環境（≠GitHub Actions）のエラーに遭遇し、「lsコマンドも使えない。ファイルが読み込めないからこの操作をしてほしい」と言われることがありました
    • こうなると回避することが基本できなかったので、そこまで話した内容を要約してもらって新しいチャットで試すとうまくいくケースが多かったです。（原因は深掘りできておらず）
  • ソースコード読みづらすぎる
    • ここが一番大変でした。物理的に難しい
    • スマホを横回転させても全体を把握できず、とにかく読みづらすぎました
    • 大体は、書いたコードをチャット上で説明させて、エラーになっているような大事な箇所は自分で読む、というような役割分担で何とかしてきました

8. さいごに

今回は連載をきっかけに、Cursor(Background Agents)+GitHub ActionsでiOSアプリ開発からApp Store公開までできるかという自由研究に挑戦してみました。審査提出まで辿り付けたので、自由研究は成功したことにしてしまおうと思います。

最近、生成AI時代に、なぜ技術ブログを書くのかという記事が公開されました。整理すると私も「スキルアップ」や「セルフブランディング」に属すような理由で書いている気がしますが、今回の自由研究連載のように「執筆を機になかなか試せていなかった新しい技術に触れる」ことも技術ブログを書く理由かなと思いました。

記事書き終わったので、スマホ縛り解いてアプリをブラッシュアップしたいと思います！わーい！