expoには、OTAアップデートというものがある。
$ expo publish
と打つと、開発者のパソコンの中のコードを使い、ユーザーのスマホの中のアプリを書き換えると言う技術だ。
つまり、アプリのアップデートを審査を通さずに行える。
さらに、アップデートの反映までなんと０分。
夢の技術が標準でついている。
(通常は、アプリのアップデートは審査で３日待たされたりするからね。)
また、デフォルトでついてくる、release-channelと言う機能を使うと、channnel毎に、アップデートが出来るので、staginig環境、本番環境を、サードパーティライブラリなしに実現できる。
release-channelの使い方
＄ expo publish --release-channel <環境名>
$ expo build:android --release-channel <環境名>
のように、release-channelの後ろに、任意の文字列を渡すだけ、
例
＄ expo publish --release-channel 'staging'
$ expo build:android --release-channel 'production'
渡した、任意の文字列は、コードの中で、以下のように参照できる。
import { Constants } from 'expo'
const env = Constants.manifest.releaseChannel
console.log(env) // => 'staging' など、
環境変数を作りたいときは、
const appName = env === production ? '本番アプリ' : 'ステージングアプリ'
のように、するといい。
OTAアップデートでは注意するべき点がある
ユーザーがアプリをインストールして初めて開いた時、expo publishしたバージョンではなくgoogle playにアップしたバージョンがユーザーに表示される！！
一見 expo publishが失敗したように見える。
しかしユーザーが、アプリを一度閉じて次に開くと、OTAアップデートが反映されたアプリが表示される。
なぜこのようなことが起きるかは、以下の例を見ていただくと分かる。
つまり、OTAアップデートの数だけ、ユーザーはアプリを再起動する必要がある。
例えば、version 1 を
$ expo build:android --release-channel production
とし、google play consoleに、apkをアップデートする。
次に、デザインに修正を加えたversion2を
$ expo publish --release-channel production
とし、アップデートする。
次に、致命的なバグを直す、version3を
$ expo publish --release-channel production
として、アップデートする。
この時、google play storeから初めてアプリをインストールしたユーザーの挙動は以下のようになる。
〜初めてアプリを開く〜
version1が表示される。
〜2回目にアプリを開く〜
version2が表示される。
〜３回目にアプリを開く〜
version3が表示される。
つまり、ユーザは、最新のバージョンのアプリを開くためには、アプリをインストールした後、OTAアップデートの回数、アプリを再起動しなければならない！！！
大きな機能の変更は、google play consoleにapkファイルを上げ、軽微な変更はOTAアップデートを使うというよういに使い分けるのがベスト
OTAアップデートで出来ないこと
アイコンの変更
アプリの名前の変更
アプリのスプラッシュスクリーンの差し替え
expo sdkのバージョンアップ
など、、、
結論
・OTAアップデートは便利だが、大きな機能を追加するときは、きちんとAPKファイルなどをgoogle play storeに提出しないと痛い目を見ることになる。
・Expo.updates.reload()と言うメソッドが用意されているので、それを利用することで、OTAアップデートのタイミングを制御出来る。
・apkを更新したいなら、OTAアップデートではなく、素直に
expo update:android
を使用した方がいいようだ。
ただ、上のコマンドは、かなり色々セットアップが必要になる。
おまけ
このヘンテコなexpo publishの挙動は、expo公式も問題視していて、twitterでこの仕様の改善した方が良いかアンケートをとっていた。
近い将来にこの仕様はひょっとすると変わるかもしれない。