Android is the world's most widespread mobile operating system, but writing an app and shipping a scalable, secure, maintainable Android product are not the same thing. Native development with Kotlin and Java, device diversity, offline field scenarios and Google Play processes are at the centre of this work.
An Android app is a whole made up of screens, business logic, local data, a network layer and store processes. An Android software expert owns both the technical architecture of this whole and its behaviour on the device.
If we are starting a new Android project today, the answer is almost always Kotlin. Shorter code, null safety, asynchronous work with coroutines and Google's official recommendation all support this.
Java is still real in projects with an ageing codebase. Here the decision is not "rewrite everything"; it is writing new modules in Kotlin while gradually migrating the old code. Moving forward without breaking the app overnight is the most critical part of this transition.
Not every project has to be native. If the goal is a single codebase, Flutter is usually more efficient. The situations where native Android stands out are these:
The decision between native and cross-platform is not a matter of religion; it is an engineering decision made according to hardware needs, team structure and the product's lifetime. I compared the two approaches in detail in the article Flutter or native.
An Android app can look like it "works" while causing problems in the field. That is why I track the following from the very start of a project:
One of the areas where Android is strongest is enterprise field operations: team management, form collection, orders, audits and stock counting. In these scenarios the app is often used on a weak network, with gloves on, under the sun and across long shifts.
I developed survey and location-based reporting apps for Açık Deniz Bilgi's FMCG field team; running on native Android, iOS and Swift, these apps were used in the field with ERP integration and the ability to keep working offline. On DoktorAsistan's mobile side, user flows, notifications and secure session management came to the fore.
I explained how the stages work in the article why work should be done in stages; I covered the cost side in the article mobile app prices.
For new projects Kotlin is recommended: it offers shorter code, null safety and modern asynchronous structures. Java can be preserved in projects with an existing codebase through gradual migration.
If deep hardware access, high performance or platform-specific behaviour is required, choose native; if shipping to two platforms at once and there is no special hardware need, Flutter is usually more efficient.
Once technical preparation is complete, store review usually takes a few days. For a first release, account verification, the data safety form and permission justifications can add extra time.
Yes. First the existing codebase and architecture are reviewed; risky areas are identified and the new feature is added without breaking the existing structure.
It is possible. It requires a layer that handles a local database, a work queue and synchronisation conflicts. This is an architectural decision that must be planned from the start.
Store rule changes, new Android versions and security patches require regular attention. The maintenance plan covers a release calendar, crash tracking and critical updates.
