クラッシュレポートとストアリリース

Even great apps crash on real devices. A crash reporter tells you what broke and where, instead of leaving you guessing from reviews.

Tools like Crashlytics or Sentry have Android and iOS SDKs, so you can monitor both apps from one familiar dashboard.

The reporter lives in native code. Initialize it in the Android app and the iOS app, not inside your shared commonMain module.

Expose a tiny expect/actual logger so shared code can record handled errors that each platform forwards to its native reporter.

Kotlin/Native crashes appear with native frames. Uploading dSYM files lets the reporter symbolicate them into readable function names.

A bare stack trace lacks context. Logging breadcrumbs of recent actions helps you reproduce the exact path into a crash.

Before release, raise the version and build number. Stores reject duplicates, and crash reports group cleanly by version.

Upload the signed app bundle to the Play Console, roll out to a test track first, then promote to production once it looks healthy.

Archive in Xcode, upload to App Store Connect, test through TestFlight, then submit that same build for App Store review.

Right after launch, watch your crash-free rate. A sudden dip means roll back or ship a fast fix before more users are hit.

Treat crash data as a backlog: triage top issues, fix them in shared or native code, and confirm the rate climbs in the next release.

Recall what makes iOS crash traces readable.

You wired a cross-platform crash reporter, bridged logging from shared code, uploaded dSYMs, released to both stores, and watched the crash-free rate. 🚀