iOSとAndroidどちらから作る？個人開発で見る六つの判断材料

どちらから作るかは、使いたい言語やフレームワークの好みでは決まりません。決まるのは、誰に使ってもらうかと、自分が確認できる環境を持っているかです。

私が実際に見た材料は六つです。上の三つは利用者側の条件、下の三つは自分側の条件です。片方だけで決めると、どちらかで詰まります。

• 最初に使ってほしい人の端末。
• カメラ、通知、ウィジェットなど必要なOS機能。
• 両方に出したときに、問い合わせを二つ分受けられるか。
• 自分が持っている検証端末。
• Swift、Kotlin、Flutterなど現在の経験。
• 公開後に両方を更新できる時間。

材料を並べたら、条件から候補を引きます。ここで気をつけているのは、国全体のシェアではなく、最初に使ってもらう相手の端末を見ることです。

最初の利用者は、たいてい自分の周りにいます。声をかけられる範囲にiPhoneしかいないなら、Androidから作っても感想が返ってきません。作ったあとに確かめられないものは、作る順番を後ろにしています。

このサイトで公開しているアプリは、いまのところすべてiOSだけです。そう決めた理由は二つあります。

一つは実機です。手元にあるのはiPhoneだけでした。シミュレータでは、通知の届き方、権限を求めるダイアログの出る順番、課金の画面、そして実際に外へ持ち出したときの挙動が確かめられません。位置情報を使うアプリでそれを飛ばすと、審査へ出す前に自分で気づけない不具合が残ります。

もう一つは審査です。私は一度、App Store の Guideline 4.3(b) で却下され、アプリのコンセプトごと作り替えました。指摘の読み方、どこを直せば通るのか、返信にどう書くのか。これは回数を重ねないと身につかない種類の知識でした。同じ学習を二つのストアで同時に進めるのは、一人だと重すぎます。

⚠️ だから私は、Google Play の審査については書きません。出したことがないので、比べる材料を持っていないからです。厳しいとか緩いといった評判は読みましたが、読んだだけのことを経験として書くのは避けています。

この判断の弱いところも書いておきます。iOSだけで進めると、Androidにしかいない利用者の反応が最後まで分かりません。私は「最初に確かめたいのは機能が使われるかどうかで、OSの違いは後で足せる」と考えてiOSを選びましたが、これは仮説です。

実機と審査のほかに、あとから効いてきたことがもう一つあります。OSの機能に寄りかかった場所が、移すときの重さになることです。いま出している位置情報のアプリは、ログインをAppleのサインインだけにしています。自分で会員情報を持たないので、退会の導線もパスワードの再発行も作らずに済みました。そのぶん、別のOSへ出すなら、同じ体験を別の方法で用意することになります。

これは失敗ではなく、意図してそうした選択です。一人で作るなら、持たなくて済むものは持たないほうが安全でした。ただ、片方を選ぶという判断は、こういう形で実装の中にも入っていきます。技術の選択とOSの選択は、あとから見ると同じ判断でした。

共通コードで書ける部分が多くても、OSごとに確かめ直すものは残ります。「一つのコードで両方出せる」と「一度の確認で両方終わる」は別のことです。

OSごとに分かれるのは、だいたい画面の外側です。権限を求める画面の文言と出る順番、通知の許可の扱い、課金の仕組みと復元、ストアの登録情報と審査、そして画面サイズと安全領域。どれもアプリの中心機能ではないので、実装しているときは意識に上がりません。

見積もるときは、実装量ではなく下の一覧の項目数で数えるようにしています。共通化で減るのは実装で、増えるのは確認と運用です。

下の一覧の最後にある問い合わせ窓口は、見落としやすいところです。ストアには連絡先を登録する欄があり、そこへ書いたURLは審査でも見られます。アプリが二本になると、届いた連絡をどちらのことか判別する手間も増えます。私はサイト側に窓口をまとめて、アプリごとに分けずに受けています。

• 権限のダイアログ：文言・出る順番・拒否されたあとの画面。
• 通知：許可の求め方、切られたときの案内。
• 課金：商品の登録、購入、復元、サブスクの解約導線。
• ストア：登録情報、スクリーンショットの規格、審査の受け答え。
• 画面：安全領域、戻る操作、文字サイズを大きくしたとき。
• 問い合わせ：窓口とサポートURLを、ストアごとに用意する。

片方を選ぶのは、もう片方を捨てることではありません。ただ、将来のために今の実装を複雑にするのも違うと考えています。

私がやっているのは一つだけで、データの持ち方と外部とのやりとりを、OS固有の都合で決めないことです。保存する形式や日付の扱いを片方のOSの型に寄せると、あとで移すときに読み替えが必要になります。

逆に、やらないと決めたこともあります。使うかどうか分からないOS向けの抽象化を先に用意すること。まだ書いていないほうのコードのために作った層は、たいてい形が合いません。必要になったときに作るほうが早かったです。

ここまで書いた上で、塞がない範囲には限りがあるとも思っています。OSの機能を使わずに作ると、その機能を使う意味が無くなります。私は、中心の価値に関わるところは寄りかかってよい、それ以外は寄りかからないという線を引いています。判断の記録だけは残しておいて、移すときにどこを作り直すか分かる状態にしています。

進む条件は日付ではなく状態で決めています。中心の機能が実際に使われた、重い不具合が落ち着いた、両方を更新する時間を確保できた。下の三つが揃うまでは片方に置いています。全体の流れは個人でアプリを作るには？企画から公開までの七段階と止まる場所、機能の絞り方はMVPとは？最初のアプリで機能を絞る方法と、外れたときの扱いに分けて書きました。

個人開発はiOSとAndroid、どちらから作るのがおすすめですか？

手元に実機があるほうからです。おすすめできる基準を一つだけ選ぶならこれになります。実機が無いOSは、審査へ出す前に自分で確かめられない部分が残ります。どちらも持っているなら、最初に使ってもらう相手の端末で決めます。

市場シェアで決めてはいけませんか？

最初の一本では効きにくい材料だと考えています。最初に感想をくれるのは周りの数人で、国全体の比率とは一致しません。確かめられない相手に届けても、次に何を直すか決まりません。

FlutterやReact Nativeを使えば、この判断は不要になりますか？

実装の判断は軽くなりますが、公開と運用の判断は残ります。権限、通知、課金、ストアの登録と審査、問い合わせ窓口はOSごとに必要です。共通化で減るのは実装量で、確認と運用の量は減りません。

Androidのほうが審査が通りやすいと聞きました。

私は出したことがないので書きません。App Store は却下と作り直しまで経験しましたが、比べる相手の経験がない状態でどちらが厳しいかを書くと、読んだだけの話になります。

あとからもう一方へ広げるのは大変ですか？

実装の移植より、確認と運用が増えることのほうが重いと見ています。上に並べた項目を二つ分やることになります。広げる前に、片方の更新にかかっている時間を測っておくと見積もれます。

いつAndroid版に着手すればいいですか？

日付ではなく状態で決めています。中心の機能が実際に使われた、重い不具合が落ち着いた、両方を更新する時間を確保できた。三つ目が抜けると、両方が古くなります。

最初に作るOSを間違えたら、やり直しになりますか？

データの持ち方と外部とのやりとりをOS固有の都合で決めていなければ、画面から作り直すぶんで済みます。逆に、保存形式を片方の型に寄せていると、そこが一番重くなります。

Appleのサインインだけにすると、Android版で困りませんか？

困る前提で選んでいます。自分で会員情報を持たないと、退会やパスワード再発行を作らずに済むかわりに、別のOSでは同じ体験を別の方法で用意することになります。片方に寄せた判断は、こういう形で実装の中に残ります。

実機を持っていないOSは、シミュレータで代わりになりませんか？

中心の機能までは確かめられます。確かめられないのは、通知の届き方、権限を求める画面の出る順番、課金の実際の流れ、そして外へ持ち出したときの挙動です。位置情報を使うアプリでは、この最後が一番効きました。

この記事では、OSごとの利用者数や収益の比較を書いていません。私はiOSだけで公開していて、比べる相手のデータを持っていないからです。

クロスプラットフォームのフレームワークどうしの比較も書いていません。全部を使い比べたわけではないので、使っていないものについては書かないと決めています。判断に必要なのは、どれが優れているかよりも、上に並べた「二度必要になる作業」を自分が抱えられるかどうかでした。

最後に、この記事の結論は「iOSから作れ」ではありません。私の手元にあった実機がiPhoneだったという、取り換えのきかない条件が一つあったという話です。Androidを持っている人が同じ材料を並べれば、答えは逆になります。