iOS SDK のトラブルシューティング

セットアップ中の問題

1. コンソールで、"App Center SDK が正常に構成されました" というメッセージが表示された Assert ログを探します。 このメッセージは、SDK が正常に構成されたことを意味します。
2. Cocoapods を使用して iOS アプリに App Center を統合し、 というメッセージでエラーが発生した場合はCocoaPods - Unable to find a specification for AppCenter、 を実行pod repo updateしてローカル Cocoapods リポジトリを更新し、もう一度実行pod installします。
3. CocoaPods を使用して iOS アプリに App Center を統合していて、プロジェクトのコンパイル中にメッセージでエラーが発生する場合はframework not found AppCenter.xcframework、 を実行[sudo] gem install cocoapodsして Cocoapods を遅延バージョンに更新 (再インストール) する必要があります。
4. SDK バイナリを手動で統合する場合は、プロジェクトに対してモジュールが有効になっていることを確認します。

分析データがポータルに表示されない

1. SDK モジュールが正しく統合されていることを確認します。

2. メソッド呼び出しと共に正しいアプリ シークレットが含まれていることを start:withServices: 確認します。 正確なstart:withServices:コードをコピーするには、ポータルでアプリを開き、はじめに ページに移動します。

3. バックエンドに送信されたログを表示する場合は、アプリケーションでログ レベルを Verbose に変更します。 その後、SDK によってコンソールにログが出力 されます。 SDK の開始前に次の呼び出しを挿入します。

   [MSACAppCenter setLogLevel:MSACLogLevelVerbose]
   

   AppCenter.logLevel = .verbose
   

   ログに [App Center SDK が正常に構成されました] が (INFO ログ レベルで) 表示されていることを確認し、HTTPS 要求ログが表示された場合はチェックします。

4. デバイスがオンラインであることを確認します。

5. ログがポータルに表示されるまでに数分かかる場合があります。 その場合はしばらく待ちます。

6. App Center バックエンドがデータを受信したかどうかをチェックするには、Analytics サービスの [ログ フロー] セクションに移動します。 送信されると、イベントが表示されます。

クラッシュがポータルに表示されない

1. SDK モジュールが正しく統合されていることを確認します。

2. メソッド呼び出しと共に正しいアプリ シークレットが含まれていることを start:withServices: 確認します。 正確なstart:withServices:コードをコピーするには、ポータルでアプリを開き、はじめに ページに移動します。

3. App Center のクラッシュ は、アプリの再起動後にのみクラッシュ ログを転送します。 また、デバッガーにアタッチされている場合、SDK はクラッシュ ログを転送しません。 アプリをクラッシュさせたときにデバッガーがアタッチされていないことを確認します。

4. バックエンドに送信されたログを表示する場合は、アプリケーションでログ レベルを Verbose に変更します。 その後、SDK によってコンソールにログが出力 されます。 SDK の開始前に次の呼び出しを挿入します。

   [MSACAppCenter setLogLevel:MSACLogLevelVerbose]
   

   AppCenter.logLevel = .verbose
   

   ログに [App Center SDK が正常に構成されました] が (INFO ログ レベルで) 表示されていることを確認し、HTTPS 要求ログが表示された場合はチェックします。

5. クラッシュ レポート機能を提供する他のライブラリは使用しないでください。 アプリに統合できるクラッシュ レポート SDK は 1 つだけです。

6. デバイスがオンラインであることを確認します。

7. 場合によっては、ログがポータルに表示されるまで数分かかる場合があります。 その場合はしばらく待ちます。

8. SDK が次のアプリの起動時にクラッシュを検出したかどうかを確認します。 API を呼び出して、前回のセッションでアプリがクラッシュしたかどうかをチェックし、アラートを表示できます。 または、クラッシュ didSucceedSendingErrorReport コールバックを拡張して、サーバーに正常に送信されたかどうかを確認することもできます。

9. App Center バックエンドがクラッシュを受け取ったかどうかをチェックするには、Analytics サービスの [ログ フロー] セクションに移動します。 送信されると、クラッシュが表示されます。

ユーザーに更新を求めるアラートには文字列は含まれませんが、それらのキーだけが含まれます

これは、 がプロジェクトに追加されなかったことを AppCenterDistributeResources.bundle 意味します。 Xcode プロジェクトにファイルがドロップされ、アプリ ターゲットの Copy Bundle Resources ビルド フェーズに表示されていることを確認します。 ドラッグ アンド ドロップでファイルを追加すると、そこに表示されます。Xcode によって自動的に行われます。 ビルド フェーズにファイルがない場合は、アプリのバンドルにコンパイルされるようにファイルを追加します。

Cocoapods を使用している場合は、リソースが自動的に処理されます。 ポッドを再インストールしてみてください。

コンソールに、データベースを開けなかったことを示すメッセージが表示される

iOS SDK のバージョン 0.11.0 以降、App Center は SQLite を使用してログを保持してからバックエンドに送信します。 OS によって提供されるライブラリを使用する代わりに、独自の SQLite ライブラリを使用してアプリケーションをバンドルしている場合は、コンソール [AppCenter] ERROR: -[MSACDBStorage executeSelectionQuery:]/147 Failed to open database にこのようなエラーが表示され、バックエンドに分析情報やクラッシュ情報が表示されない可能性があります。 SDK をバージョン 0.13.0 以降に更新します。

配布とアプリ内の更新によって自動化された UI テストがブロックされている

アプリ内更新プログラムが有効になっている場合は、自動化された UI テストがブロックされます。 更新プロセスでは、App Center バックエンドに対する認証が試行されます。 UI テスト ターゲットに対して App Center Distribute を有効にしないことをお勧めします。

SDK が "静的ライブラリ" として配布される理由

App Center SDK の主な設計目標は、App Center を使用してアプリに与える影響を最小限に抑え、モジュール式 SDK を用意することです。 これにより、SDK が複数の動的なリンクされた共有ライブラリとして配布されます。

これまで、iOS は動的なリンクされた共有ライブラリをサポートしていませんでしたが、 Landon Fuller のこのブログ投稿で説明されているように、iOS 8 で追加されました。

ただし、App Center は、"脂肪" の偽のフレームワークにラップされた静的にリンクされた共有ライブラリとして配布されます。 つまり、SDK は コンパイル時 にリンクされ、パフォーマンスを向上させるために起動時にはリンクされません。 複数の動的なリンクされた共有ライブラリの読み込みには時間がかかります。

Apple では、 WWDC セッションで 400 ミリ秒以下にするようにアプリの起動を最適化することをお勧めします。 この目標を達成するために、動的共有ライブラリよりも静的共有ライブラリを特に推奨しています。 静的にリンクされた共有ライブラリとして App Center SDK for iOS を配布することは、Sdk を含むアプリに最適なパフォーマンスと最小限の影響を提供するために、Apple の推奨事項に従います。

静的にリンクされた共有ライブラリと動的なリンクされた共有ライブラリの詳細については、このトピックに関する Apple の 一般的なドキュメントをお勧めします。

SDK バイナリが非常に大きいのはなぜですか? アプリのサイズが気になる

AppCenter バイナリは、すべての iPhone アーキテクチャと iPhone シミュレーターのスライスを含む "fat" フレームワークとして配布されます。 このため、たとえば AppCenter.framework は 10.5 MB でダウンロードできます。

SDK バイナリのコンパイル済みサイズは、Xcode でアプリに追加する サイズよりもはるかに .framework 小さくなります。 また、リリース ビルドはデバッグ ビルドよりも小さくなります。

これを説明するために、Xcode 9.2 で空の Objective-C アプリケーションを作成し、App Center バイナリをアプリに追加し、iOS 11.3 を実行している iPhone 7 に分散リリース ビルドを追加しました。

Bitcode を有効 にせずに テストを実行し、 アプリ間引きを使用しませんでした。 これらの手法を使用して、アプリのバイナリ サイズをさらに縮小できます。

以下の数値はビルド設定によって異なる可能性があるため、大まかなガイドと考えてください。 とはいえ、App Center SDK をアプリに追加すると、アプリケーション バイナリのサイズへの影響は最小限に抑えられます。

App Center シークレット値を保護する

app_secretはアプリの識別子であり、トラフィックがどのアプリに適用されるかを知る必要があり、既存のデータを取得または編集するために使用することはできません。 app_secretが公開されている場合、最も大きなリスクは不適切なデータをアプリに送信することですが、データのセキュリティには影響しません。

機密データを取得するには、クライアント側で生成されるアプリ/ユーザー トークンを指定する必要があります。 クライアント側のデータを完全にセキュリティで保護する方法はありません。

環境変数を使用してアプリ シークレットをコードに挿入することで、アプリのセキュリティを向上させることができます。 そうすることで、シークレットはコードに表示されません。