TestFlightを使用して、アプリのパイロットを送信しています。
アプリの一部がクラッシュしていて、クラッシュを再現するのに多くの問題がありました。彼らのコードはかなり単純です。
TestFlightを介してアプリを入手したユーザーはクラッシュしますが、アプリをビルドしてIDEを使用してインストールすると、クラッシュしません。
誰もがこれを引き起こしている可能性があるものについての考えを持っていますか?
回避策のアイデアはありますか?TestFlightの使用をやめたくありません。
TestFlightを使用して、アプリのパイロットを送信しています。
アプリの一部がクラッシュしていて、クラッシュを再現するのに多くの問題がありました。彼らのコードはかなり単純です。
TestFlightを介してアプリを入手したユーザーはクラッシュしますが、アプリをビルドしてIDEを使用してインストールすると、クラッシュしません。
誰もがこれを引き起こしている可能性があるものについての考えを持っていますか?
回避策のアイデアはありますか?TestFlightの使用をやめたくありません。
デバッグではなくリリースモードでアプリをビルドしてください。アプリはリリース時にのみクラッシュする可能性があります。
私が最初に試みることは、クラッシュスタックトレースをアプリケーションの関数名にマップすることです。これにより、クラッシュの性質に関する有用な洞察が得られる可能性があります。
手動シンボル化:これは、ビルドにデバッグ情報がある限り機能します。
実行可能ファイル(Payload / AppName.app / AppName)に対して次のコマンドを実行します。
otool -tv AppName.app | c ++ filt> Listing.asm
前の手順が完了するまで待ちます(しばらく時間がかかる場合があります)。生成されるlisting.asmファイルの長さは数メガバイトになります。
もちろん、象徴化できる場合は、この手順をスキップできます。
頑張ってデバッグしてください!
同様の問題がありました。私たちの問題は静的ライブラリでした。アプリを最初から作成してtestflightに移行したとき、クラッシュしていましたが、IDEからはそうではありませんでした。クラッシュは、ビルドの実行時に静的ライブラリが含まれていなかったために発生しましたが、iPadを直接接続し、XCodeを使用してインストールした場合に含まれていました。
簡単なテストでこれが証明されます:-
1.)IDEからビルドする代わりに、.appファイルを作成し、iTunes経由でロードして、クラッシュするかどうかを確認します。
これを回避するには、.iPAを手動で作成します。つまり、.appを作成してから、ペイロードフォルダーを作成し、その中に.appをinfo.plistと一緒に配置します。
その後、Testflightでも機能し始めました。