iOSアプリ新規開発のノウハウ

今年でAdvent Calendarに参加するのは3年目。

今年は新規アプリ開発についてです。

iOSアプリの新規開発

仕事で何度か新規でiOSアプリを開発することがありました。チームやそのときの状況に応じて柔軟に対応するのがベストですが、その中でもやっておいてよかったなぁと感じたことについて紹介します。

iOSアプリの開発以外でも応用できる内容かも。

CIははやめに

CIの構築は初期段階で行っておくと、以下のようなメリットがあります。

ビルド時間が早いのでCI構築時のサイクルがはやい
何か問題が起きた場合、CIの設定まわりが怪しいといえる
その後の開発サイクルがスムーズになる

最低限のプロジェクトの設定をしたら、まずはCIの構築をしましょう。

コードをたくさん書いてからCIの構築をすると、構築に手間取ることが多いです。ライブラリもほぼ導入せずUnit Testも空の状態だと、Travis CIでもそれなりに早くサイクルを回せます。

ほとんど開発されていないプロジェクトだと、問題が起こった場合の原因はCIやFastlaneの設定にあることが多いです。原因究明も楽に行えるので、後回しせずにさっさと構築しておきましょう。

毎朝レビュー、マージ優先

毎朝レビューを行いmasterブランチへマージしておくと、以下のようなメリットがあります。

チームメンバのお互いの作業進捗が把握しやすい
コンフリクトを最小限に抑えられる
Pull Request一覧が毎日きれいになり精神衛生上よい
同様の機能を重複して実装することがない

リリース前なので、masterブランチへのマージは躊躇せず行えます。

前日に開発した内容をベースに開発を進めることができるで非常にテンポがよいです。

レビューは1つのディスプレイでチームメンバ全員で閲覧して行うようにしました。実装した人がコードの説明をすることで、何をどのように実装したかをメンバ全員が知ることができます。

気をつけたこと

レビュー時に気をつけたことは、少々のバグがあってもマージ優先でどんどん先に進むことです。

「このボタン押したらクラッシュしてしまう」といったバグについては、レビュー時にチームメンバ内に共有し了承を得ることでマージをしました。

そしてそのバグについては次の日までに必ず直すというルールにしています。

マージを優先することで、アプリが形になっていくスピードは格段に上がりました。

用語集を作る

あるプロダクトを作る上で、エンジニア以外の方とのコミュニケーションは避けられません。

コミュニケーションロスを極力少なくするためにも、言葉の定義をきちんとしておくとよいです。

iOSアプリ内の標準パーツ

f:id:Kamekiti:20171213091644p:plain

基本中の基本ですが、「Navigation Bar」や「Tab Bar」、「Segmented Controls」などiOSが標準で用意しているパーツについての名称を共有しておきましょう。Navigation Barのことを「メニューバー」と呼んだり、Segmented Controlsのことを「トグル」と呼んだりする方もいます。いちいち脳内変換するのが面倒なのと、iOSアプリを作る上では常識なので、プロダクトマネージャーやデザイナーで間違って使っている方がいれば、やさしく指摘してあげましょう。

独自で定義した機能

こちらは、前職で開発したアプリのスクリーンショットですが、「コンセプト」という機能です。あとからジョインした方がこれを見て「カテゴリ」や「特集」と呼んでいたことがありました。分からなくはないのですが、既に「コンセプト」と命名して、APIや内部実装でも「concept」という名称を使っているので、色んな呼び方があると混乱を招きがちです。

独自で定義したものは、最初に説明しないと分からないので、用語集を作ってまとめておくことで解決しました。

英語での表記

たとえばアンケート機能。

単純に「enquete」と表記してもよいですが、「survey」「questionnaire」など似たような意味の表記もあります。厳密にはそれぞれのニュアンスは違うのですが、日本人のわれわれにとってはほぼ同義と捉えられることが多いです。 API側では「survey」と表記されているのに、内部実装では「questionnaire」となっているとモヤモヤしますね。

こういったことを避けるためにも、英語表記ではどうなるかを定義しておくとスッキリします。

プロジェクト設定

アプリを新規開発し始めた際に毎度考えることです。

後回しにすると面倒になることもあるので、開発初期段階で検討したいです。

スキーム

どういうビルド構成にするかという設定ですが、たいていの場合「Dev」「Stg」「Prod」の3種類を用意することになります。

環境による分岐も必要なケースはあるのでマクロを作っておくと便利です。

画面の向き

Portrait（縦画面のみ）のアプリがほとんどですが、横画面にも対応するケースもあるでしょう。 横画面も必要となると、その場合の実装コストやテストケースも増えるので、開発する前に対応するかどうかを検討しておくとよいです。

対応するOSバージョン

どこまで下位バージョンをサポートするかは重要です。

開発者としては最新OSのみにしたいのですが、要件に応じてはそれ以前のOS対応も余儀なくされます。

Appleが公表しているiOSのシェア率を参考にするのもよいでしょう。 iOS11は約3ヶ月で60%のユーザに普及しました。2年前のOSは10%未満まで減るので、iOS界隈では一世代前のバージョンまでサポートしていれば90%のユーザはカバーできますね。

Lint

github.com

SwiftLintなど静的解析ツールを早いうちに導入しておきましょう。

あとから導入すると警告の嵐で泣く羽目になります。

アーキテクチャ

開発する上で大切なのがアーキテクチャの選定。

以下のようなことを踏まえ、どのようなアーキテクチャで開発を進めるかをチーム内で話し合いましょう。

プロダクトの規模
これからの運用保守
チームメンバのスキル

注意したいのは「流行っているから」とか「他のプロダクトで成功したから」など、自分たちのチームやプロダクトと関係のない根拠で決めることです。場合によってはチームメンバの学習コストもかかってくるので、アーキテクチャの選定は必ずチームメンバ全員の合意の上で決めたいですね。

ディレクトリ構成

Xcode上でのディレクトリの構成です。アーキテクチャを選定してから決めるのが良さそう。きちんとルールにしたがってディレクトリを分けて置かないと、気づいたらカオスになっていることも…。

Xcode 9からはXcode上でディレクトリ操作すると、ローカルディレクトリにも自動的に反映されるようになったので、わりと整理は楽になりました。

コーディング規約

開発をしていると各メンバの癖のようなものが出てくることがあります。気になる書き方やコーディングスタイルがあれば議論してみるとよいです。コーディング規約をガチガチに縛る必要はないと思いますが、ProtocolやExtensionの書き方や命名、//MARK :の付け方、guard letやif letなど多用するものの書き方など、軽くルールを作っておくと全体的にコードが読みやすくなるはずです。

ローカライズ

多言語化する予定がないプロダクトの場合でも、ローカライズすることを前提に開発しておくとよいです。

あとから置き換えるのは大変だし、漏れがでる可能性もあります。

Localizable.stringsを利用して言語ごとのローカライズファイルを作り、そこから表示すべきテキストの内容を読み込みましょう。 Storyboardのローカライズは色々と辛いのであまりおすすめできません。

単純な翻訳程度のローカライズであれば、導入してもさほど手間にならないと思います。

iOS11からのローカライズ

tofucodes.hatenablog.jp

地味にiOS11から仕様が変わっているのでご注意を。

ライブラリ

ライブラリの選定も大事ですね。以下のような選定基準で考えることが多いです。

インターフェース
アーキテクチャに沿うか
プロジェクトの規模に合ったもの

どれくらい柔軟に対応できるインターフェースなのか、サンプルなどを見たり軽く実装してみて検討するとよいでしょう、ライブラリによっては、採用したアーキテクチャに沿わないものもあります。

実現したいことを満たすがオーバースペックなものは採用しないほうがよいかもしれません。 データの永続化にRealmは便利ですが、Realmのメリットをあまり享受できなかったり、Realmを使うほどでもないなと感じたら別の手段を考えてみるのもありです。

ライブラリの管理方法

メジャーどころだとCocoaPodsやCarthageが挙げられます。

「基本的にはCarthageを利用して、提供されていないものはCocoaPodsで管理する」などチーム内でルールを設けておきましょう。

また、Fastlaneなど頻繁にアップデートされるライブラリもあります。開発初期段階に導入したライブラリが知らないうちに大幅にアップデートされていることも。 チーム内で定期的にライブラリのアップデートが来ていないか確認したり、アップデートして動作確認する習慣をつけておくとよいです。

汎用的なメソッドの作成

新規開発をしていると、汎用的なメソッドを作成することになります。

StoryboardやXIBの読み込み
色の読み込み
ログまわり
ネットワーク通信
Rxの拡張
ローカライズ
UIViewの角丸や影
ルーティング

同じ現場で何度も新規開発をすることがあるのなら、これらをFrameworkとして切り出しておくのも一つの手だと思います。

APIチームとの連携

アプリ開発において重要なのがAPIチームとの連携です。ほとんどのアプリの場合、APIと通信をしデータを取得します。

APIの実装が始まる前に、アプリ側の観点からこういうAPIがほしいというリクエストをするのが理想です。 取得したデータのデコードなどを考えると、APIの設計はアプリ側の実装とも深く関わってくるので。

リクエストとレスポンスの認識合わせ
エラーの種類や扱い方
APIの仕様をどのように管理するか

リクエストとレスポンスを定義しておけば、APIの開発中はモックを使ってアプリ側の開発を進めることができます。

デザイナーとの連携

Human Interface Guidelineを一読しましょう。

エンジニアやデザイナーだけでなく、プロジェクトに関わる方は目を通しておいたほうがよいと思います。

デザイナーとのコミュニケーションをどうするか

デザイナーとのコミュニケーションも非常に大事で、いかにスムーズに連携できるかで開発のスピードは大きく変わってきます。

過去に、社内Wikiでデザイン仕様を画像で都度アップロードしてもらっていた経験があるのですが、デザイナーの負担が大きすぎて時間的なコストがかかりました。

直近のプロジェクトでは、ZeplinのコメントをSlackと連携して通知させることでかなりスピーディに進められたと思います。

隣にデザイナーがいるなど、物理的な距離が近いとなおコミュニケーションが取りやすくなりますよ。

色について

開発初期段階にやっておきたいこととして、デザインのカラースキームの定義です。色はアプリにとってかなり重要で、色ひとつで雰囲気が全然違ったものになります。

アプリ内で利用する色の定義とその命名を行っておきましょう。

色の命名のテクニックとしては、はっきりと区別できる名前をつけることです。

「cellRed」や「textBlack」など、限定的な用途の命名は避けましょう。「lightPink」「lightPink2」など、わずかな色の差をうまく表現できないパターンも良くないです。「cinderella」「roseWhite」といった命名はいかがでしょうか。色にはそれぞれコードネームのようなものがあります。 わずかな色の差を表現したい場合は、色の別名を使ってみるとコード上では明確に区別をつけることができますよ。

画像について

Zeplinから直接Xcodeに画像をインポートするなどといった場合、画像の命名規則を作っておいたほうがよいです。せっかく書き出し設定してくれたのに、名前に統一感がないとインポート時の作業に一手間加わることになります。

画像形式も、PDFで出力してほしいなど事前に周知しておきましょう。

プロトタイプでの検証

ProttやOrigami Studioなどプロトタイピングツールもたくさん登場しています。紙芝居程度の簡単なプロトタイプはデザイナー自身でも作ることができます。

開発し始めてから、デザインの大幅な変更がくることを避けるためにも、プロトタイプでの検証は開発前に一度行っておきたいです。

デザイナーだけでなく、エンジニアやプロダクトマネージャーなども含めて議論するのが理想ですね。

マーケティングとの調整

アプリを開発してもユーザに広まらなければ意味がありません。マーケティング部隊が頑張ってアプリを広めるための施策を考えてくださっていることだと思います。

エンジニアとして少しでも力添えできるようにしたいです。

外部アプリとの連携

外部アプリからの導線が組まれることがあります。そこで必須になるのがURLSchemeです。

デバッグ機能としてもURLSchemeを活用することはできるので、設定しておくとよいかと思います。

Appleに推薦する

今年から正式にAppleに対して自分のアプリを推薦することができるようになりました。自分のアプリの特徴や、マーケティング施策、ストーリーを語ることでAppleに自薦できます。採用されるとApp StoreのTodayタブで取り上げられます。

この申請は、アプリのリリース前6〜8週間以内に行わなければなりません。 そして推薦できるのはApple Developer Programに加入しているユーザに限られます。 マーケティングチームの方は上記のページすら見られないこともあるので、エンジニアから一声かけてサポートしてあげることが必要です。