Android app development is no longer just a matter of building screens and uploading a package. A durable app has to work across phones, tablets, foldables, ChromeOS, cars, Wear OS, and changing platform requirements. Google Play target API rules, Android 16 behavior changes, and 16 KB page-size compatibility can all create late rework if they are treated as release-week tasks.
This article organizes the practical checks that should be addressed when starting a new Android app or modernizing an existing one. The key question is not only whether to use Kotlin or Jetpack Compose, but whether quality, accessibility, store readiness, and maintenance are part of the same development plan.
Key Takeaways
- Kotlin and Jetpack Compose are strong defaults for modern Android development, but architecture, state ownership, reviews, and tests still decide quality.
- Android 16 readiness should include behavior-change review, SDK setup, and testing on real devices or emulators.
- Google Play publishing requires planning for target API level, permissions, privacy declarations, store presentation, and staged rollout.
- Apps that include native code or SDKs should check 16 KB page-size compatibility early.
- Maintenance for OS updates, SDK changes, crash fixes, and support should be part of the project scope, not an afterthought.
Start With Quality, Not Only Features
Android projects rarely fail because of one framework choice alone. They fail when the team does not define who uses the app, on which devices, in which context, and what outcome must happen reliably. Apps that involve booking, payment, notifications, login, location, camera access, external APIs, or personal data need more than convenient screens. They need failure handling, retry behavior, permission explanations, and support paths.
Android Developers presents Android work across UI, architecture, quality, security, tools, device categories, and Google Play. That is a useful operating model for real projects. Screen production, API integration, store submission, and monitoring should share one quality standard. When they are treated as separate workstreams, issues tend to appear late in review or after release.
Kotlin and Compose Are a Start, Not a Substitute for Design
Google’s official documentation describes Kotlin as fully supported for Android development and notes first-class Kotlin support in Android Studio. The Android SDK also includes nullability annotations from Android 9 onward to help reduce NullPointerException risk. For many new apps, Kotlin is a practical default; for existing Java codebases, migration can be staged around clear boundaries.
Jetpack Compose is positioned as Android’s modern toolkit for native UI. It lets teams describe UI with Kotlin APIs and often reduces boilerplate, but it does not remove the need for architecture. If state ownership is unclear, problems surface in recomposition, navigation, input preservation, and error display. For each screen, separate displayed state, user actions, data updates, and failure behavior. ViewModels or other state holders should own the data that must survive configuration changes and navigation.
Android 16 Readiness Should Not Wait Until Release Week
The Android 16 overview directs developers to set up a runtime environment, configure the Android 16 SDK and tools, review behavior changes for all apps, review changes for apps targeting Android 16, and test user flows. This makes platform readiness more than a build-setting change. Notifications, background work, media access, permissions, screen sizes, and third-party SDKs may all need review depending on the app.
In practice, major OS readiness belongs in the sprint and maintenance plan. Regular checks of dependencies, Android Gradle Plugin, NDK usage, test devices, crash logs, and Play review feedback make target API updates easier to estimate and less likely to interrupt product work.
Google Play Requirements Belong in Product Planning
Google Play’s target API level guidance says that starting August 31, 2025, new apps and app updates must target Android 15, API level 35, or higher. Existing app availability also has requirements, and teams should check the latest official guidance for exceptions and extension rules before each release.
Raising the target API level is not just a one-line build change. It can affect permissions, notifications, background execution, storage, media access, SDK compatibility, privacy declarations, store listings, and review-sensitive wording. For commissioned development, the contract should specify who handles future API requirement changes, support windows, and post-release maintenance.
16 KB Page Size Support Starts With Native Dependencies
Android Developers explains that starting November 1, 2025, new apps and updates submitted to Google Play and targeting Android 15 or later devices must support 16 KB page sizes on 64-bit devices. Apps written only in Kotlin or Java generally already support 16 KB devices, but apps using NDK libraries directly or through SDKs need verification.
Maps, payments, ads, analytics, image processing, games, audio, encryption, and proprietary SDKs may include native libraries. Use APK Analyzer to check for .so files, then test with a 16 KB environment through an emulator or supported device. If older NDK versions or prebuilt shared libraries are involved, check the provider’s support status and plan rebuilds or replacements early.
Do Not Delay Adaptive UI and Accessibility
Android devices vary widely in size and posture. A phone-only portrait design can leave tablet and foldable experiences stretched, sparse, or hard to operate. Plan compact, medium, and expanded layouts from the beginning. Decide how navigation, list-detail screens, forms, images, dialogs, and input behavior change as the available width changes.
Accessibility should be handled with the same discipline. Text scaling, contrast, screen reader labels, focus order, touch targets, and error copy are far cheaper to solve in the component system than at the end. Compose provides semantics and testing APIs that help structure UI meaning for assistive technologies and automated tests. This is a quality and maintainability issue, not only a courtesy.
Practical Checklist
| Area | What to Check | Evidence to Keep |
|---|---|---|
| Planning | Users, use cases, device scope, distribution path | User stories, success metrics, constraints |
| Design | Navigation, permissions, offline behavior, data ownership, failure recovery | Screen flows, API design, state transitions, error policy |
| Implementation | Kotlin, Compose, architecture, SDK dependencies, testing approach | Code, review records, unit tests, UI tests |
| Compatibility | Android 16, target API, 16 KB page size, screen sizes | Device matrix, compatibility notes, crash logs |
| Release | Google Play requirements, store listing, privacy, staged rollout | Release checklist, release notes, monitoring plan |
| Operations | OS updates, SDK updates, support, incidents, maintenance scope | Runbook, responsibility boundaries, update plan |
FAQ
Should a new Android app use Kotlin and Compose?
For many new projects, yes. Kotlin is well supported in Android Studio, and Compose fits modern UI and adaptive layouts. Existing assets, team experience, required SDKs, and deadlines may still justify keeping some view-based screens while introducing Compose gradually.
What should be checked first for Android 16 readiness?
Review the official behavior changes, target SDK impact, key user flows on real devices or emulators, and third-party SDK support. Notifications, permissions, background work, media access, and screen sizes can vary by app.
Does every app need 16 KB page-size work?
Apps that fall under the Google Play requirement should verify compatibility. Kotlin-only or Java-only apps generally already support 16 KB devices, but apps that include native code or SDKs with native libraries need build and testing checks.
What is often missed in commissioned Android development?
Post-release responsibility. OS updates, target API requirements, SDK updates, store review issues, crash fixes, and support should have clear owners and scope before launch.
References
- Android Developers: Develop for Android
- Android Developers: Kotlin and Android
- Android Developers: Jetpack Compose
- Android Developers: Android 16
- Android Developers: Google Play target API level requirement
- Android Developers: Support 16 KB page sizes
- Android Developers: Android Studio and app tools