酢ろぐ!

カレーが嫌いなスマートフォンアプリプログラマのブログ。

Xcode 12.3のiOS 14.3シミュレータを起動すると画面が黄色くなってしまう問題を解決した

今朝起きたらXcode 12.3が公開されていたので、Xcode 12.3をダウンロードして開発中のアプリが動くかどうか検証しようとしたところ、UIAlertControllerが真っ黄色になっていたので腰をぬかしました。すんげえエンバグしてもうたと慌てて原因を調査しました。

iOS 14.3 シミュレータの画面が黄色くなってしまう問題が発生

何度かデバッグ実行を繰り返したところ開発中のアプリは関係なく、そもそもとして iOS 14.3シミュレータ を実行するとドック部分が黄色くなっていることに気がつきました。黄色くなる部分はドック(?)やナビゲーションバーやタブバーの部分やアラートなどの半透明になっている部分です。

f:id:ch3cooh393:20201215152911p:plain

以下の環境で不具合が発生することを確認した。

  • Big Sur 11.0.1(20B50)
  • Xcode 12.3
  • iOS 14.3 シミュレータ

ちなみに Big Surのバージョンを 11.1(20C69) に上げても問題は発生します。macOSのバージョンは不具合の原因としては直接的には関係なく、iOS 14.3シミュレータに問題があることがわかりました。

SOにも報告あり

Stack Overflowにも同一の現象について書き込みがあるのをみつけた。

この質問者の方は以下の組み合わせで実行しているようです。

  • Catalina 10.15.7
  • Xcode 12.3
  • iOS 14.3 シミュレータ

Twitterでも報告あり

Twitterでも同じ現象の書き込みを見つけた。こちらの方は実行しているOSバージョンについての言及はなかったけれど「外部ディスプレイを接続していたら発生した」と書かれている。

うちでは外部ディスプレイを使ってないのに発生しているのだが?と思ってハマり続けていた。

解決編:MacBook Proに刺さっている充電ケーブルを抜いて iOSシミュレータを再起動する

何度かiOSシミュレータの再起動して試したところ、正しい対応策かはわからないけど解決策が判明しました。以下の方法で問題が解決することを確認しました。

  1. 充電ケーブルを含むすべてのケーブルを抜く
  2. 実行中のiOSシミュレータを再起動する

つまりは、「MacBook Proに刺さっている充電ケーブルを抜いて iOSシミュレータ を再起動する」 です。HDMIケーブル以外にも充電ケーブルも刺さっていると黄色画面現象が発生しました。しかしなんでこんなことが起こってしまうのか。

私と同じ現象に遭遇した場合には、充電ケーブルも抜いて iOS シミュレータを起動しましょう!!

解決編(その2):iOSシミュレータの GPU設定 を変更する

そもそもケーブルが刺さっているとGPU設定が変わるのが原因ではないかと指摘があり、iOSシミュレータのタブバーから File -> GPU Selection -> Prefer Integrated GPU をONにすることでも半透明が正しく表示されました。

f:id:ch3cooh393:20201215214530p:plain

私と同じ現象に遭遇した場合には、iOSシミュレータのGPU設定を変更してみてください!

iOSアプリのdSYMファイルをBitriseからFirebase Crashlyticsへアップロードする #bitrise #bitrisearticle

この記事は、Bitrise Advent Calendar 2020の1日目の記事です。夕食を食べて帰ってきてアドベントカレンダーを覗いたところ、20時時点で誰もエントリーしていなかったので書くことにしました。

Bitriseとは

今年に入ってからこのブログでも、Bitriseを使ってiOSアプリのビルド時間の短縮に挑戦する記事Firebase iOS SDKをCocoaPods経由でインストールしたときにどれだけビルド時間が伸びるかなど紹介してきました。

弊社ではプロジェクトごとにじわじわとJenkinsからBitriseへの移行がおこなわれていましたが、現時点で完全にBitriseへの移行が完了しています。関係者が多いプロジェクトだとProvisioning Profile(プロビジョニングプロファイル)の更新が頻繁に発生して、更新処理が大変だったので随分と負荷が下がりました。Jenkinsおじさんは引退です。

もしBitriseを使ってみたい方がいれば↓のリンク経由でアカウントを作っていただければ、ビルド時間が5分伸びるみたいです!

iOSアプリのdSYMファイルがBitriseからFirebase Crashlyticsへ送信できていない

個人で開発しているアプリのクラッシュ情報はFirebase Crashlyticsに送るようにしています。久しぶりにFirebase Consoleにアクセスしたところ、ここしばらくdSYMファイルがFirebase Crashlyticsへ送信できていないことがわかりました。

f:id:ch3cooh393:20201201195404p:plain

f:id:ch3cooh393:20201201195223p:plain

不足している必須のdSYMをアップロードしてください と怒られていました。これはいけない。

Xcodeでリリースバイナリを作成する際(ビルドフェーズ)にdSYMファイルを送信するようにしていましたが、Xcode 12対応を入れたあたりから送信できてなかったようです。

if [ $CONFIGURATION = "Release" ]; then
"$SRCROOT/bin/FirebaseCrashlytics/run"
fi

アーカイブ後に直接 upload-symbols を実行してアップロードする

xcode-archiveステップのあとであれば、dSYMファイルに $BITRISE_DSYM_PATH でアクセスすることができます。直接 upload-symbols を実行して dSYMファイルをアップロードすることにしました。

    - xcode-archive@2.8:
        inputs:
        - project_path: "$BITRISE_PROJECT_PATH"
        - scheme: ptcgnote
        - export_method: app-store
    - script@1.1.6:
        title: Firebase Crashlytics
        inputs:
        - content: |-
            #!/usr/bin/env bash
            chmod +x ptcgnote/bin/FirebaseCrashlytics/run
            chmod +x ptcgnote/bin/FirebaseCrashlytics/upload-symbols
            ptcgnote/bin/FirebaseCrashlytics/upload-symbols -gsp ptcgnote/ptcgnote/Resource/GoogleService-Info.plist -p ios $BITRISE_DSYM_PATH
    - deploy-to-itunesconnect-application-loader@0.11:
        inputs:
        - password: "$APPLE_PASSWORD"
        - itunescon_user: "$APPLE_ID"

upload-symbolsのパスが Pods/FirebaseCrashlytics/upload-symbols でないのは、Firebase iOS SDKをCarthage経由でインストールしているからです。CocoaPods経由でインストールしている方は適宜パスを読み替えていただければと思います。

あとは追加したscriptステップが下図のようにうまく動くのを確認すれば、対応は完了です。

f:id:ch3cooh393:20201201203003p:plain

おわり。

Carthage経由での FirebaseAdMobBinary v7.1.0 のインストールに失敗する

昨日、Firebase iOS SDKが v7.1.0 にアップデートされた。Bitriseでのビルド時間を最短にするためにFirebase iOS SDKもCarthage経由でインストールしている。

いくつかのプロジェクトでライブラリのアップデートを実行していったところ、とあるプロジェクトでのみCarthageのアップデート処理が中断されてしまうことがわかった。

Carthage経由での FirebaseAdMobBinary の v7.1.0 のインストールに失敗する

gist.github.com

試したこと

Issueに書かれているコメントを参考にして、キャッシュを削除してからCarthageコマンドを実行したが同じエラーが発生した。

rm -rf Carthage
rm -rf ~/Library/Caches/org.carthage.CarthageKit
bin/carthage.sh update --platform ios --cache-builds

直接carthageコマンドを使ってないのは「BitriseでXcode12+Carthageを使ってiOSアプリをビルドしよう! - 酢ろぐ!」で書いた通り。

応急処置的に AdMobだけ v7.0.0 を使うようにした

Carthage経由で AdMob をインストールしている人がいないのか、一向に同じ現象に当たるひとがいません。うちの環境だけかもしれないので AdMob が安全にアップデートできるようになるまではバージョンを v7.0.0 に固定しておきたいと思います。

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseCrashlyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAdMobBinary.json" == 7.0.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseProtobufBinary.json"

CarthageでNYTPhotoViewerをアップデートすると10月23日以降ビルドエラーが発生する

BitriseでXcode12+Carthageを使ってiOSアプリをビルドしよう! - 酢ろぐ!」のエントリを書いてから、僕は開発中のプロジェクトをXcode 12+Carthage環境に戻しています。

Firebase関係をCarthage経由でインストールできるのでCIでのビルド時間が2〜3分短縮できてホクホクしていました。

ある日いつものようにCarthageのアップデートをしていると途中でビルドが止まってしまいました。

問題発生

2020/10/23に NYTPhotoViewer のアップデートがあり、Carthageを使っていると NYTPhotoViewerでビルドエラーが発生してしまう現象が発生しています。具体的にはNYTPhotoViewerが依存しているPINRemoteImageでビルドエラーが発生します。

*** Building scheme "PINOperation" in PINOperation.xcodeproj
*** Building scheme "PINCache" in PINCache.xcworkspace
*** Building scheme "PINRemoteImage" in PINRemoteImage.xcworkspace
Build Failed
    Task failed with exit code 65:
    /usr/bin/xcrun xcodebuild -workspace /Users/ch3cooh/Documents/works/ptcgnote_app/ptcgnote/Carthage/Checkouts/PINRemoteImage/PINRemoteImage.xcworkspace -scheme PINRemoteImage -configuration Release -derivedDataPath /Users/ch3cooh/Library/Caches/org.carthage.CarthageKit/DerivedData/12.1_12A7403/PINRemoteImage/3.0.3 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/_2/9d5qvdq90tx6x15mpsw0bxmr0000gn/T/PINRemoteImage SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/ch3cooh/Documents/works/ptcgnote_app/ptcgnote/Carthage/Checkouts/PINRemoteImage)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/_2/9d5qvdq90tx6x15mpsw0bxmr0000gn/T/carthage-xcodebuild.1UqBEE.log

解決編(?)

まったく解決していないのですが、NYTPhotoViewerをCarthage経由でインストールするのをやめてCocoaPodsでインストールするようにしました。

Firebase関係と同じようにNYTPhotoViewerはcocoapods-binaryが使えないのでCIでのビルド時間は伸びる傾向にあります。そのためキャッシュを効かせたかったのですが回復するまでは CocoaPods経由でインストールした方がよさそうです。

実行環境

  • Xcode 12.1
  • CocoaPods v1.10
  • cocoapods-binary 0.4.4
  • Carthage 0.36.0

CocoaPodsをv1.10にアップデートすると cocoapods-binaryを使っているプロジェクトでビルドエラーが発生する

Xcode 12でCarthageが使えなくなって、CocoaPods + cocoapods-binary の構成に移行した方は多いのではないかと思います。僕もそのうちのひとりです。

CocoaPodsはCIサービスでリリースビルド(ipaファイルをエクスポート)する際には毎回フルビルドされます。そのためビルド時間が伸びる傾向にあります。

cocoapods-binaryを使うことで事前にプリビルドしておき、CIサービスでのビルド時間を短縮することができます。cocoapods-binary については、以前エントリを書いたのでよければご覧ください。

CocoaPods v1.10にアップデートするとビルドエラーが発生する

本日 CocoaPods v1.10がリリースされたのでアップデートして、cocoapods-binaryを使っているプロジェクトをビルドしたところ下記のようなエラーが発生しました。

sent 201 bytes received 26 bytes 454.00 bytes/sec total size is 85 speedup is 0.37 rsync --delete -av --filter P .*.?????? --links --filter "- CVS/" --filter "- .svn/" --filter "- .git/" --filter "- .hg/" --filter "- Headers" --filter "- PrivateHeaders" --filter "- Modules" "/Users/ch3cooh/Library/Developer/Xcode/DerivedData/MediaCropper-fxsikdwktzbzvbfokxppfrwokuwk/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/UIDeviceIdentifier.build/DerivedSources/UIDeviceIdentifier.framework.framework.dSYM" "/Users/ch3cooh/Library/Developer/Xcode/DerivedData/MediaCropper-fxsikdwktzbzvbfokxppfrwokuwk/Build/Products/Debug-iphonesimulator/UIDeviceIdentifier" building file list ... rsync: link_stat "/Users/ch3cooh/Library/Developer/Xcode/DerivedData/MediaCropper-fxsikdwktzbzvbfokxppfrwokuwk/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/UIDeviceIdentifier.build/DerivedSources/UIDeviceIdentifier.framework.dSYM" failed: No such file or directory (2) done

sent 29 bytes received 20 bytes 98.00 bytes/sec total size is 0 speedup is 0.00 rsync error: some files could not be transferred (code 23) at /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/main.c(996) [sender=2.6.9] Command PhaseScriptExecution failed with a nonzero exit code

解決策

Podfileに「Errors using CocoaPod 1.10.x · Issue #132 · leavez/cocoapods-binary · GitHub」で紹介されているスクリプトを追加します。Podsディレクトリを削除してから pod update すれば、いままで通りビルドが通るようになります。

手元のプロジェクトのPodfileは以下のようになりました。

plugin 'cocoapods-binary'

# Uncomment the next line to define a global platform for your project
# source 'https://cdn.cocoapods.org/'
platform :ios, '13.0'

enable_bitcode_for_prebuilt_frameworks!
keep_source_code_for_prebuilt_frameworks!

target 'MediaCropper' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!
  inhibit_all_warnings!

  # Pods for MediaCropper
  pod 'R.swift', :binary => true
  pod 'LicensePlist', :binary => true
  pod 'UIDeviceIdentifier', :binary => true
  pod 'Dollar', :binary => true

  target 'MediaCropperUITests' do
    # Pods for testing
  end

end

# 追加する
post_integrate do |installer|
  installer.pods_project.targets.each do |target|
    target.shell_script_build_phases.each do |phase|
      script = phase.shell_script
      if script.include? "-copy-dsyms.sh\""
        script = script.delete_prefix "\"${PODS_ROOT}/"
        script = script.delete_suffix "\"\n"
        script = "Pods/" + script

        contents = File.read(script)
        contents = contents.gsub(/-av/, "-r -L -p -t -g -o -D -v")
        File.open(script, "w") do |file|
          file.puts contents
        end
      end
    end
  end
end

Xcode 12のリリースから1ヶ月経ってさまざまなノウハウが共有されてくるようになりました。おかげで僕はXcode 12でCarthageを使えるようになりました。もしお困りの方がいればこちらの記事も合わせていかがでしょうか。

cocoapods-binaryはしばらくメンテナンスされていませんでしたが、Xcode 12でCarthageが使えなくなり cocoapods-binaryを使うユーザーが増えたからか、久しぶりにプロダクトに手が入り始めました。この問題もいずれ解決されると思います。

実行環境

  • Xcode 12.1
  • CocoaPods v1.10
  • cocoapods-binary 0.4.4

参考記事

BitriseでXcode12+Carthageを使ってiOSアプリをビルドしよう!

Xcode 12になって悲しいことにCarthageが使えなくなりました。説明するまでもありませんが、CarthageはiOSアプリ開発の主要なパッケージマネージャーのひとつです。

開発を止められないお仕事アプリは即日ですべてCocoaPodsへ移行しました。CocoaPodsは導入が簡単なので大好きなのですが、ビルド時間が長くなる傾向にあります。デバッグ実行のたびにつらみが増します。過去に「Bitriseで iOSアプリのビルド速度を cocoapods-binary を使って高速化する - 酢ろぐ!」で紹介したように、CI上ではcocoapods-binaryを使ってビルド時間の短縮を狙うことが可能です。

Apple公式であるSwiftPMへの移行も検討しましたが、Bitriseでキャッシュが効かずCIでのビルド時間が増えてしまうので不採用になりました。

Xcode 12の劇的なリリースから1ヶ月経って状況も落ち着いてきたので、Bitrise+Xcode12でCarthageを使ってiOSアプリをビルドするように戻しました。

実行環境

  • macOS 10.15.7 (19H2)
  • Xcode 12.0.1
  • Carthage v0.36.0

古いバージョンのCarthageを使っている場合には、Mac HomebrewでCarthageをアップデートしておくと良いかもしれません。

brew upgrade Carthage

Carthageは頻繁にアップデートがおこなわれないのでみんな最新のものを使っているかと思います。

carthage.shを準備する

この項目はまるっと 「Carthage/Xcode12Workaround.md at master · Carthage/Carthage · GitHub」 からの引用が多いです。WorkaroundスクリプトはXcodeのバージョンによって変わってしまうかもしれませんので、随時適切なスクリプトに読み替えてください。本記事では2020/10/16時点のスクリプトを利用しています。

carthageのコマンドの代わりに carthage.shスクリプトを使います。

mkdir -p bin
touch bin/carthage.sh

Carthage/Xcode12Workaround.md at master · Carthage/Carthage · GitHub」 から、スクリプトをまるっとコピーします。

# carthage.sh
# Usage example: ./carthage.sh build --platform iOS

set -euo pipefail

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT

# For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise
# the build will fail on lipo due to duplicate architectures.

CURRENT_XCODE_VERSION=$(xcodebuild -version | grep "Build version" | cut -d' ' -f3)
echo "EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$CURRENT_XCODE_VERSION = arm64 arm64e armv7 armv7s armv6 armv8" >> $xcconfig

echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$(XCODE_PRODUCT_BUILD_VERSION))' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

export XCODE_XCCONFIG_FILE="$xcconfig"
carthage "$@"

本プロジェクトでのディレクトリ構成

なお、本記事での紹介に使っているプロジェクトのディレクトリ構成は下図のようになっています。ルートディレクトリにプロジェクトファイルは置いていません。

f:id:ch3cooh393:20201016095935p:plain

BitriseのScriptステップでこの carthage.sh を実行しますので、本記事を読んで「Bitriseで動かないよ〜」という方がいれば適宜読み替えてください。

Bitriseでの設定

ローカルPC上でCarthage経由でライブラリをインストールするのは以下のコマンドを実行すればよいです。

chmod +x TweetClips/bin/carthage.sh
TweetClips/bin/carthage.sh bootstrap --platform iOS --cache-builds --project-directory TweetClips

このコマンドをBitrise上で再現する場合にはCarthageステップを使わずにScriptステップを使います。Bitrise上でのステップは以下のように書きました。

workflows:
  primary:
    steps:
    {{ 〜〜〜中略〜〜〜 }}
    - cocoapods-install@1.11.0: {}
    - script@1:
        title: install carthage
        inputs:
        - content: |-
            #!/usr/bin/env bash
            chmod +x TweetClips/bin/carthage.sh
            #export GITHUB_ACCESS_TOKEN="$GITHUB_ACCESS_TOKEN"
            TweetClips/bin/carthage.sh bootstrap --platform iOS --cache-builds --project-directory TweetClips

BitriseでCarthageを使っている方はご存知かと思いますが、Cartfileがルートディレクトリに存在しない場合エラーを吐くので、--project-directoryオプションでCartfileを置いている場所を指定しています。詳しくは「Bitriseでトラブル発生!Cartfile.resolved がルートディレクトリにないリポジトリのビルドが通らない - 酢ろぐ!」をご覧ください。

export GITHUB_ACCESS_TOKEN〜の部分はあってもなくても良いですが、CIサービス上でのビルド時間を短縮することができるので調べてみてください。具体的には下記のエラーを防ぐことができます。

API rate limit exceeded for xxx.xxx.xxx.xxx. (But here’s the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

トラブル:Carthageディレクトリがキャッシュされない

Carthageステップを利用しているとBitrise側で自動的にキャッシュをよしなにしてくれます。

今回はScriptステップでcarthage.shを実行しているため、自動的にはキャッシュをプッシュしてもらえません。悲しい。cache-pushステップでキャッシュするディレクトリを手動で追加をする必要があります。

    - cache-push@2:
        inputs:
        - cache_paths: |-
            $BITRISE_CACHE_DIR
            TweetClips/Carthage -> TweetClips/Cartfile.resolved

GUI側で設定するのであればこの部分を編集してください。

f:id:ch3cooh393:20201016132613p:plain

トラブルシューティング:Command PhaseScriptExecution failedエラーが発生する

bin/carthage.sh update --platform ios --cache-builds 実行時、ある日何もしていないのに下記のエラーが発生する。

The file couldn’t be saved.
Command PhaseScriptExecution failed with a nonzero exit code

macOSの再起動で発生しなくなります。

または、carthage copy-frameworks produces "The file couldn’t be saved." error · Issue #3056 · Carthage/Carthage · GitHubによれば、macOSのシステム設定でXcodeにフルディスクアクセス権限を付与した状態で、Run Scriptを以下のように書き換えることで発生しなくなります。

rm -rf ${TMPDIR}/TemporaryItems/*carthage*  
/usr/local/bin/carthage copy-frameworks

Xcodeにフルディスクアクセス権限を付与してもエラーが消えないようでしたら、ターミナルで以下のコマンドを実行して、直接手動でtempファイルを削除する方法もアリかと思います。

open $TMPDIR/TemporaryItems

トラブルシューティング:10/23のNYTPhotoViewerアップデートでCarthageビルドに失敗するようになった

Carthageでビルドせずに CocoaPodsでビルドするようにしました。CocoaPodsはCocoaPodsで最新版のv1.10でビルドするとエラーが発生するかもしれないのでこちらのエントリをご覧ください。

まとめ

以上でXcode12+CarthageでiOSアプリをビルドできるようになりました。

f:id:ch3cooh393:20201016121138p:plain

そもそもとしてcocoapods-binaryを使ってキャッシュを利用するようにしているので、Carthageを使うようにしてもCI上でのビルド時間自体はそんなに変わりませんが、ローカルPCでのデバッグ実行時のビルドが軽くなった印象はあります。

なお、FirebaseをCarthage経由でインストールする場合にはいくつか注意する点があるのであわせて関連記事もお読みください。

ちなみに新規でBitriseを使ってみようとお考えの方はこちらのリンクからアカウントを作成していただけると、通常10分のビルド時間が増えるのでよければこちらからどうぞ!

app.bitrise.io

Xcode12でCocoaPods以外の方法でFirebaseをインストールするとAppStoreへのアップロード時に失敗する

Firebase for iOS SDKの正式な導入方法としては、CocoaPods経由でインストールすることになっています。

しかし、CarthageまたはSwiftPMでの導入方法はまだベータ版扱いですが導入手段が提供されています。Xcode 12 betaあたりまでは正常に動いていたようなのですが、Xcode 12の正式版が出た段階で CocoaPods以外の方法でFirebaseをインストールするとAppStoreへのアップロードに失敗してしまうようになりました。

エラー内容は下記の通りで、まったく情報がありません。

Found an unexpected Mach-O header code: 0x72613c21

今週あたま、GitHubに書き込まれたコメントを参考にすることで、問題なくAppStoreにバイナリをアップロードすることができました。

実行環境

  • macOS 10.15.7 (19H2)
  • Xcode 12.0.1
  • Carthage v0.36.0

古いバージョンのCarthageを使っている場合には、Mac HomebrewでCarthageをアップデートしておくと良いかもしれません。

brew upgrade Carthage

Carthageは頻繁にアップデートがおこなわれないのでみんな最新のものを使っているかと思います。

Cartfile の中身

サンプルとして弄ったプロジェクトでは、Carthage経由で「AdMob」「Firebase Analytics」「Firebase Crashlytics」を導入しています。

github "realm/realm-cocoa"
github "SDWebImage/SDWebImageSwiftUI"
github "yhirano/LicensePlistViewController"
github "takecian/SwiftRater"
github "NYTimes/NYTPhotoViewer"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAdMobBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseCrashlyticsBinary.json"

*.framework をリンクする作業等は、通常通りしてください。Buld Phasesで/usr/local/bin/carthage copy-frameworksするのも忘れないで。

対応策

アプリターゲットの「Build Phases」を開いて、Run Scriptを追加します。スクリプトは一番最後に移動させてください。

f:id:ch3cooh393:20201016172244p:plain

このタイミングでFirebase関係の.frameworkを削除します。具体的には app/Frameworks/HOGEHOGE.framework を削除します。

f:id:ch3cooh393:20201016172259p:plain

画像だと見にくいと思いますので書き出しました。

# Type a script or drag a script file from your workspace to insert its path.
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/Firebase.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseCore.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseCoreDiagnostics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseCrashlytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseInstallations.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleDataTransport.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleMobileAds.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleUtilities.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/nanopb.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/PromisesObjC.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/UserMessagingPlatform.framework"

これでCarthage経由でFirebase for iOS SDKをインストールしたアプリでもApp Storeへのアップロード時にエラーが発生することがなくなります。