【ReactNative】単一ソースを複数アプリ(target)にビルドしたときの話

背景

同じようなシステムを別のターゲットに少しだけ内容を変えてリリースしたいという状況だった。 具体的には、国家試験対策アプリを歯科医師用歯科衛生士用に出したかった。 歯科医師用アプリはiOS, Androidでリリース済みで、衛生士用も同じく両プラットフォームで出したかった。 システムはほぼ同じで、コンテンツ(クイズの内容・カテゴリ)と少しのUI、iconなどだけ変えて別アプリとして出したかった。

検討したこと

1. xcodeでtargetを2つ作る
2. 共通部分をnpm pacakge化
3. 【採用した】共通部分をgit submodule化

採用しなかったやつとその理由

1. xcodeでtargetを2つ作る

これが一番スマートだと思って、一度はやってみた。しかし、

- iOS, Android両方でビルドを分けるのは思ったより大変だった
- targetによって切り分ける処理はネイティブコードでしかできない(僕調べ)ので、環境変数
などで切り分けるしかなくてメリットが小さかった
- ※1 ReactNative特有の原因により、解決困難なエラーが出まくった
- だだでさえ不確定要素の多いReactNativeで、nativeでもあまりやらないことをすると危険

swiftとかで書かれたアプリなら、この方法(複数targetを作る)が良いんだと思う。この方法はネット上に意外と多く転がっているので、swiftなら時間かけずにできそう。

※1 ReactNative特有の原因により、解決困難なエラーが出まくった => 詳しくは割愛する(後日書くかも)が、ReactNativeの実装上、複数targetにビルドするのは想定されていない気がしている。

2. 共通部分をnpm pacakge化

2と3は似ているが、submoduleによる管理・共通化の方が運用が楽そうだった。(後述) あと単純に、npm pacakgeに詳しい人よりもgitに詳しい人の方が世の中に多そうなので引き継いだ人が楽になる可能性が高いと判断した。

【採用した】共通部分をgit submodule化

git submoduleについては詳しく触れないが、使いどころさえミスらなければ非常に便利だと思うので知っておくと良いと思う。 f:id:yooska14:20181206165212p:plain 今回のプロジェクトはこんなディレクトリ構成になっていて、基本的な実装部分はsrc以下にまとめた。 そして、今回submodule化したのはsrc以下の全て。 画像を見ればわかるように、redux関連の処理と各スクリーン・コンポーネント、ナビゲーション設定系も全てまとめている。

submoduleを使ったメリットは沢山あるしsubmoduleについて調べれば分かりやすいと思うので割愛するが、大きなデメリットが1つあるので紹介する。それは依存ライブラリのリンク(Linking Libraries)をプロジェクトごとにしなければならないことだ。(Linking Librariesについては「参考」のリンク参照)

NativeがいじれないからReactNaitveを選定したのに結局触らなアカンのかい!って気持ちになるのをプロジェクトごとにやるのか。。って気持ちになるが、意外と2回目の作業は詰まらずいけた。むしろ復習になってすごく理解が進んだ。なのでこれについては実はあまりデメリットに感じていない。 ただ、複数人でプロジェクトを回す場合はやはり大きなデメリットになるかも。

追記

BuildSettings (iOS), BuildVariant (Android)を使うとプラットフォーム側でビルド時に処理してくれるらしい。 speakerdeck.com

参考

qiita.com

facebook.github.io

【ReactNative】iOSアプリのリリースフロー

前提・背景

この記事は、「使用中のmacで1度以上iOSアプリをリリースしたことがある」前提です。 自分がその状態のため、思い出しながら備忘録として書いています。 リリース経験がない人は、この記事最下部におすすめ記事を書いているので、それがすごく参考になると思います。 この記事の対象読者にとっては、「この部分は1回だけで良いんだ」「この作業は毎回必要なんだ」という風に理解が進む狙いなので、お役に立てると思います。

そして、

使用中のmacで1度以上iOSアプリをリリースしたことがある というのは具体的に以下の3つの前提を指しています。

  • Appleの開発者登録(Apple Developer Program)が済んでいる前提です。 登録 - サポート - Apple Developer

  • iOS Certificateが作成されている前提です。 iOS CertificateはXcode上でアプリを実機用にビルドするのに必要なもの。逆に言えば、一度作成しているとそれ以降は必要ない。 以下の記事がすごく詳しい(少し古いが2018-12-04現在問題ない)のでおすすめです。 i-app-tec.com

  • Provisioning Profile Provisioning ProfileもXcode上でアプリを実機用にビルドするのに必要なもののようです。 作成手順に関してはやはりこちらの記事が詳しいです。 iOSアプリ Provisioning Profile を作ってみる

リリースの流れ

1. App IDを作成
2. AppStoreConnect上でアプリを作成
3. XcodeでArchive

以上になります。下記に1つ1つについて詳しく書きます。

1. App IDを作成

Sign In - Apple へ飛びます。画像のようにApp IDを新規作成します。f:id:yooska14:20181204163459p:plain

  • App ID Description(IDの説明)
  • Explicit App ID
  • App Services を入力します。Explicit App IDはつまりBundle IDです。(Xcodeで設定するやつ・アプリ固有のID) 基本的にはリバースドメイン(アプリ名を逆にしたやつ)が推奨されています。 例: news.oned.jp => jp.oned.news

App Servicesに関しては、使用している機能だけにcheckが基本です。checkしていない機能を使っていたら審査時にリジェクトされることは当たり前ですが、逆に使ってない機能にcheck入れすぎてると怒られるらしいです。(経験なし) が、実際、PushNotificationsとか「後々使うよなー」って機能は入れちゃってます。怒られた試しはありません。「とりあえず全部チェック入れとく」とか適当なことせずにいくつかだけチェック入れるなら良いんだと思います。(Appleも審査大変やろ)

以上3つを全て入力し、Continue => Submitすればdoneです。

2. AppStoreConnect上でアプリを作成

https://appstoreconnect.apple.com/ へアクセスし、「新規 App」を作成します。 f:id:yooska14:20181204165813p:plain

  • プラットフォーム(大体iOSでしょう)
  • 名前(アプリ名)
  • プライマリ言語(大体日本語でしょう)
  • バンドルID(「1. App IDを作成」を経ていたら選択肢として出るはずです)
  • SKU(Appleが内部で使うIDらしい。僕はbundleIDと一緒にしています。なんでも良さそう)
  • ユーザアクセス(「なし」で良いでしょう)

を入力します。 これで、Xcode上でArchiveができるようになります。

3. XcodeでArchive

f:id:yooska14:20181204171300p:plain 以上を入力して、メニューバーからProduct => Archiveすればアップロード完了です。

参考にした・関連おすすめ記事

i-app-tec.com qiita.com