強制バージョンアップの話。
という記事を見かけたので。
このライブラリの実装の問題点
| key | description |
|---|---|
| type | 基本的には強制バージョンアップを行うことを前提に解説していますが、SRGVersionUpdaterではキャンセルボタン付きの告知アラートを表示することも出来ます。強制アップデートの場合は"force" を任意でのアップデートの場合は"optional"を入力して下さい。 |
これ、設計ミスってません？
一度致命的なバグを出して"force"で通知したら、それ以降二度と"optional"は使えません。「必ず一定以上のバージョンを使って欲しいけど、最新版の通知もしたい」ようなユースケースに対応できないなら、"optional"の存在意義はない気がします。
あと、「評価が付くまで様子見ユーザー」層は毎回"optional"の通知を繰り返し見せられて離れます。開発者がいいと思ったアップデートが必ずしもユーザーに受け入れられるとは限らない（むしろ逆のケースのほうが多い）のです…。
もう一点指摘するなら、一度強制バージョンアップ対象になった端末は、その後通信する必要がありません。何度起動してもストアに飛ばされるだけなので。
条件を付けてレスポンスをキャッシュすることで、余計な通信負荷を減らすことができます。機内モードに入れるなどして、バージョンチェックを迂回する裏道もなくなります。ただし サーバーの設定が間違っていた 場合の救済策がなくなります。
解決すべき問題について
古いバージョンのアプリで特定の操作を行うと、データが破損しアプリの操作が不可能となるバグが発見された
この本質的な原因は、単なるテスト不足です。
強制的に最新のバージョンに上げてしまうと、新たなバージョンに致命的なバグがあったとき、全ユーザーに被害が拡大するだけです。
品質管理の問題に対して、「強制バージョンアップの運用で解決する」という方法論を取るのは、正直微妙な感じがします。
サーバーサイドとの通信部分で使う認証ロジックに問題があり、古いバージョンでの認証ロジックのままでは成り済ましが出来てしまう脆弱性が発見された
これも根本的なところではテスト不足なのですが、それに加えてアプリとの連携APIを作る場合は、
- 利用不可（非推奨）バージョンであることを通知する
- 利用非推奨APIとなったことを通知する
- サービスの終了（移行）を通知する
というのを、設計段階で想定するべきだと考えています。
これはリクエスト時にバージョンを受け取って、何らかのレスポンスコードで判定を行えばいいだけなのでまったく複雑ではないです。
アプリとAPIの寿命は長いとは言えません。設計段階で死の概念を内包しなければならない、と考えています。
楽ではないJSONのデプロイ
「たった3行」で導入できますが、運用は大変です。
これまでの経験上、最新版のアプリを配信開始しiTunes Connectの状態がReady for Saleとなっていても実際にApp Storeに反映されるまでには1〜3時間程度の時間差がありました。
にもありますが、アプリをデプロイしても実際に反映されるまでのラグを考慮する必要があります。全てのユーザーが本当にダウンロード可能になったのか、定期的に確認する必要があります。
加えて、サーバー側のデータの更新作業はユーザーが多い時間にやるべきではありません。
これはアプリの規模感にもよります。もしJSONに不備があっても、すぐに直して挽回可能な規模であれば当てはまりませんが、基本的には深夜層に実施することになるでしょう。深夜まで待機して、ミスったら大クレーム…、そんな作業やりたくない…。
バグのないプログラムがないように、必ず一度はヒューマンエラーが発生します。例えば、iOSとAndroidを並行して開発した場合、両者のバージョンは基本的に一致しません。入れ違えただけで大惨事です。
古い端末のユーザーの考慮
AppStore固有の問題として、最新のバージョンとして「iOS7以降でしか動かないアプリ」をデプロイした場合、iOS6未満のユーザーは古いAPKを取得できてしまう というものがあります。
参考: アップル、古い iOSデバイス向けに互換性のある旧アプリを提供 - Engadget Japanese
一度アップロードしたバイナリはAppleによって管理され、開発者は制御できません。闇です。
UPDATE:訂正。アプリケーションのバージョンをiCloudに表示しない(iCloud availability)の設定で、旧バージョンが新規にダウンロードされることは防げる、が正しいです。
