MyApp crashed: solving "Unfortunately stopped" in 2025 on Kotlin

Introduction: "Unfortunately MyApp has stopped" — every developer's curse

Have you ever seen this gray dialog box that crosses out hours of your work? "Unfortunately MyApp has stopped" — a phrase that makes Android developers twitch. This bug is a real "monster under the bed" for beginners and even experienced programmers. In 2025, when Kotlin has become the main language for Android, we can finally not just guess why the app crashed, but know exactly what went wrong. In this article, we'll break down how to fix this error on Kotlin and show best practices so your app never shows this message. Let's go!

What is "Unfortunately MyApp has stopped" and why does it happen?

This error is Android's standard message when an app terminates unexpectedly (crash). It appears when an unhandled exception or fatal error occurs that the system cannot ignore. In Kotlin, this can be anything from NullPointerException to OutOfMemoryError. The main problem is that the message gives no information about the cause. You just see that the app "died," but you don't know how to "revive" it.

In 2025, with the development of debugging tools, we can turn this error from a black box into a transparent process. Let's figure out how to do this in Kotlin.

Main causes of crashes in Android apps

\n
• NullPointerException (NPE) — a classic that Kotlin saves from, but not completely.
\n
• ResourceNotFoundException — when you try to load a resource that doesn't exist.
\n
• OutOfMemoryError — the app tries to load too much data.
\n
• NetworkOnMainThreadException — a network request is executed on the UI thread.
\n
• IllegalStateException — incorrect state of an Activity or Fragment.
\n

Most of these errors can be prevented by using proper practices. But first — how to find them.

How to find the cause of a crash: tools of 2025

Instead of guessing, use modern tools. Here's what should be in every Kotlin developer's arsenal:

\n
• Android Studio Logcat — your best friend. Look for lines with the tag AndroidRuntime and the keyword FATAL EXCEPTION.
\n
• Crashlytics (Firebase) — automatically collects stack traces from real devices.
\n
• Bugsnag or Sentry — alternatives for detailed monitoring.
\n
• StrictMode — a built-in tool for detecting issues during development.
\n

Example: if you see a line in Logcat like java.lang.NullPointerException: Attempt to invoke virtual method on a null object reference, it means you are trying to call a method on a null object. Let's fix this in Kotlin.

Best practices for preventing crashes in Kotlin

Kotlin already solves many problems, but only if you use its features correctly. Here's how to protect your app from "Unfortunately MyApp has stopped."

1. Use nullable types and safe calls

Kotlin introduces nullable types, but many developers still get NPEs due to Java code or incorrect initialization. Use ?.let and ?: for safe handling:

// Bad\nval name = user.name\nprintln(name.length) // May crash if name == null\n\n// Good\nval nameLength = user.name?.length ?: 0\nprintln(nameLength)\n

If you work with Java libraries, wrap calls in try-catch or use @Nullable annotations.

2. Use ViewBinding instead of findViewById

One common cause of NPE is incorrect view lo