株式会社Inner ResourcePublicationへの投稿
😸

Expo Bare WorkflowからManaged+dev-clientに移行しました

Yoshiaki Kondo
に公開
React Native
Expo
tech

はじめに

この記事では弊社(Inner Resource)の在庫管理のReact NativeアプリをExpo Bare WorkflowからExpo Managed Flow + expo-dev-clientに移行した話を紹介します。

React Nativeアプリを開発する際、2025年5月現在、Expoの選択肢としては主に以下の3つがあるかと思います。

  1. Expo Managed Workflow
    ネイティブコードの管理は全てExpoに任せる
  2. Expo Bare Workflow
    ネイティブコードを自分たちで全て管理する
  3. Expo Managed Workflow + expo-dev-client
    ネイティブライブラリも使いつつ、ネイティブコードの管理はExpoに任せる

今回は、2から3への移行について、その背景や手順、結果を共有します。

Expo Bare Workflowにした背景

元々、弊社のアプリではReact Native Firebaseのアナリティクス機能などを利用するため、Expo Bare Workflowを採用していました。

しかし、Bare Workflowには以下のような課題がありました。

  • Expo SDKのバージョンアップやAndroidのAPIレベルの更新、iOSのプライバシーマニフェスト対応など、ネイティブ側のメンテナンスも行う必要がある
  • 開発環境のMacのXCodeのバージョンアップなどが原因でビルドが通らなくなるなど、アプリ開発の環境構築に時間がかかってしまう
  • 弊社の場合はエンジニア全員がバックエンド、フロントエンド、インフラ、ネイティブアプリをフルスタックに触っているため、ネイティブアプリの更新にそこまで工数はかけたくない

今後もExpo Bare Workflowを利用していると、ネイティブ側のメンテナンスがネックとなってしまいます。また、そもそもReact Native Firebaseのアナリティクス機能も現状あまり活用できていない状況でした。

そのため今回はReact Native Firebaseの代わりに、弊社で既に導入していたNew Relicをアプリにも導入し、その上でManaged Flow + expo-dev-clientに移行する判断をしました。

Expo Managed Flow + expo-dev-clientへの移行でやったこと

1. 独自で修正したネイティブコードの差分を確認

まずは、弊社で独自にカスタマイズしていたネイティブコードを特定する必要があります。

  • ios、androidディレクトリを削除して expo prebuild した結果との差分を確認
  • 主にFirebase関連の設定や、特定のネイティブモジュールの設定が独自に修正されていましたが、それ以外は特に特別は設定は行なっていなかった

2. app.config.tsへの設定移行

独自で修正していたネイティブコードの必要な箇所は app.config.ts に同等の設定を追加しました。

export default {
  // 他の設定...
  plugins: [
    // NewRelicを導入
    "newrelic-react-native-agent",
    // 他のプラグイン...
  ],
  ios: {
    infoPlist: {
      // 権限周りなどの設定
    },
    privacyManifests: {
      // プライバシーマニフェストの設定
    }
  },
  android: {
    // Androidの設定
  },
};

3. 依存関係の確認とアップデート

使用しているネイティブライブラリがExpo Managed Flow + expo-dev-clientに対応していることを確認します。

4. expo-dev-clientの導入

npx expo install expo-dev-client

expoの起動コマンドにも --dev-client オプションを付与します。

{
  "scripts": {
    "start": "expo start --dev-client",
    "android": "expo start --android --dev-client",
    "ios": "expo start --ios --dev-client",
    ...
  }
}

5. EAS Buildの設定

eas.json にもEAS Buildの設定を追加し、シミュレータ用にビルドできるようにしておきます。

# eas.jsonの設定
{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "ios": {
        "buildConfiguration": "Debug",
        "simulator": true
      },
      "android": {
        "buildType": "apk"
      }
    }
  }
}

Expo Managed Flow + expo-dev-clientにした結果

メリット

ビルド環境の標準化

  • EAS Buildでビルドしたものをシミュレータや実機で動作確認すれば良くなり、ローカルの環境依存でのビルドエラーがなくなった

アップデートの容易さ

  • Expo SDKバージョンを上げる作業がかなり楽になった（ネイティブ側の差分を気にする必要がない）

課題と対応策

開発環境の制約

  • expo-dev-clientの場合はExpo GOは利用できないため、iOSやAndroidのシミュレータや実機の準備は必要

EAS Buildの無料枠制限

  • 環境構築や動作確認などで複数人でビルドをすると無料枠をすぐに使い切ってしまう

さいごに

課題がなくなったわけではありませんが、ネイティブコードのメンテナンスから解放され、フルスタックと並行してのネイティブアプリ開発も以前よりやりやすくなったかと思います。

弊社ではバックエンド、フロントエンド、インフラ、ネイティブアプリとフルスタックに開発したいエンジニアを募集しています。興味のある方はぜひ一度カジュアル面談にご応募ください。

参考リンク

GitHubで編集を提案
株式会社Inner Resource
株式会社Inner ResourcePublication

株式会社Inner Resource のエンジニアブログです。 忙しい研究者・研究施設の業務効率化のためのクラウド購買管理ソフト「リプルア」を開発しています。

Discussion