Mobile Development Guide: Frameworks, Kotlin and an Android Release

Framework comparison tables rarely settle anything, because Flutter, React Native and Kotlin all look convincing on paper. A more honest method is to build the same tiny app three times: one screen with a text field, an Add button and a list that grows each time the button is tapped. A project that size is enough to feel the language, the tooling and the way each framework lays out a screen. Roughly 6 to 10 hours per path, spread over 1 to 2 weeks, is usually plenty to reach a decision.

In Flutter, learners write Dart, assemble widgets such as Column, TextField and ListView, and get to feel hot reload refreshing the screen within seconds. In React Native, anyone who already writes JavaScript will recognise the component and state patterns from web work, and Expo makes it easy to run the project on a phone with a light setup. In Kotlin with Jetpack Compose, learners work inside Android Studio, write composable functions and try the result on an emulator.

After each attempt, write down three things: where you were stuck the longest, how readable the error messages felt, and whether you actually want to keep going with that project tomorrow. The answer to that last question often matters more than any benchmark. Once a path is chosen, park the other two until one app is genuinely finished, because switching frameworks halfway through tends to eat months and leave nothing to show.

A first Android project in Android Studio nearly always opens with a wait for Gradle sync, the step that downloads libraries and prepares the build configuration. On a slow connection it can drag on, and it is where the first errors tend to appear: a mismatched plugin version, a library that failed to download, or a missing SDK. Two files deserve early attention, the project-level and app-module build.gradle.kts, where SDK versions and dependencies are declared.

When an app launches and then crashes, the answer lives in Logcat. Learners need to get used to filtering Logcat by their own package name and by the Error level, since the unfiltered view drowns in system messages. Read a stack trace from the top: the first line names the exception, then look for the first line that points at a file you wrote, such as MainActivity.kt line 42. If there is a section labelled Caused by, the root cause is usually spelled out there.

A useful drill is to break the Hello World app on purpose in three ways: call !! on a null value, read a list index that is out of bounds, and open a second Activity that was never declared in AndroidManifest. For each break, find the responsible line through Logcat before rereading the code. Once you can point to the culprit line within a minute or two, you are ready to move on to building screens with a calm head.

Jetpack Compose builds screens from composable functions, and the screen updates through recomposition: whenever state that a composable reads changes, that function runs again and the affected part of the screen is redrawn. This idea trips up most learners who are used to changing the interface directly, for example by setting the text of a label with a single command.

The two core tools are remember and mutableStateOf. A plain variable inside a composable resets to its initial value on every recomposition, so a counter written without remember appears frozen at zero no matter how often the button is tapped. remember keeps a value for as long as the composable stays on screen, while rememberSaveable also keeps it through a rotation. The frozen counter is extremely common and makes an excellent diagnostic exercise for understanding how Compose thinks.

The next step is state hoisting. State moves up into a parent composable, and the child receives the value plus a callback as parameters, like the value and onValueChange pair on a TextField. This pattern keeps small composables reusable and easy to inspect in @Preview without running the whole app. The drill: build a to-do screen with a TextField, an Add button and a LazyColumn, then split it into three composables whose state is held by one parent.

Every bit of screen drawing on Android happens on the main thread. When that thread is busy reading a database or waiting for a server, the screen freezes, and if the freeze lasts around five seconds the system shows the App Not Responding dialog, known as an ANR. Android even rejects network calls on the main thread with NetworkOnMainThreadException, so every learner runs into this boundary as soon as their app starts fetching data.

Kotlin coroutines are a compact way to move heavy work elsewhere. A function marked suspend can pause without blocking a thread. viewModelScope.launch starts work that is cancelled automatically when the ViewModel is cleared, and withContext(Dispatchers.IO) shifts file or network access to a background thread. Room and Retrofit both support suspend functions, so learner code only needs to call them from inside a coroutine.

The idea feels abstract, so practise it with an experiment you can see. Make a button that runs Thread.sleep(6000) on the main thread and feel the screen lock up, then swap it for delay(6000) inside a coroutine and watch an animation keep moving. Add a loading indicator that appears while you wait. Get one concept fully settled, such as suspend and scopes, before stacking Flow and its operators on top, and this stage stays manageable.

Any app uploaded to Google Play has to be signed. Through Build and then Generate Signed Bundle/APK, Android Studio creates a keystore file (.jks) holding the upload key along with its alias and passwords. Keep that file outside the repository, back it up somewhere safe and keep it away from public GitHub. With Play App Signing, Google holds the app signing key, and a lost upload key can be replaced through a reset request, although the process takes time.

Since August 2021, new apps on Google Play have been uploaded as Android App Bundles (.aab), from which Play generates APKs tailored to each user's device. Every upload must carry a versionCode higher than the previous one, while versionName is the label users see, such as 1.0.2. Forgetting to bump versionCode makes Play Console reject that upload.

Before a public release, the internal testing track in Play Console lets a small group of testers install the app through a link. New personal developer accounts are also asked to run a closed test with a number of testers before production access, and the current requirements are best read directly in Play Console. The store listing needs an icon, screenshots, a description, a privacy policy, which is required even when the app collects no personal data, and the data safety form. For anyone not ready to release yet, a GitHub repository with a clear README already makes a portfolio worth showing.