現状で EAS Update のストア規約に違反しない主な使い方というのは、FAQ の以下に集約されていると考えます。
EAS Update is a great way to quickly deliver improvements to the people who use your apps. For example, consider an app that has a critical bug that needs to be fixed. With EAS Update you can quickly get the fix out and later follow up with a new submission that includes the fix built in.
また、それによって内製化を選択できることは EAS Update 自体の魅力ではないと思うのですが、いかがでしょうか？
EAS Update は若干コストが高く、とにかくめんどうな OTA を投げるか、自前で抱えるかというのは最初からトレードオフになる気がします（多くのサービスにも言えることですが…）。
途中で EAS Update をやめてインフラを内製化することで、開発コストと長期的なメンテナンスコストが発生する時、それがペイするか？を考えるのも若干難しいです。
将来的にスケールした場合でも、他のサービスに乗り換えるか、多少割高でも EAS Update を使い続けよう…という話にはなりそうです😇
Discussion
とても素晴らしい記事でした。
OTA アップデートについて、補足があった方が良さそうだなと思うことがあり、恐縮ですがコメントを…🙏
「ストア規約に違反しない範囲」とは、どこまでの範囲を指すのでしょうか？
後に記述されている「ランタイムで機械語を差し替えること」でしょうか？
明示されている箇所がないので、各々の解釈に委ねられています、というのが正直な回答になるのだとは思いますが…😢
Microsoft Code Push の README や Shorebird の FAQ では、OTA の仕組みでダウンロードできるのは Interpreted code だから OK という解釈です。ただ、それによる変更は節度を守ってね、的な記載がどちらも添えられています。
Apple Developer Program license agreementの 3.3.1 B または C に引っかかる可能性は否定できず、ぼかすしかなさそうな事情はありそうです（深く追ってはないのですが…）
現状で EAS Update のストア規約に違反しない主な使い方というのは、FAQ の以下に集約されていると考えます。
また Shorebird の FAQ を見ても、想定される用途はパッチやバグフィックスがメインのように思えます（最後の項目はなんだかぼかしてるのが気になりますが…）。
Zenn ですとツルオカさんの以下の見解が、現状では自分も無難なものだと思いました。
詳細にコメントいただきありがとうございます！
おっしゃる通り解釈の問題であり、ツルオカさんの見解はまさに無難な解釈だと思います。
さらに言えば、インタプリタというのも解釈の広い言葉ですよね。
極論、CPUを機械語インタプリタと捉えれば、「ランタイムで機械語を差し替えること」も問題ないと言い張れるかもしれません（技術的にはサンドボックスを超えたメモリアクセスが不可能そうですが）。
総じて、ストア側もOTAサービスプロバイダ側もあえてぼかしているであろう領域なので、ストア側がこの規約によって守りたいことに想いを馳せて「怒られないようにやる」しかないんだと思ってます。答えにならない回答ですみません。
めちゃくちゃ nits ですが、プロトコル仕様（Expo Updates v1）は EAS Update ではなく Expo Updates のものだと思います。
また、それによって内製化を選択できることは EAS Update 自体の魅力ではないと思うのですが、いかがでしょうか？
EAS Update は若干コストが高く、とにかくめんどうな OTA を投げるか、自前で抱えるかというのは最初からトレードオフになる気がします（多くのサービスにも言えることですが…）。
途中で EAS Update をやめてインフラを内製化することで、開発コストと長期的なメンテナンスコストが発生する時、それがペイするか？を考えるのも若干難しいです。
将来的にスケールした場合でも、他のサービスに乗り換えるか、多少割高でも EAS Update を使い続けよう…という話にはなりそうです😇
こちらもありがとうございます！
そうですね、厳密には Expo Updates のプロトコルに準拠したサービスプロバイダが EAS Update ですね。
Expo Updates というプロトコルとクライアント実装が EAS Update から分離されていることで、後からプロトコル準拠のOTAサーバを内製するだけで差し替えられることは魅力だと思っています。
おっしゃる通り、EAS Updateと内製にはコストのトレードオフがあります。初期的にはEAS Updateの従量課金も少ないですから、内製コストはペイしないですよね。ただ、Expo Updatesプロトコルはそこまで難しいものでもないですし、参照実装も公開されているため、スケールして従量課金が膨らんだ場合には十分に内製を検討する余地があると考えています。
もちろん内製コストは社内の様々なコンテキストに依存しますから一概には言えませんが、大事なのは、SaaSとプロトコル/クライアントの分離によって、スケール後に内製を検討する余地が現実的に残っていることだと思います。
capacitorをやめた理由は、エコシステムの弱さ、プラグインのアップデートの厳しさなどになりますでしょうか。（あとはネイティブと比べたときの速度差とか？）
capacitorをやめた理由をもうちょっと詳しく知ることができたら嬉しいです。
コメントありがとうございます！
まさにエコシステムの弱さは主要な理由の1つです。
レンダリングのパフォーマンスについては、Webも十分に速いため問題にはなりませんでした。
ただ、WebView1枚の表現力に限界があり、アプリに求める体験（下タブごとにスタックを持ち状態が維持されるなど）をエミュレートしきれないため、どうしても「アプリっぽくない」体験が残ってしまいました。
独自スタック管理とかView Transition API とかで頑張ることもできると思いますが、無理に頑張るよりは、自然に実現できるネイティブに寄せちゃおう、という判断です。
ありがとうございます。大変参考になりました。
一応補足すると、すでにWebアプリがグロースしてる状態で、モバイルアプリの可能性を検証する手段としては最高でした。過去に戻ってやり直すとしてもCapacitorで始めると思います！