独学で初めてiOSアプリをリリースした人がこれから独学を検討中の人に向けた記事
ふとiOSアプリ開発者になりたいと思って、実際に1個作ってリリースしたので後学に活きそうな内容を整理していきたいと思います。
はじめに
対象読者
- エンジニアの実務が未経験、もしくは歴浅でモバイルアプリ開発に興味がある。
- モバイルアプリの開発をやりたいけどどのように進めれば良いか分からない。
- iOSアプリ開発初学時に気を付けるべきことがあれば知っておきたい。
使用した技術
- 言語：Swift5
- FW：SwiftUI
- DB：CoreData
作ったアプリ
github
figma
Notion（簡単な仕様など）
審査用に作ったサイト
今回はAPIとの通信を用いずCoreDataを使ったローカルだけで完結するアプリで、ソースコード公開によるセキュリティ的な懸念もないと思うのでgithubも掲載しておきます。
とにかくまずは公開というところを優先したのでソースコードには多くの改善の余地があると思いますが（パッと思いつくものだと共通部分を切り出したり、エラーハンドリングなど）、これから
少しずつ修正版は挙げていきたいと思います。
あとは、ユニットテストのコードもチャレンジしてみたかったのですが、とにかく前に進みたいという気持ちが先行してしまって機を逃してしまったのでテストコードも後々書いていきたいですね。
開発手順
以下は最初から全て実践できた訳ではなく、反省を踏まえて「こういう風に進めるのが良いのでないか？」と思ったことも含めて整理した内容となります。
開発以前にゴール・マイルストーンを決める
「さぁ、早速アプリを作ろう」となる前に「なぜアプリ開発を始めるのか？」というゴールは明確にしておいた方が良いと考えております。
というのも、ゴールが明確になるとその後の行動も自然と決まってくる部分はあるからです。
パッと思いつくのでは下記のいずれかに当てはまるケースが多いのでないでしょうか？
- 技術に対する好奇心がある
- お金を稼ぎたい
- 将来、手に職をつけたいと考えている
- 何か解決したい課題があり、それを解決するのにアプリという形式が最適だった
モバイルアプリ（特にiOS）の個人開発はそれなりの初期投資が必要なので、就職活動の自己分析ではないですが「自分の中でのアプリ開発に対する率直な要求」というのを整理した方が良いと思います。
その方が後々詰まったときにモチベーションを維持できたり、撤退ラインというのも明確になります。
例えば、私がモバイルアプリを自分で作ってみようと思った動機は「"アプリをあの権威あるアップルのストアに出す"という体験への好奇心」、「将来、何か解決したい課題が出てきたときの技術的ソリューションを増やしておきたい」という気持ちからでした。
これが「何が何でもアプリを1つリリースするまでやりきる」という強い意志で迷わず突き進む原動力になったと思っています。
要件定義・設計
個人開発における要件定義とは「各機能の提供したい価値の設定」、設計とは「その機能を実現する方法の設定」という風に解釈しております。
何を作るか・アイデアの考え方
アプリを作るのも「それを使って解決したい何かしらの課題ありき」だと考えておりますが、最初に設定した「アプリ開発の目的」によってここのアプローチは変わってくると思います。
考え方としては下記の記事に書かれている内容が非常に参考になると感じました。
ちゃんと多くの人に使ってもらおうとすると、上記記事で書かれているように
「作ったアプリがお金を払ってでも解決したい課題（バーニングニーズ）に寄り添っている」
という図式が成り立りたつように、じっくり検証する必要があるかと思います。
ただ、記事本文でも書かれている通りユーザーインタビューを実施するのには時間とお金の両面でコストがかかってきます。なので私は、「自分の課題を解決するためのアプリを解決する」という方針で考えました。
というのも、先述したように現段階のゴールは「まずは1つでも自作のアプリを公開すること」となったため、今作ったアプリがヒットするかどうかはそこまで重要でないと考えたからです（もちろんヒットするに越したことはありません）。
事実としていきなり全て手にいれにいく難易度は高いし、いきなり無理して自分の心を折に行くようなことはしなくて良いと思いますし、小さな成功体験を積み重ねていくことが大事だと考えております。
私の反省点
「とにかくまずはアプリを公開する」ということを目標にしていたので、マーケティング面は気にしないと正直割り切っていた部分はあるのですが、こうして記事を書いていると反省を感じる部分もあります。
ソースコードの質やUIについては修正版を挙げていけばどうにかなると思うのですが、コンセプトの失敗は挽回するのが難しいからです。
今回作ったアプリの機能をシンプルに説明すると「カレンダー+ToDoアプリ」なのですが、これをやろうと思った理由は「iOSもAndroidもカレンダーとToDoのアプリが別々で手の痒いところに届かない」と私自身が感じていたからです。
ただ、カレンダーとToDoアプリが一緒になったといっても
- ユーザーのどんな悩みを解決してくれるか分かりづらい
- toCにおいては「アプリ名でバシッと伝えられないから詳細で説明します」=コンセプトの失敗
だと思っています。
なので、今後は
- 汎用アプリでなくより具体的な課題に目を向ける
- タイトル聞いただけで「それ良いね」ってなるようなアプリを目指す
- 課題とフィットするシチュエーションでそのアプリを使ってくれるような動機づけの設計をする
という部分は意識してみたいと思います。
解決したい課題の軸を決める
やりたいことを詰め込もうとすると無駄な工数が膨れ上がる上に、主目的を達成するのに使われない機能を作ってしまうという失敗をしがちです。
なので、解決したい課題は具体的に1本に絞って、あれもこれも機能を載せるのではなく必要ないものは極力削ぎ落としていくという考え方で行くのが良いです。
というのも、Webアプリならまだしもモバイルアプリの場合は「せっかく作っても審査に通らず公開できない」可能性も一定あり、開発工数が無駄になってしまう可能性があるからです。
正直、私もこれを実践できていたとは言い難く、一応審査には通りましたが「タスク管理と実行内容の振り返り」というテーマに焦点を当てると「プロジェクト単位での管理」や「カレンダー機能」を最初から実装する必要はなかったかもしれません。
どんな機能や画面が必要なのかを洗い出す
ここは解決したい課題に沿って必要な機能や画面を洗い出していくだけです。
私はNotionをドキュメントツールとして使い整理しました。
Notionは最近流行っていると思いますが無料でも個人で使う分には十分機能を備えており便利です。（SlackやHerokuみたいに後々有料化されるかもしれませんが）
個人的には下記の機能が便利です。
-
テーブルビュー
テーブルビューという機能はテーブル形式で作った各行を別ページとして開くことができ、「一覧ページ->詳細ページ」の詳細を簡単に作れます。 -
Figmaの埋め込み
Notionの各ページにページ単位での埋め込みが可能となっており、詳細設計を書くのに便利です。
使用技術が初学の場合は、学習コストが膨れ上がるのを想定した上で優先度をつけ、どうしても必要な機能以外は次回バージョン以降で出すのもアリかと思います。
画面設計を書く
上記でNotionで必要な画面を整理したので、それぞれの設計を行っていきます。
ここでのゴールとしては「各画面での動作を洗い出して全体で整合性が取れているか確認し、実装時に迷わないようにすること」を想定しています。
なので最低限以下の内容を整理したら良いと考えております。
- その画面の役割・達成するべき内容
- その画面と周辺の画面の繋がり・画面遷移
- 各画面のUIパーツの一覧と付随するアクション内容
- 表示形式のルール
画面遷移については、NotionでMermaid記法でフローチャートを書いたり、draw.ioで作るという手もありますが、時間かけても費用対効果が小さいので紙に手書きでも良いと思います。
デザイン
最初は面倒に感じるかもしれませんが、コーディング時に行き詰まったときのストレスの方が大きいので後々自分への投資だと考えて多少はやっておいた方が良いと考えております。
私ははっきりいってデザインセンス皆無ですが、同じようにデザインセンスのない方でも、「余白」・「色」・「１パーツに要素を詰め込みすぎない」という点に気をつければ致命的にダサいデザインは回避できるかなと思ってます。
ただ、やりこみすぎるとキリがない上に途中で変わる部分もあると思うので、ここでのゴールはあくまで「画面上にパーツをどのように配置するかイメージし、後々迷わないようにする」と捉えてほどほどにしておくのが良いです。
一応、私が作成したものを掲載しておきますが、参考になれば幸いです。
余白
例えば文字の入ったボタンのパーツを考えた時に、文字とボタンの縁がギチギチになったり、余白が広すぎて間抜けな感じにならないようにしましょうということです。
色
色数が多いとカラフルで楽しい雰囲気になるのですが、トンマナを揃えようとすると全箇所それなりの色数で整合性を保つ必要が出てくるのでデザインの工数が増えます。
また、「リストの各アイテムの色を担当者ごとに変える」というケースを考えた場合に、ユーザー側の状況によって開発者側が想定したデザイン通りにいかないということもあると思います。
1パーツに色々詰め込まない
例えばX（旧Twitter）のタイムラインを想像してみます。
つぶやきの1つ1つがカード型のUIとして表示され、そのカードを改めて見ると「ユーザーID」、「表示名」、「日付」、「本文」、「いいねボタン」、「ブックマークボタン」、「インプレッション数」、「シェアボタン」で構成されています。
ただ、デザインが得意でない場合は色々詰め込むとギチギチになったり、コンポーネント全体が無駄に大きくなって視認性が悪くなったりするので、「多くの情報を伝える」よりも「１パーツの要素を極力減らす」というスタンスの方が良いのでないかと思いました。
カラーパレットを自動生成する
アプリのデザインにそれなりに多色を使いたい場合は、その組み合わせにもおそらくセオリー的なものがあると思うので自動生成してくれるようなサイトを活用するのも良いかと思います。
-
Adobe Color
ベースの色を指定すればその色に対する補色や類似色を出してくれます。 -
Tint & Shade Generator
カラーコードを指定すると、その色を濃淡が違うバージョンを作成してくれる。 -
Flat UI Colors
マテリアルデザインに使われる色の組み合わせを複数パターン、テンプレートとして用意されている。
他の方のデザインを参考にする
Webデザインに関しては上記サイトのように、ユーザーが自分のポートフォリオを公開するサイトもあります。
そのままパクるのはダメですが、ボタン1つ作るにしても色々なパターンを知っておくのには有効だと思います。
OS特有のデザインに則る
デザインに迷ったときはオリジナルで考えようとせずに、OS標準の系統に合わせるのも1つの手です。
例えばiOSとAndroidOSにはそれぞれ独特の系統があると思いますが、iOS風のデザインはCupertino（クパチーノ）と、AndroidはMaterialDesign（マテリアルデザイン）と呼ばれています。
1台は何かしらデバイスがあると思うので、その端末のOS（iOS/Android）が標準で提供しているアプリを観察してみるのも有りかと思います。
もちろんデザインが無個性になってしまうというデメリットはあるかと思いますが、開発に慣れないうちは文法とロジックの習得に集中した方が良いのでないかと個人的には考えています。
実装
参考になりそうなgithubリポジトリ
今回自分はSwiftUIを使って開発したので、SwiftUIのタグがつけられたリポジトリの一覧のページを貼っておきます。
初学時にディレクトリ構成などで参考にしたリポジトリを一部下に載せておきます。
-
clean-architecture-swiftui
https://github.com/nalexn/clean-architecture-swiftui -
SwiftUI-WeChat
https://github.com/wxxsw/SwiftUI-WeChat -
SwiftUI-Weather
https://github.com/dnKaratzas/SwiftUI-Weather/tree/master
テストデータの作成
多くのアプリがDBからデータを取得して表示すると思うので、ユーザーが何もデータを作成していない状況でも取得できるデータを最初に作っておいた方が良いと思います。
私が今回作ったアプリはAPIとの通信を伴わずにCoreDataのみを使用したので、デバッグ時にインメモリーでCoreDataにデータを生成するロジックを作成しました。
最後にアプリの審査を出す際にスクリーンショットが必要となるので、そのスクリーンショットに表示して問題ないデータをワンプッシュで呼び出せると、開発時だけでなく後々も捗ります。
審査の準備
審査期間の目安
不備がなければそれほどかからないのでないかと思います。
参考までに、私の場合は深夜の1時くらいに審査を出して、朝8時くらいに起きたら審査完了の連絡が来ておりました。
審査基準
iOSのアプリ審査については、上記に記載されているものからメジャーだと思われるものを紹介します。
- 全般
- 提出した内容と実際のアプリの動作に相違がないこと。
- 内容
- 不適切なコンテンツ（差別・暴力・わいせつ的な内容など）が含まれていないこと。
- ユーザーがコンテンツを生成できたり、ソーシャルネットワーク要素を含むものに関しては、不適切な投稿に対する対策が行われている。
- 不正確な医療情報を提供し、物理的危害を加える恐れのあるコンテンツがないこと。
- パフォーマンス
- バグがなくちゃんと動作すること。
- ベータ版ではないこと（ベータ版の公開は認められていない）。
- 広告などの含めて空の情報が表示されないこと。
- ソースコード
- ユーザーから分からない隠れた機能が実装されていないこと
- 開発時の一時的なコンテンツが含まれていないこと
Webサイトとプライバシーポリシーページ
アプリ審査時には「サポートサイトURL」、「マーケティングサイトURL」、「プライバシーポリシーページのURL」が必要となります。
マーケティングサイトというのはアプリのオフィシャルサイト的なものを指すのですが、個人でアプリを開発している人は当該アプリが掲載された自身のポートフォリオサイトを使っている人も多いです。
このサイトについてはアプリ公開の話に限れば凝ったものを作る必要はないです。
例によって下記を参考にNotionだけで外部公開ページを作成し、CloudFlareで独自ドメインを乗せました。
私は元々将来使おうとして取得していたものを使いましたが、わざわざ独自ドメインを用意する必要もないかもしれません。
プライバシーポリシーやサポートサイトURLについては、マーケティングサイト内にそれ用のページを作成しておけば問題ないと思います。
プライバシーポリシーについても形式というのは定められておらず、個人データを収集する要素がある場合（アナリティクスなどのトラッキングツール含む）にその利用用途を普通に書けば問題ありません。（ただし、うっかり違法な形で個人情報を収集・使用しないように改正個人情報保護法には目を通しておいた方が良いと思います。）
個人データを収集しないアプリについては「このアプリはユーザー情報を収集しません。」だけでも大丈夫です。
問い合わせ先
サポートURLについては問い合わせフォームなどのリンクを貼っておけば良いと思います。フォーム自体はGoogleフォームとかで作ったもので問題なく、私はNotionのページ内でGoogleフォームにリンクしたページを用意しました。
アイコンの準備
ここもアプリのデザインのときと同様、デザインが得意でない人は外部の力を借りてしまった方が良いかと思います。
自分はMidjurneryを使いました。iOSのアプリアイコンに関しては下記を参考にしてプロンプトを用意し、指示を行いました。現在は有料版を契約しないと使えなくなっておりますが、月額1,000円程度で済むので費用対効果は良いと思います。
スクリーンショット
スクリーンショットは2023年7月時点で6.7インチ、6.5インチ、5.5インチのものが必要になります。
これはiPhoneに限った話なので、iPadにも対応しようとした場合にはそれ用のスクリーンショットが必要です。
ただ、実機を用意する必要はなく、Xcodeのシミュレータ上でCommand+Sキーでスクリーンショットを撮影することができます。
上記画面に対応する端末の例としては
- 6.7インチ：iPhone14
- 6.5インチ：iPhone11 Pro Max
- 5.5インチ：iPhone8 Plus
があります。
その他アプリ公開ページに必要な素材
以下の公式サイトから確認できます。
iOSアプリ開発アプリに限ったハードル
個人的に今回iOSのアプリを開発してみて、他の言語を学ぶより敷居が高いと思ったポイントをお伝えします。
モバイルアプリ開発には興味あるが、下記に挙げた内容を見て悩んだ時はAndroidアプリから入るか、iOS/Android両方いけると言われているFlutterから初めて見ても良いかもしれません。
Androidアプリの開発はまだやったことないですが、少なくともiOSアプリよりハードルが高くなるイメージはないです。
実機はなくても開発できるがあればベター
iOSアプリを開発するのに使用するSDK「Xcode」には実機を模ったシミュレータで実行できる機能があります。
Androidスマホしか持っていない人には追加でコストがかかりますし、シミュレータだけでアプリのデバッグを済ませることも可能です。
ただ、以下の点から実機はあった方が良いように思えます。
1つ目はアプリをストアに公開する前に開発途中のアプリを知人に触ってもらうこともできるのですが、これには開発途中のソースが入ったMacに実機を接続してビルドする必要があることです。
2つ目は実機に触ってみることで実装したViewの細かい仕様に気付きやすくなり、UI上の不便を防ぐことができる可能性があるからです。初学時には見た目ばかりに気を取られがちなのと、マウス操作が不便なのもあって組み込みのViewが持つ挙動を確認するのは大変だと思います。
また、これからiOSアプリの開発を学ぼうとしている方はXcodeのバージョンやシミュレータのOSを最新にしてから始めることも多いと思いますが、よく使うViewでも新登場の機能や新しい記述に置き換わって古い記述が非推薦になったりすることもあり、なるべく現行〜少し未来までOSのアップデートがサポートされる端末を選んだ方が良いと思います。
私はAndroid使いだったのでiPhoneSE（3rdGen）を購入したましたが、MacBookがそもそも高いですし、マストではないと思うので自分の財布と相談しましょう。
アプリ公開時に登録料として年間$99かかる
Appleのストアにアプリを出すときは年会費99$を一括で支払ってAppleDeveloperProgramに登録する必要があります。GooglePlayの登録料が25$らしいのでAndroidアプリを出すときの約4倍になります。
今は円安の影響で日本円に直すと自分のときで13,000円くらいかかった記憶があり、自分は本格的にモバイルアプリをやりたかったので気にならなかったのですが、公開するアプリの数に関わらずかかってくる費用なのでiOSアプリ開発の敷居が高い要因ではあるのかなと思います。
Xcodeが初心者の心を折ってくる
iOSアプリの開発にはXcodeを強いられるのですが、このXcodeが中々曲者で初心者の心を折ってくるのには十分な使い勝手をしています。
まず、Xcodeが日本語に対応しておらずに全て英語なので、普段英語に触れる機会を能動的に作って来なかった方だとシンプルにストレスが溜まります。
あとは、Xcodeエディタ上に表示されるエラーはパッと分かりづらいものが多く、経験と勘が必要になってくる場面があります。シンタックスエラーはエラー文で調べれば出てきたり、最近だとGPTに聞けば解決することも多いのでまだ何とかなるかと。
ただ、アプリ開発と開発者アカウントが密接に関連しているせいで、何もしていないのに証明書エラーが起きたりしてその辺りは慣れるまで大変だと思いました。
あまりよくありませんが、X（旧Twitter）でXcodeの悪口を調べるとたくさん出てくるので（小声）、自分だけじゃないんだと割り切っていくしかありません。
SwiftUIのソースコードはブラックボックス
SwiftUIがオープンソースではないので「このメソッドは引数に何と何を取って戻り値の型は何」というのはドキュメントに載っておりますが、他言語と違って具体的なソースコードはブラックボックスになっております。
フレームワークの組み込みメソッドの挙動などはソースコードを見ると勉強になる部分もあったので、ここは残念だなと思いました。
アプリを個人で出す場合には本名が公開される
まず、自分が実際にiOSアプリをリリースしたAppStoreについては、必ず英字ではありますが本名を公開しなければいけない仕様となっています。
別に悪いことはしていないですし、そもそもエンジニアの方は結構本名出して活動している方も多いのですごいなと思いますが、会社員やっている身としては最初少し抵抗がありました。
屋号で出すことも検討しましたが現在は認められていないようです。屋号で登録したという記事もあったのですが、ある時から認められなくなったのかもしれません。
ですが、Appleとしてユーザーに安心してアプリを使ってもらうために必要なことだと思いますので、普段ネットで実名を使った活動がなくて慣れない方も割り切ってしまいましょう。
最後に
ラストの方はiOSアプリ開発のネガキャンっぽくなってしまいましたが、何だかんだアプリ開発は楽しいしやりがいのあるものだと感じております。
特にiOSアプリは審査もそれなりに厳しく行われるようなので、初めて審査を通過して公開されたことに対する満足感は高かったです。
少しでも興味のある方はぜひチャレンジしてみてください。
Discussion