iOSアプリ開発進捗

iOSアプリ開発がぼちぼち進んでおり、ようやくテストフライトも可能となり、初めての審査を出しました。

最初はリジェクトされると思いますが、とりあえずここまで来れたということでひと段落。

詰まったところも色々あったので備忘録としてまとめてみます。

apple developer programのアクティベート

画面に沿って登録はできるのですが、支払い完了後におよそ48時間かかりました。

しかもapple developer programのアカウント画面に行くとpurchaseが押せる状態で待つことになるので、本当に支払いできているのか？　というプレッシャーと戦うことになります。

大体48時間後にアクティベートされました。

expoを使ってシミュレータを動かして問題なかったのですが、いざテストフライトを開始したら実機で動かない事態に。

アプリを開くと真っ白になる状態でした。

エラーの中身を確認すると、firebaseのsparkプランが実機では動かないそうです。

blazeにアップグレードが必要でした。従量課金が恐ろしかったのですが、見込みとしては無料枠の10%以下しか使わない計算だったので、アップグレードしています。

やっぱり脆弱性が怖いです。とにかく怖い。

バイブコーディングやってて一番怖いのはこれだし、これが乗り越えられなくて公開できない人もかなり多そうです。

firebaseへの不正アクセス、悪意のあるツールでの連続書き込みなどを防ぐ方法を取らなければ無限に課金をしてしまうことになります。

この辺りを終盤に実装したのですが、うまく動かすことに1.5日くらいかかりました。

不正利用防止の機能の一つとしてapp checkを使っていますが、これがシミュレータでうまく動かなかったりなど、ユーザーが操作する部分ではないところで詰まることが多かったです。

この辺りは、実装しても見た目が変わったり動くものが変わったりするわけではないので、面白くないと感じる人も多いかも。でも、非常に重要。

今回のアプリ開発で学んだことは、ユーザーが直接体験する機能要件よりも、ユーザーと開発者を保護する、ユーザー体験を見えないところでサポートするような非機能要件の設計・実装が難しいこと。しかし、もしかするとアプリ開発やサービス開発の肝要ってここにあるのではないか？　ということでした。

バイブコーディングはすごいです。とりあえず動くものをパッと作れます。

基本的にVS codeのcodexにコードを書かせていますが、CLIを使ったらもっともっと楽になるんでしょうね。

作業はほとんどコピペですが、判断しなければならないところは出てきます。

例えば今回のapp checkの導入もそうです。データベースが攻撃されるという考えがなければ、こんな大変なものは導入しないでしょうし、思いつきもしません。

そもそもapp checkを入れよう、というプロンプトさえ出てきません。

定期的に「リポジトリ全体を見渡して、脆弱性があるか検討して」や「効率よく書けるコードにならないか検討して」「保守性を上げるためにhooksを使ってviewと分けて」など、ほんの少しでもマシな開発になるような配慮は必要になります。

特に、生成AIは一つのファイルに機能もビューもベタ打ちで作ってくることが多い（CLIは違うのかも？）ので、そのまま進めたら後から大変なことになるという予見ができないと、本当に大変なことになるでしょう。

知識はなくとも動くものを作れるのがバイブコーディングですが、やっぱり本職エンジニアがAIを使って開発するのとでは、開発スピードと成果物の品質に天と地の差が生まれるのでしょうね。

審査の進捗もしくはリリースができれば、また記事をまとめてみます。