2024/7/23
laprasdrum.icon 久々の帰省楽しみ
/icons/hr.icon
独自のクラッシュレポーター作成はAppleとしては非推奨
AppleのDTS（Developer Tools & Services） Engineerによる回答。
I strongly advise against implementing your own crash reporter. It’s very easy to create a basic crash reporter that works well enough to debug simple problems. It’s impossible to implement a good crash reporter, one that’s reliable, binary compatible, and sufficient to debug complex problems. The bulk of this post is a low-level explanation of that impossibility.
Rather than attempting the impossible, I recommend that you lean in to Apple’s crash reporter. In recent years it’s acquired some really cool new features:
If you’re creating an App Store app, the Xcode organiser gives you easy, interactive access to Apple crash reports.
If you’re an enterprise developer, consider switching to Custom App Distribution. This yields all the benefits of App Store distribution without your app being generally available on the store.
iOS 14 and macOS 12 report crashes in MetricKit.
If you previously dismissed Apple crash reports as insufficient, I encourage you to reconsider that decision.
Why Is This Impossible?
Earlier I said “It’s impossible to implement a good crash reporter”, and I want to explain why I’m confident enough in my conclusions to use that specific word. There are two fundamental problems here:
On iOS (and the other iOS-based platforms, watchOS and tvOS) your crash reporter must run inside the crashed process. That means it can never be 100% reliable. If the process is crashing then, by definition, it’s in an undefined state. Attempting to do real work in that state is just asking for problems.
To get good results your crash reporter must be intimately tied to system implementation details. These can change from release to release, which invalidates the assumptions made by your crash reporter. This isn’t a problem for the Apple crash reporter because it ships with the system. However, a crash reporter that’s built in to your product is always going to be brittle.
I’m speaking from hard-won experience here. I worked for DTS during the PowerPC-to-Intel transition, and saw a lot of folks with custom crash reporters struggle through that process.
Still, this post exists because lots of folks ignore this reality, so the subsequent sections contain advice about specific technical issues.
WARNING Do not interpret any of the following as encouragement to implement your own crash reporter. I strongly advise against that. However, if you ignore my advice then you should at least try to minimise the risk, which is what the rest of this document is about.
1 On macOS it’s possible for your crash reporter to run out of process, just like the Apple crash reporter. However, possible is not the same as easy. In fact, running out of process can make things worse: It prevents you from geting critical state for the crashed process without being tightly bound to OS implementation details. It would be nice if Apple provided APIs for this sort of thing, but that’s currently not the case. 独自のクラッシュ レポーターを実装することは強くお勧めしません。 単純な問題をデバッグするのに十分な基本的なクラッシュ レポーターを作成するのは非常に簡単です。信頼性が高く、バイナリ互換性があり、複雑な問題をデバッグするのに十分な優れたクラッシュ レポーターを実装することは不可能です。この投稿の大部分は、その不可能性の低レベルの説明です。
不可能なことに挑戦するよりも、Apple のクラッシュ レポーターを利用することをお勧めします。近年、クラッシュ レポーターにはいくつかの非常に優れた新機能が追加されました。
App Store アプリを作成する場合、Xcode オーガナイザーを使用すると、Apple クラッシュレポートに簡単にインタラクティブにアクセスできます。
エンタープライズ開発者の場合は、カスタム アプリ配布への切り替えを検討してください。これにより、アプリをストアで一般公開しなくても、App Store 配布のすべてのメリットが得られます。
iOS 14 および macOS 12では MetricKit のクラッシュが報告されています。
これまで Apple のクラッシュレポートが不十分だとして無視していたのであれば、その判断を再考することをお勧めします。
なぜこれが不可能なのでしょうか?
先ほど「優れたクラッシュ レポーターを実装するのは不可能だ」と言いましたが、なぜその言葉を使うほど自分の結論に自信があるのかを説明したいと思います。ここには 2 つの根本的な問題があります。
iOS（および他のiOSベースのプラットフォーム、watchOS、tvOS）では、クラッシュレポーターはクラッシュしたプロセス内で実行する必要があります。つまり、100％信頼できるということはありません。プロセスがクラッシュしている場合、定義上、そのプロセスは未定義の状態にあります。その状態で実際の作業を行おうとすると、問題が発生するだけです1。 良い結果を得るには、クラッシュ レポーターがシステム実装の詳細と密接に結び付いている必要があります。これらはリリースごとに変わる可能性があり、クラッシュ レポーターが行った想定は無効になります。Apple のクラッシュ レポーターはシステムに同梱されているため、これは問題になりません。ただし、製品に組み込まれたクラッシュ レポーターは、常に脆弱です。
ここでは苦労して得た経験から話しています。私は PowerPC から Intel への移行中に DTS で働いており、カスタム クラッシュ レポーターを持つ多くの人々がそのプロセスで苦労しているのを見てきました。
それでも、多くの人がこの現実を無視しているため、この投稿が存在するので、後続のセクションには特定の技術的な問題に関するアドバイスが含まれています。
警告以下のいずれも、独自のクラッシュ レポーターを実装することを推奨するものではありません。私は、そうしないことを強く勧めます。ただし、私のアドバイスを無視する場合でも、少なくともリスクを最小限に抑えるようにしてください。これが、このドキュメントの残りの部分で説明する内容です。
1 macOSでは、Appleのクラッシュレポーターと同様に、クラッシュレポーターがプロセス外で実行される可能性があります。しかし、可能であることと簡単であることは同じではありません。実際、プロセス外で実行されると状況が悪化する可能性があります。OSの実装の詳細に厳密に縛られずに、クラッシュしたプロセスの重要な状態を取得できなくなります。Appleがこの種のAPIを提供していれば良いのですが、現時点ではそうではありません。 去年の今頃
焼き鳥を食べてた。
https://scrapbox.io/files/669f07aca9b1ba001df6457d.jpeg
やらなきゃいけないことが見通せないからテストを書く
たまに「和田さんは、コードを書く前から機能の完成形をちゃんと見通せているから、先にテストを書けるんですよね」と言われることがあるんですが、そうじゃないです。むしろその逆で、先々が見通せていないからこそテストを書くんです。
TDDを実践しながらコードを書く感覚をたとえるなら、不確実性にまみれたソフトウェア開発に少しずつ確実性を持たせていく、一種の陣取り合戦みたいなものです。
テストを書きながら開発を進めることは、こうして「よくわからない領域」を少しずつ切り崩し、「分かった領域」を組み合わせながらシステムをつくっていく感覚なのです。