これから iPhone アプリ開発に携わるのであれば覚えておきたい最低限のこと
iPhone アプリを作ってきて
私が iPhone アプリ開発を始めてからおよそ4年が経過しました。
その間に得た知見の一部を紹介致します。
この記事の対象読者は以下の方を想定しています。
●これから iOS プログラミングを始めたい方
●今まで本格的に iPhone アプリを作ってはいないけれども、興味がある方
●開発の事はよくわからないけれども、アプリのプロモーションなどを担当している方
これから iPhone アプリ開発に携わるのであれば覚えておきたいこと
言語について
(一)モダンな書き方をする → Objective-C でもジェネリクスなどを積極的に使う (二)冗長な書き方をしない →[[Class alloc] init] は [Class new] と同等
(三)Swift は GitHub の Release や Issue などを追う → オープンソースの活用
(四)豊富なOSSを活用する → 時間をかけて頑張って作り過ぎない
UIについて
(一)Appleのヒューマンインターフェイスガイドラインから離れすぎない (二)画面遷移や大まかな構造はStoryboard を使う
(三)細かいパーツには Xib を使う
(四)コードでUIを作り過ぎないようにする
(五)AutoLayout を使う
(六)ScrollView 系統のコンポーネントの仕組みを理解する︵TableView, CollectionView︶
(七)Constraints ︵AutoLayout の制約︶が複雑になってきたら ContainerView で切り分ける
データの永続化について
(一)UserDefaults を使う
(二)Realm を使う
(三)CoreData などから SQLite を使う
アプリ内に必要以上のデータを持ちすぎない事がポイントです。
アプリの設定情報やキャッシュ以外は、なるべくサーバに持たせると良いでしょう。
通信について
(一)AFNetworking︵Swift では Alamofire︶ を使う (二)Web 上の画像取得には SDWebImage を使う ATS 対応が必要なので、注意してください。 可能であれば Web アプリと iPhone アプリの API は別々に分けた方が良いでしょう。 必要以上に通信中のユーザ操作を受け付けないこと︵全画面ローディング表示の出しすぎ︶には気をつけましょう。カメラについて
(一)ImagePicker を使う︵撮影した画像を取得・モーダル表示のみに限定される︶
(二)AVFoundation を使う︵動画・音声・加工などの操作を一挙に行えるが、UIは全て自前で作る︶
ImagePicker は簡単に作れますが、操作や機能の微調整が不可能です。
AVFoundation は Cに近い操作が必要になることが多いです。
また、 AVFoudation を使ったライブラリ︵バーコードリーダー・顔検出・加工・ARなど︶はたくさんありますが、アプリに適した OSS がなければ、 OpenCV︵C++︶ などと組み合わせて自作する必要があります。
端末内の画像操作について
(一)ImagePicker を使う︵カメラロールから画像取得・モーダル表示のみに限定される︶
(二)AssetsLibrary を使う︵カメラロール以外の画像ライブラリの作成・取得・操作︶
カメラと同様に ImagePicker は簡単に作れますが、操作や機能の微調整が不可能です。
音声について
(一)BGM などはAVFoundation︵AVAudioPlayer︶ を使う
(二)SEなどは AudioToolbox を使う
Android と比較すると、標準の音声ライブラリのレイテンシが非常に低いです。︵音再生までのタイムラグが、体感できないほどにない︶
また、端末に左右されることなく一定の再生品質を保てるのも iPhone の利点の一つです。
動画再生について
(一)MoviePlayer を使う
(二)AVFoundation︵AVPlayerView︶ を使う
(三)WebView を使う
ストリーミング再生なども比較的簡単に実装可能です。
位置情報について
(一)MapKit を使う
(二)CoreLocation を使う
簡単な地図の表示だけでよければ MapKit で十分でしょう。
GPS機能などが必要であれば CoreLocation が必要となります。
位置情報を﹁常に許可﹂するタイプのアプリでは、バックグラウンド︵アプリを開いていない状態︶でも動作させることが可能です。
Bluetooth Low Energy︵BLE︶について
(一)CoreLocation︵CoreBluetooth︶ を使う
iOS 7で話題になった iBeacon も BLE に含まれます。BLE モジュールとの連携はもちろん、上手く使えば O2O︵Online To Offline︶のようなマーケティング施策にも使えます。
Bluetooth SIG という団体によって定められた GATT という仕様を理解した方が、より円滑にプログラミングが行えます。
Bluetooth デバイスとの連携は、バックグラウンド︵アプリを開いていない状態︶でも動作させることが可能です。
Webページの表示 について
(一)WebView を使う
(二)SafariView を使う
(三)OpenURL を使って Safari で開く
ATS 対応が必要なので、注意してください。
簡単に表示できる ≒ 複雑なことをしようとするとデバッグが大変
というジレンマに簡単に陥れるコンポーネントでもあります。
OpenURL はアプリから離れるので、以降の制御は不能ですが、常に端末の Safari アプリで開ける事は利点の一つでしょう。
プッシュ通知について
(一)ローカル通知とリモート通知がある (二)リモート通知を実装する場合はサーバに証明書などを用意する必要がある リモート通知は、クライアントサイド︵アプリ側︶とサーバサイドの開発者が違う場合、連携を取る必要があります。SNSアカウントとの連携について
(一)﹁設定﹂アプリで紐付けられているアカウントからの投稿︵シェア︶はSocialFramework を使う
(二)Twitter や Facebook ログインなど、SNSアカウントから情報を取得するには申請︵+SDK︶が必要
SNS のプロフィール情報や、友達リストをアプリで取得したい場合は、各SNSに申請する必要があります。
Facebook では取得する情報によって簡単な審査があるので、事前に申請しておく必要があります。
課金について
(一)消耗型プロダクト︵Consumable Products︶にして、仮想通貨︵魔法石など︶をサーバ側で管理する (二)仮想通貨でアプリ内のコンテンツを購入したり操作させる 消耗型プロダクト︵Consumable Products︶以外の課金方法については、デバッグが大変なのであまりオススメできません。課金フローを参考にできるアプリ自体が少ないです。 購入したデータは、アカウントに紐付けてサーバで保持しましょう。どの端末でも同一アカウントであれば、データの同期が行えるようにすることが重要です。 課金額には Apple が定めた Tier︵価格帯︶以外の価格をつけることができません。iPhone のアプリ内課金のほとんどが、120円〜とか決まっているのはそのためです。 Tier はドル円相場で変わることがあるので、UIの価格を固定表示しない︵Apple の API から価格を取得する︶ように気をつけましょう。ソースコードのバージョン管理について︵特に指定がない場合︶
(一)ローカルのリポジトリには Git を使う (二)リモートのリポジトリには GitHub を使う GitHub では、PullRequest や Issue を積極的に使ってコミュニケーションを取りましょう。
README での手順管理や、Release 機能を利用すると引き継ぎなどがスムーズに行えます。
リリースについて
(一)アプリのリリースには Apple の審査が必要 (二)Apple の定めた各種ガイドラインに従う必要がある (三)何度もリジェクト︵審査落ち︶されてアプリの修正を促されることがある とにかく審査提出前に、﹁ 一般的なアプリケーションの却下理由 ﹂に当てはまらないかをチェックしましょう。 リリースに関わる事︵審査提出までのUI・審査期間︶が不定期に変わるので、常に覚えておくことが必要です。 1度リジェクトされると、修正も含めて1週間は少なくともかかると思った方が良いでしょう。なので、見積もりには余裕を持たせたいところです。 リリースまでの仕組みを理解していないで、﹁去年まではこの操作でリリース出来ていました。︵キリッ﹂は、大体今年のリリースでハマります。 Apple は開発者ファーストではなく、常にユーザファーストなので、仕方がないことだと思いましょう。アプリのアップデートについて
(一)アップデートを計画的に行うものなのかを開発前に決めておくと、後々のトラブルを回避できる (二)旧バージョン︵OS・アプリ︶での動作を保証するのか、切り捨てる場合はどうするのかも開発前に決めておくとより良い AppStore のレビューの星の数に直結するような、致命的なバグは避けたいところです。下位バージョンのソースコードを GitHub に残しておけば、実機検証が容易に行えます。 検証用の端末は、OSバージョンを上げずに残しておきたいところです。ユーザのプライバシーについて
(一)プライバシーに関するものは、大半がユーザによる許可が必要 (二)誰しもカメラ・プッシュ通知などを許可してくれるものではなく、許可されなかった場合も問題なく動作する必要がある プッシュ通知の使用率を上げるためには、プッシュ通知を何故使う必要があるのか、ユーザへわかりやすく説明する必要があります。 アプリのコンバージョン率を上げるためには、ユーザに嫌がられない工夫が必須でしょう。ダウンロード数について
(一)単にリリースしただけでは、ほとんどダウンロードされない (二)どうやったらよりダウンロードされるのかをよく考えないと、頑張って作っても見向きもされない この辺りは、各種事例や取り組みなどが Web 上にたくさんあるので、作りたいアプリにあったものを参考にすると良いでしょう。高品質なアプリを目指すのであれば覚えておきたいこと
ユニットテストを行う
OSS のテスト用フレームワークの方が、Xcode 標準搭載のXCTest よりも高機能なものが多いのでオススメです。
初めてユニットテストを書く時は、何を書いたらいいかわからないものです。
まずは、著名なOSS︵必ずテストコードがあります︶を参考にすると良いかと思います。
ロジックを変更した際に不具合があれば、ユニットテストを回すだけで判断できます。
都度シミュレータで操作したりする必要はありません。︵﹁頼む、動いてくれ〜〜！﹂といった考えは捨てましょう。︶
