おいしい健康AndroidアプリのminSDKを21から23へ上げた時にやったこと

こんにちは。おいしい健康Androidエンジニアの小林です。

おいしい健康Androidアプリは、2019年の初回リリース以降〜先月までminSDK21でした。
先月初旬にminSDK23へ上げたのですが、その時にやったことを振り返りたいと思います。

minSDKを上げる理由

2つの大きい理由があります。

1 Android OSバージョンのシェアへの追従

おいしい健康はリリース以降、minSDK 21だったので、Android L(5)の端末まで後方互換性がある状態でした。

Android OS は年々新しいバージョンをリリースしており、ユーザーもどんどん新しいバージョンへ移行していきます。
古いOSバージョンのままのユーザーも一部いますが、日が経つほどの古いバージョンのユーザーは必然的に減少していきます。

2 開発環境の新陳代謝

開発環境はどんどん新しくなっていき、一般的にはモダンな環境の方が開発効率は上がります。
新しいライブラリを導入する時にもminSDKの要件を意識する必要があります。現状は導入したいライブラリがminSDK >= 21であることが多かったので、ブロッカーになることはありませんでしたが、今後要件が上がっていく可能性はあります。
そのときにブロッカーにならないように今のうちからあげていこうという判断をしました。

運用ルールの決定

「minSDKを上げたいよね」というチーム内での感覚の共有はできていましたが、どんなルールに基づいて運用していくかまでは定めていませんでした。
現状のおいしい健康Androidアプリのアクティブユーザー数と他社さまの事例などを参考に、チーム内で話した結果下記の方針に決まりました。

全体のアクティブユーザーの内、シェアが2%以下になったバージョンはサポートを終了する

シェアの調査

シャアの調査はGooglePlayConsole上で行いました。各OSバージョンごとのアクティブユーザー数が確認できます。
調査した日時点で、Android5とAndroid5.1のシェアが2%以下だったのでminSDKを23にすることが決まりました。

（余談ですが、このときおいしい健康Androidアプリでは、Android7よりもAndroid6のシェアの方が高かったです。）

影響範囲の調査

おいしい健康Androidアプリは有償プランがあります。minSDKを上げることにより、有料ユーザーのどれほどが影響を受けるのか事前調査が必要でした。
ログからAndroid5, Android5.1 を利用している有料ユーザーを特定しましたが、対象ユーザーはごく少数でリテンションもあまりないようでした。