EASの誕生の経緯
この2つの記事に書いてる内容の要約
Expo managed workflow in 2021. Part 1: The preset Expo runtime
Expo managed workflow in 2021. Part 2: Customizing the runtime
2021/4頃、Expo SDK v41のリリースらへんの話
前提
「JavaScriptのコードを実行できる」ためには以下のようなものが揃っている環境が必要
①Update Layer
自分で書いたコード
「bundle」と呼んだりする
②Native Layer
runtime (特にExpoの場合)
ECMAScriptの仕様に基づく標準関数の定義
React Native
いわゆるnative code
Expo SDK
JavaScript Runtimeにメモった
従来 (EAS以前)
どういう風にランタイムを扱っていたか?
開発時と本番時で分けて考えると良い
開発時は、Expo Goのランタイムを使っていた
Expo Goの中にExpo SDKや、native codeが含まれている
要するに、ランタイムは自分で拡張できないmrsekut.icon
本番時は、buildしてstandalone appにしていた
Turtleというbuild toolを使う
standalone appとは
$ expo build:iosなどで生成したバイナリのこと
runtimeを内蔵したshell appのような感じかなmrsekut.icon
Expo Goなどのランタイムに依存せずに実行できる
このruntime部分にはnative codeなども含まれる
これをstoreで配布することでuserに届けられる
要するに、ランタイムは自分で拡張できないmrsekut.icon
EAS以前の開発の流れ ref
https://gyazo.com/bfe4e998be7d9e710d915eb6c9bdd0a3 https://blog.expo.dev/expo-managed-workflow-in-2021-5b887bbf7dbb
開発時、Preview時は、Expo Goのランタイムを使う
本番向けにBuildする際に、standalone appを作って、それを配布する
以下のことを意識することが重要である
開発時と本番時はランタイムの扱いが異なる
両者ともに、ランタイムの拡張をすることはできない
ExpoのOTA updateで更新されるのは、Bundle部分のみ
ランタイムは更新されない
上記のやりかたでは問題がいくつかある
native codeを使用するlibraryを使えない
従来、この問題を回避する方法がλ expo ejectだった
ランタイムを自分でカスタマイズする状態に移行させる
ただし、1度行うと元に戻せない
Expoのサポートが部分的にしか受けられなくなる
native codeを自分で管理しないといけなくなる
build sizeが無駄に大きい
standalone appを作る際に、Expo SDKの全てを含める
使用するかどうかに限らず、Expo SDKが提供するlibraryが全て含まれる
その結果、build sizeが無駄に大きくなる
上記の問題はいずれも「runtimeを自分でカスタマイズできない」ということに起因する
この2層がある時に
①Bundle
②Runtime
①の方は、従来から独自で記述することができた
②の方を、ejectなしで行いたい、という要望がある
上記の問題を解決するために、EASが作られた
②を自分でカスタマイズできるようになった
ここで、②をどのようにしてカスタマイズするか、が論点になる
これは、本番環境と開発環境で分けて考えると良い
本番と開発でアプローチの仕方が異なる
本番環境でのアプローチ
繰り返しになるが、従来は以下のいずれかだった
拡張不可能なstandalone appを作る
Expoのサポートを受けづらくなるが、ejectする
EASではλ npx expo prebuildを使って、ejectなしでruntimeのカスタマイズをする
つまり、native codeを操作するlibraryも扱える
native codeに対して設定が必要なものはConfig Pluginsを使う
これは、app.jsonに記述するだけで良い
自分でnative codeの内部を触れずに、native codeの設定ができる
build前にλ npx expo prebuildを実行する
毎回のbuildの前に$ expo ejectをするイメージ
λ npx expo prebuildは、build前に行うだけなので、通常の開発には影響しない
native codeの管理はExpoに任せつつも、runtimeを拡張できる
また、Expo SDKを全部入れることもしなくなった
アプリ内で使用されているもののみをlinkするようになった
これによって、build sizeをかなり小さくできる
開発環境(実機)でのアプローチ
従来はExpo Goを使っていたが、そのままではruntimeを拡張できない
そこでexpo-dev-clientを使う
コレ自体が、native codeに影響を与えるlibrary
初回にスマホの登録をし、prebuildとbuildすると以降はExpo Goと同じノリで使える
native code部分に修正があった場合はbuildをやり直す必要がある
たぶんmrsekut.icon
release buildする時は、この実装は不要なので削除される
開発環境(simulator)でのアプローチ
iOSの場合のみ追加の設定が必要 ref
code:eas.json
{
"build": {
"development": {
"ios": {
"simulator": true
}
}
}
}
(まだmrsekut.iconが成功していないのでちゃんと書けない)
チーム内で配布するときのアプローチ
以前はTestFlightを使うしかなかった
そのためには、buildして、app storeにuploadまでする必要がある
EASでは、Internal Distributionを使えば良い
これもeas.jsonに1行追記するだけ
build後に、expo.devからinstallできる
(まだmrsekut.iconが成功していないのでちゃんと書けない)
まとめ
ざっくりこの2層があるということ
①Bundle
②Runtime
ECMAScriptの仕様に基づく標準関数の定義
React Native
いわゆるnative code
Expo SDK
この②の方の拡張が、ejectなしでできるようになったのがEAS Build
また、ExpoのOTA updateで更新されるのは①の方のみ
②に影響する変更はOTA updateでは対応できない
これに対処する方策がEAS Update
開発のフロー
https://gyazo.com/c5d85e108f189606e1380fcceacfcf95 https://blog.expo.dev/expo-managed-workflow-in-2021-d1c9b68aa10
runtimeをどう扱うか?という話だが、シチュエーションによって設定が必要でややこしい
table:_
従来 EAS
本番環境 expo build expo prebuild & eas build
開発環境(実機) Expo Go expo-dev-client or Expo Go
開発環境(ios simulator) expo start expo run:iosなど
チーム内で配布 TestFlight Internal Distribution or TestFlight
ランタイムのカスタマイズ ↑不可能 ↑可能
記事内ではあまり触れられてないが、CIでかなり楽できる
master branchにmergeしたら、自動でEAS Build → EAS Submit
というようなCIを作っておけば、(時間はかかるものの)mergeさえすれば完了、とできる