You can get the crash data from the local device, if you have access to it, or Apple's developer site, but neither is ideal in many cases.ĬrashKiOS (Crash reporting for Kotlin iOS) is a simple library that let's you send symbolicated crash reports to crash reporting systems like Crashlytics and Bugsnag. Kotlin 1.3.60 introduces crash data being written to the iOS internal crash log and better symbolication support. You can add the stack trace in the crash report log as a string, but you may lose detail, and in any case, the errors won't be grouped by the stack trace. For crash reporting, that isn't super useful. They all end with konan::abort(), which internally force-kills the app. Because of how iOS crashes work, that looks like this: At the border between Swift/Objc and Kotlin, uncaught exceptions will trigger a crash. To stay consistent with Kotlin on the JVM, exceptions propagate in the same way on iOS. The crash reporting tool will capture the state of the threads at that moment.įor Kotlin, this introduces a problem. On iOS, without exception propagation, the system simply "crashes".
If it makes its way to the default exception handler, the app generally "crashes", with maybe a report to a crash reporting library.
When a crash happens on Android in the JVM, an exception will bubble up until something catches it. The JVM and Kotlin rely on exceptions, while iOS really does not. Kotlin code running on iOS has an issue specific to the design differences between the JVM and iOS. Knowing when things fail, and how, is information you need to make sure things are running smoothly. Crash reporting tools are critical to the success of any mobile product.
0 kommentar(er)
