円滑にiOS/Android並行開発するための心得まとめ

2016年4月12日 2021年4月9日

notwork_matome_multi

iOS/Androidアプリを同時に開発するための心得まとめ

ネイティブアプリをiOS/Androidそれぞれ並列に開発する際に気をつけること

ヒーラー

クロスプラットフォーム開発というわけではなく、ネイティブアプリ開発を並行にするときの心得だよ

はじめに

新しいモバイルアプリを開発するプロジェクトにおいては、iOSとAndroidの開発を同時にすることが多くあります。同時並行で開発を進める上で、複数のメンバーで方針を決める必要もあります。それは、iOSの担当者、Androidの担当者だけでなく、サーバーサイドの開発者やデザイナー、企画やマーケッター、受託開発であれば、発注する人も気をつけるべきことがあります。

ここでは、クロスプラットフォーム開発ではなく、SwiftとKotlin（Objective-cとJava）など異なる言語を組み合わせて、OSの特性を意識した上で行うネイティブアプリ開発での注意点に触れます。

※クロスプラットフォーム開発とは
ハイブリッド開発とも呼び、１つのプログラムでiOSとAndroid両方で動作可能なアプリを開発する手法で、FlutterやReactNative、Xamarinなどがあります。
プログラミングのコストカットができるメリットがありますが、iOS/Androidの最新の機能を使うには対応を待つ必要があるなどのデメリットもあります。

設計

UIパーツやフレームワークはそれぞれの素材・特長を活かす

当然ながら共通設計

採用するアーキテクチャを決定する（MVC、MVP、MVVM、Fluxなど）
用語を揃える（企画時点の用語を採用するべき）
コーディングルールを揃える（iOSとAndroidに共通する部分は合わせる）
define値やクラス名などを統一する（用語から落とし込んだ大項目の名称は合わせる）
永続化する項目を統一する
レイアウトの細かい部分まで統一する
- UIデザインマージンやセンタリングなどのルール統一
- 端末/画面サイズに応じて、固定/可変する箇所の認識を合わせる
例外系のエラーメッセージを網羅しておく

無理やりiOSのパーツをAndroidに適用しない

ダイアログやドラムロール(ピッカー)などのUIパーツ
iOSのタブ機能やナビゲーション機能（Androidでは画面上部かサイドメニューも検討）
戻る機能はAndroidではBackキーを活用

それぞれの特長を活かす

iOSではSQLiteを直接使用せずCoreDataを使用するなど

製造

開発者間の情報共有を密にする！

LOGの記述体裁を合わせる

ファイル名、メソッド名、行数、コメントなど体裁を合わせる
- 品質チームや運用チームが見やすくなる
- (ついでに…LOGはデバッグでのみ表示させるものと使い分ける)

TODOの記載の仕方を合わせる

不確定部分や拡張予定の項目は、ミーティングなどで共有したらコメントで残す
特殊タグを活用する
- いつからか、iOS（Xcode）でもAndroid（AndroidStudio）のようなTODOの書き方ができるようになりました

// MARK: 罫線付きのセクション見出し
// TODO: 「後で○○しなければならない」の意味
// FIXME: 「○○を修正する必要がある」の意味

共通ルートを準備する

実装中に気がついた例外ケースはすぐ共有
- もう一方でも同じケースが起こりうるため
設計を見直す必要がある場合にはすぐ共有
- もう一方でも同じケースが考えられるため自分勝手に直さない！

デザイン

画像作成

解像度別に画像を準備する

(特に指定がない場合) x1を念頭に、x2、x3の画像を用意する

iOS	Android	解像度
非Retina	mdpi	1px/1pt
	hdpi	1.5px/1pt
Retina(@2x)	xhdpi	2px/1pt
Retina(@3x)	xxhdpi	3px/1pt

ファイル名にハイフンは使用しない (Androidで使用できない)

PJ管理

コーディング規約をメンバーに浸透させる

iOSとAndroidで表現が変わらない様にする

例えば：ホーム画面とトップ画面とメイン画面など
コーディング規約以外にも、OS間で共有しなければならない事項についてチェックや啓蒙を継続する

iOSとAndroidの工数を同じと思わない

Android機種が多く機種依存もあるため、テスト工数も増える

サポートする機種やバージョンを予め決める
受託開発の場合は特に、見積り時にサポートするバージョンや機種の合意を取る

傾向的にはAndroidの方が工数膨らみがち

iOSに合わせることが多く、iOSの標準のアニメーションを求めることがあるため

諸々の事情について理解をもらう

受託開発の場合は、技術と工数の関係する事情ををなるべく顧客に知ってもらう

iOSのデフォルトのアニメーションをAndroidに求められて工数増加などがある

要求の機能ひとつとっても、コストの認識のずれは起きます。
「○○できます？」と聞かれたとして、「（技術的には）できます！（ただしその分コストがかかります）」とカッコの中が省略されたやりとりされることが多々あります。
ここはiOSとAndroidで仕様を無理やり合わせるのは、工数もかかるしバグも生みやすいし、お互い美味しくないですよなど伝えることも大事です。