スマホアプリを作る際に対応しておきたい実装ポイント
この記事を書く背景
僕が働いている会社ではSaaSと受託の両軸で事業が成り立っていて、両方でスマホアプリを作っているのだが、主に受託側でスマホアプリを作ってリリースする前に対応していきたい実装ポイントがいくつかあってそれを共有したいと思います。
「要件にはないけど、保守する時や追加機能の実装フェーズが来たときにあらかじめ対応しておきたい」内容などもあるので、あらかじめ受託開発の予算に組み込んでおいた方がおすすめです。
実装ポイント
1. メンテナンスモード
アプリに致命的な不具合が発生した場合やアプリの提供を終了したい場合にあった方がいい。
例えばアプリ起動時や、どの画面を触っても必ず通る処理でDBやFirebaseRemoteConfigなどからメンテナンスモードのフラグを見に行って、ONになっているとメンテナンス画面を表示するといったもの。
メンテナンス時のメッセージなども取得して出せるといいかなと。
「アプリ メンテナンス」で画像検索するとサンプル画面などが出てきます。
2. 強制アップデート
アプリに致命的な不具合もしくはアップデート後にしか使えない機能があった場合に強制アップデートの機能をあらかじめ実装しておくと、エンドユーザーのアプリの挙動を一律で合わせることができる。
例）記事の表示/非表示機能をv1.0のリリース後から追加した場合(v2.0をリリースしたい)、既存アプリ(v1.0)は非表示機能がないため、アプリと管理画面側で非表示機能(v2.0)を実装しても既存アプリ(v1.0)ではアップデートしない限り見れてしまう。
ただし、この強制アップデートはエンドユーザーからしてみると、使いたい時にアップデートしないと使えないという状態になってしまうので、主に２種類の挙動を用意して、用途別に使い分ける必要がありそう。
<強制アップデートの種類>
- 完全にアプリを使えなくしてアップデートを強制させる
- 案内のダイアログは出すが、アップデートのキャンセルをつける
もしくはAPIのエンドポイントをv1.0とv2.0でわけて運用するという手法もあるかなと思いますが、エンドポイントを分けることによるデータの振る舞い方の違いが出てきたり、シンプルに両方のエンドポイントの保守をするという大変さもあると思うので、開発メンバーの体制やサービスの大小にもよるかなと思いますが、あらかじめ強制アップデートを実装しておくと無難です。
3. 退会機能
もしそのアプリがユーザーの登録画面を持っているアプリなら、アカウントの削除機能が実装されていないとストア審査でリジェクトを食らいます。
<App Store Reviewガイドライン>
5.1.1の(v)
4. プッシュ通知の仕様
プッシュ通知の仕組みが欲しいという要望ってよくあると思いますが、仕様は様々あるのでよくヒアリングすることをお勧めします。
- 通知が複数あった場合iOSのアイコンの通知バッジをインクリメント/デクリメントする
- 通知が複数あってもiOSのアイコンの通知バッジは１のまま
- 通知センターからタップしてアプリを起動後、iOSのアイコンの通知バッジを消す
- 通知センターを１つでもタップしたら全部通知センターを消す
- 通知センターを１つタップしても複数残っていた場合はそのまま通知センターに残しておく
5. 翻訳対応
絶対に日本しか使わないみたいな要件や開発のスピード感的に難しければ対応しなくていいですが、翻訳したいという要望がほんの少しでも可能性としてありそうなら、いざという時にできるだけ早く対応できるように、i18n対応をあらかじめ入れ込んでおくと後々要件が発生した場合に対応のスピード感が変わるかなと思います。
切り替え予定がなくとも日本語のarbファイルだけでも対応しておくことをお勧めしておきます。
6. SNSアカウントでアプリを利用する場合
GoogleやFacebook、Twitterなどサードパーティのログインを利用するならiOSはAppleサインインも必要となります。
<App Store Reviewガイドライン>
4.8
7. OSSライセンス表示
利用しているライブラリを確認してアプリ内にライセンスを表示しておきましょう。
8. 保守対象OS(動作対象機種)を決めておく
OSや機種依存による対応を毎回するのはかなり大変になってくるので、保守対象のOSなどを定めておくことをお勧めします。
「最新OSのみ」や「最新OSとその一個前まで」「iPhoneX以降」などなど保守できそうな範囲を決めておきましょう。
Discussion