してきたというか、開催したというか、そんな感じです。

↑の記事にも載せたスライドを再掲します。

見てもらえば概要はわかるかと思いますが、3行でまとめるとこんな感じ。

• アプリ（っていうかiOS）のリリースがめんどい、ちょっとした変更を出すのが億劫
• React NativeだとメインのJS部分がネイティブから独立してるから差し替えられる
• 差し替える仕組みとしてCode Pushってのがあるよ

実際に僕が開発しているアプリではちょっとした不具合修正とかレイアウトの調整みたいなものだけでなく、新しい機能のための1画面を追加するぐらいの勢いでCode Pushを使っています。

とはいえデメリットもないことはないので、今日はデメリットをちょっとだけ紹介します。

リジェクトの可能性がわずかながらある

これは当日話しました。codepushのIssueにあるように、リジェクトされたという声がときどきあるようです。

ですが、多くの人はそんなことないよと言っているようなので、これはあまり大きなデメリットにはならないと思います。

アプリを壊すことがある

Code Pushによるアプリ（JS）の更新が行われるのはアプリ起動後に非同期で行われます。その間にアプリの起動自体は動き続けますので、一旦起動したあと画面の読み直しが入るような動きになります。

（正確にいうと、Code Pushを使っても必ずこのようになるわけではありません。ユーザーに確認を求めたり、次の起動時まで反映しないというやり方も可能です。）

アプリが壊れるタイミングは、アプリが起動時の処理にバグを含むようなバージョンをCode Pushで配信してしまった場合です。

1. 正常に起動するバージョンでアプリを起動する
2. 裏でCode Pushによる更新が入る
3. アプリが読み直される
4. バグにより起動しない

となって起動しなくなります。

その後Code Pushで修正版を配信したとしても、

1. アプリを起動する
2. アプリが死ぬ
3. 裏でCode Pushによる更新が入る

Code Pushの更新前にアプリが死ぬため永久にバグったままとなります。

こうなってしまうとネイティブビルドで配るほかありませんので、通常のネイティブアプリの更新と同じような手順でアップデートしなければなりません。

気軽に配れるのが仇になる例でした。