はじめに

この記事はCrowdWorks Advent Calendar 2016 4日目の記事です。

CrowdWorksのiOSアプリは2015年の7月に初版としてメッセージアプリとしてリリースされ、いったんの開発中断を挟みながらも、2016年5月に検索機能を追加して12月現在もエンハンスを続けています。

アプリを作っていると他の会社ではどう開発しているんだろう、ということがよく疑問に思ったりもするので、一つの事例としてご紹介できればと思います。

Xcodeプロジェクト構成

Swift 3, Xcode 8

アプリはほぼすべてSwiftにて実装しており、Swift 3, Xcode 8に対応しています。
iOS Development Targetは9.0にしてiOS 9.0以降をサポートしており、なるべく古いバージョンは切り捨てながら新しいバージョンに追随するようにしています。

ReactiveCocoa

開発をはじめた2015年春くらいには、iOSでもリアクティブプログラミングをしてみるのが流行りだしていた頃でしたので、CrowdWorksアプリでもReactiveCocoaライブラリを取り入れ、実装もMVVMで実装しました。

ちなみに、当時のReactiveCocoaはまだversion 2.5で、Objective-Cによる実装でした。（現在はなんともうすでに5.x系の開発が進んでいる模様です）
アプリはSwiftで実装していたため若干無理をして使っているところもあるのですが、現在もまだバージョン2.5を使っておりSwift対応の新しいバージョンに移行したいところです。

Realm

実際にはまだプロダクションのアプリにはのっていないのですが、アプリ内部のDBとしてRealmを利用するように対応中です。
RealmはCoreDataを使うよりも高速に動作するのと、データの変更に対してリアクティブに実装することが簡単にできるので、どんどん使っていきたいライブラリとなっています。

グループ構成

今でもどう分けるのが正解なのかも分かっていないですが、現状こんな感じで落ち着いています。
MVVMにおけるVMに相当するViewModelsグループと、Vに相当するView, ViewControllersグループ、Mに相当するManagersやServicesなどに分かれています。

グループ	内容
cw-ios/Utils	共通的な処理など
cw-ios/Resources	画像やフォントファイルなど
cw-ios/Views	UIViewやUITableViewCellのサブクラスなど
cw-ios/ViewModels	ViewModelクラス
cw-ios/Services	サービスクラス
cw-ios/Managers	保存データの管理を行ったりするクラス
cw-ios/Entities	Web API通信の結果や保存するデータのエンティティを定義するクラス
cw-ios/Supporting Files	Info.plistやBridging-Header, entitlementsなど諸々突っ込んでいます。
Frameworks	導入したframeworkをまとめています。
Libraries	CocoaPodsで管理していないサードパーティ製のライブラリ
cw-iosTests	テスト関係
Products	ビルド生成物など
Pods	CocoaPodsが自動で生成したxcconfingファイル

ディレクトリ構成

Xcode上のグループ構成と違って、実際のファイルシステム上のディレクトリ構成は実装したソースコードはフラットに配置しています。
こうしないとXcode上でグループ構成をいじったりするに従い、ディレクトリ構成との乖離が発生してきて結局ぐちゃぐちゃになっていくようになるからです。

基本的に開発したソースコードはすべてcw-iosディレクトリに入っており、サードパーティ製ライブラリなどはlibrariesディレクトリに分けたりしています。
これは、今後自分達で開発したボリュームがどのくらいだったのかの把握がしやすいかなと思って分けています。

CocoaPods

サードパーティライブラリの管理にはCocoaPodsを利用しています。
CocoaPodsで推奨しているように、pod installして得られたライブラリなどはすべてGitへコミットするようにしています。

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you:

ライブラリ提供元が公開内容を変更したりすると、過去バージョンのビルドが再現できなかったりするので、一緒にバージョン管理しておいたほうが良いと思います。

　独自アイコンフォント

赤丸で囲んだところのように、お気に入りボタンを表示する必要が出てきたとき、画像ファイルを用意することが多いかと思われますが、CrowdWorksではアイコン表示用に独自フォントを作成しています。
表示するのは文字であるため、大きく表示しても綺麗に表示できるしサイズも軽く済んだりするので、よく利用しています。

また独自にアイコンフォントを作成するまでもなく、Font Awesomeにすでにある場合にはFont Awesomeのものを良く利用しています。

外部サービス

Fabric

公開したアプリでクラッシュが発生していないかを計測するために、FabricのCrashlyticsというサービスを利用しています。
Appleのクラッシュレポートだけだとアプリを公開したあとのクラッシュを把握するのは難しいので、こういったサービスを利用すると非常に役立ちます。
CrowdWorksでは直近7日間のクラッシュ率が0.3%以内になるよう意識しながら、監視を続けています。

またFabricにはiOSアプリが提供されており、これをインストールしておくとクラッシュが急増した場合にはプッシュでお知らせしてくれるため、オススメです。

Flurry

アクセス解析に利用しています。
ユーザーさんのアプリ上の行動について測定します。

CircleCI + Fastlane + DeployGate

アプリのCIとしてCircleCIを利用しています。

CrowdWorksアプリはGitHubのプライベートリポジトリで管理していますが、リポジトリにプッシュしたタイミングでCircleCIでフックしブランチ名によって様々な処理を行うようになっています。
処理内容はFastlaneで記述しています。

開発時のブランチの場合には、UnitTestやビルド番号をインクリメントしてGitHubにプッシュしたり、開発サーバーや本番サーバーと接続するようにしたアプリをAd Hocでアーカイブした結果をDeployGateで社内配布を行っています。

リリース時のブランチの場合にはさらにReleaseアーカイブしてApp Storeにアップロードしたり、dSYMをCrashlyticsにアップロードしたりしてクラッシュレポートのシンボル情報を解決（symbolicate）できるようにしています。

ツール

特に利用頻度の高いツールを紹介します。
SketchもCharlesも有料のツールとなりますが、とても有用なため自腹を切ってでも購入したいツールとなっています。

Sketch

iOSやAndroidアプリ開発で最近有名なデザインツールの「Sketch」を利用しています。
豊富なテンプレートや誰かが作ったSketch APP RESOURCESなどからデザインリソースをダウンロードして取り込むことができたりするため、非デザイナーでも簡単にアプリのデザインに取り組むことができます。

Charles

CharlesはMac上にProxyをたてて、そこに流れるHTTP, SSL/HTTPS通信内容をみたりできるツールです。

アプリを実装していると、APIの通信結果をログに出力してコンソールを確認するよりも、Charlesの表示を確認する方が手軽なのとより確実に内容が把握できるため、このツールがあるとないとでは大分開発効率が違ってくるのではないかと思います。

おわりに

この記事はCrowdWorks Advent Calendar 2016 4日目の記事でした。

明日は@YusukeIwakiのAndroidに関する記事の予定です。