結論から書きます。
AIがデザインし、コードを書いたアプリが、
普通に App Store / Google Play の審査を通り、普通に公開できました。
特別な裏技も、ゴリ押しもありません。
ただし、放っておいてできた話ではありません。
AIには、日本語で相当うるさく指示しています。
「FlutterだとAppleの審査が厳しい」は本当か？
今でもよく聞きます。
FlutterだとAppleの審査が厳しいのでは？
結論から言うと、まったく問題ありませんでした。
- 特別な対策なし
- ネイティブ実装への書き換えなし
- 余計な説明のやり取りなし
ごく普通に申請して、ごく普通に審査を通過しています。
Appleが SwiftUI / UIKit を推奨しているのは事実です。
でも、それは Flutterを否定している という意味ではありません。
Appleが見ているのは、
- どう作ったか
ではなく - 何ができて、どう感じるか
UIの品質とユーザー体験が良ければ、フレームワークで差別されません。
UIを良くすると、コードは汚くなる
ここで、一つ認めなければいけないことがあります。
UIを良くしようとすると、コードは汚くなります。
- padding の微調整
- 色の細かい指定
- レスポンシブ対応
- 端末ごとの調整
全部、コードを冗長にします。
でも、ユーザーが見るのはコードではなくUIです。
Appleの審査も、コードを読むのではなく実際に触って体験します。
「綺麗なUI」と「綺麗なコード」は、基本的に両立しません。
どちらを取るかと言われたら、ユーザーに届くのはUIです。
「ロジックとUIを分離せよ」は、個人開発では間違い
一般的に言われます。
ロジックとUIは分離すべき
個人開発では、これは間違いだと思っています。
Flutterは宣言型UIです。
「この状態なら、こう表示する」を書く世界。
状態と表示は、最初から一体になっています。
無理に分離すると、かえって読みにくくなる。
そもそもこの原則は、
- ロジックを書く人
- UIを書く人
が別だった時代の名残ではないでしょうか。
個人開発なら、分ける理由がありません。
共通化しない。DRYを捨てる
もう一つ、捨てた常識があります。
DRY（Don't Repeat Yourself）です。
共通化すると
- 依存が生まれる
- 共通部品を変えると複数箇所が壊れる
- コードを追う範囲が広がる
共通化しないと
- 似たコードは増える
- でも、それぞれ独立している
- 一つ直しても他に影響しない
- 壊れたら、そこだけ直せばいい
AIを使う開発では、これが特に重要です。
AIにとって問題なのは「書く量」ではありません。
いくらでも書けます。
問題になるのは 「読む量」 です。
共通化すると、依存が増え、
AIが追うべき文脈が分散します。
重複を恐れない。
効率より、独立性を取る。
ただし、全部を捨てるわけではない
もちろん問題もあります。
同じロジックが複数箇所にあると、
- 仕様変更
- バグ修正
で全部直す必要が出てきます。
なので、重要なロジックだけはサービスに切り出します。
結論：AIにうるさく言うのは、この2つだけ
1. 重要なロジックはサービスに切り出して管理する
AIはコードを書くのは得意です。
でも、アプリ全体を俯瞰するのは苦手です。
- API呼び出し
- データ変換
- ビジネスルール
こうした部分はサービスに切り出し、
「ここだけは間違えるな」とうるさく管理します。
2. UIは、実際に動かしてうるさく言う
AIがUIを完璧に作るのは、まだ無理です。
UIはコードで管理するものではなく、
実際に触って、納得できるまで修正させるもの。
これはAppleの審査と同じです。
最後に
今回公開したアプリはこちらです。
70歳の個人開発者が、AIと一緒に作ったアプリです。
Flutterで開発した初めての本格的なアプリですが、それでも、普通にストア審査を通り、普通に公開できました。
次回は、
Flutterでの具体的な実装例と、個人開発向けのプロンプトを紹介します。
ご意見・ご要望があれば、ぜひ聞かせてください。