Custom Android app development
Appfront develops custom Android applications, natively in Kotlin with Jetpack Compose, or cross-platform via Flutter and React Native. From the first conversation through to publication on the Google Play Store.
Kotlin and Jetpack Compose: the gold standard for native Android
When you commission an Android app, choosing the right language and UI toolkit determines the lifespan and quality of your product. Appfront works with Kotlin and Jetpack Compose as standard, the combination Google itself recommends for modern Android development.
Kotlin has replaced Java as the primary language for Android apps. The language is expressive, safe and concise: null pointer errors are caught at compile time rather than by the end user. Coroutines make writing asynchronous code, such as API calls or database operations, intuitive and readable. The result is code that is easier to maintain and carries a lower risk of regressions during updates.
Jetpack Compose is Google's declarative UI framework. Rather than defining XML layouts and manipulating them through imperative code, you describe how the interface should look based on the app's current state. Compose makes it considerably faster to build animations, custom components and responsive layouts. It also fits seamlessly with modern Android architecture: ViewModel, StateFlow and the Navigation component work together naturally.
Compose is more than just a UI layer: it enforces a clear separation between presentation and business logic. That makes your app easier to test, including at the level of individual UI components (composable previews in Android Studio).
Material Design 3, Google's current design standard, is a first-class citizen in Compose. Dynamic colour themes, adaptive layouts for large screens and tablets, and accessibility support are not add-ons but built-in foundations. Your app will immediately look familiar to Android users and meet the Play Store's review requirements.
For backend integration, we use Retrofit for REST connections and Room as the local database. Room generates SQL at compile time and throws an error if your queries are syntactically incorrect, a mistake that with hand-written SQL only surfaces in production. Dependency injection via Hilt keeps components loosely coupled, so swapping implementations and writing unit tests are no pain points.
If you need an application that makes heavy use of platform-specific Android features, such as widgets, NFC, Bluetooth LE, WorkManager for background tasks, or integration with device sensors, then native Kotlin is the right route. The full Android SDK is directly available, without wrapper overhead or polyfills.
Native Android stack
- Kotlin 2.x (coroutines, flows)
- Jetpack Compose + Material 3
- ViewModel + StateFlow
- Room (local database)
- Retrofit + OkHttp (API)
- Hilt (dependency injection)
- Navigation Component
- WorkManager (background)
- Firebase (analytics, push, auth)
- Gradle + build variants
Would you rather build for iOS and Android at the same time? Read about building an app in general, or see our Flutter service.
Cross-platform as an alternative: Flutter and React Native
Not every project requires fully native development for each platform. When budget, timeline or product roadmap call for a combined Android and iOS app, Flutter and React Native are both fully fledged options that Appfront actively works with.
Flutter: one codebase, native look and feel
Flutter is Google's own cross-platform toolkit and has its own rendering engine (Impeller). The app draws its own pixels, regardless of the underlying platform. This means pixel-perfect UI on both Android and iOS, including animations, without platform-specific polyfills.
The Dart programming language is optimised for client-side applications: JIT compilation during development (hot reload) and AOT compilation in production. Widgets are the building blocks of Flutter; they combine layout, painting and interaction within a single component. For state management we use Provider, Riverpod or Bloc, depending on the complexity of your app.
Flutter is an excellent choice when you want a uniform visual identity across both platforms while keeping development speed a high priority. You can find more information on our page about hiring Flutter developers.
React Native: leveraging JavaScript expertise
React Native compiles to native UI components: a button in React Native is a genuine Android Button or iOS UIButton, not a webview equivalent. The architecture has been entirely rewritten with the new "Fabric" renderer and the "TurboModules" system, which has largely eliminated the bridge overhead of the first generation.
Expo simplifies the management of builds, OTA updates and the Play Store publishing process. Does your organisation already have a JavaScript or TypeScript team? If so, React Native is a smart investment: the overlap with React web knowledge is substantial, which speeds up onboarding and knowledge transfer.
For projects with heavy platform-native requirements — camera, biometrics, BLE, NFC — we always recommend assessing feasibility feature by feature. In most business applications, the available native modules cover this fully.
| Criterion | Native Kotlin | Flutter | React Native |
|---|---|---|---|
| Platform access | Full Android SDK | Plugins + FFI | Modules + NativeWind |
| Development speed | Single platform | High (shared) | High (shared) |
| UI consistency | Android platform style | Custom rendering | Native UI elements |
| Ideal for | Android-first, complex features | Consistent multi-platform UI | JS teams, Expo workflow |
Want to know more about the costs and lead times of the different approaches? Our knowledge base page app development costs gives an honest overview of the factors that determine the investment.
From concept to Play Store: our Android development process
A successful Android app is the result of a considered process, not code produced as quickly as possible. Appfront works in short iterations with fixed checkpoints, so you always know where the project stands and can steer early.
Phase 1 — Discovery
Requirements analysis and technical architecture
We map out which user groups the app serves, which core processes are to be automated or supported, and which external systems (ERP, CRM, internal APIs) the app must connect to. On that basis we choose the platform (native or cross-platform) and design the data and module structure. This results in a technical design and a realistic project plan with sprint goals.
Phase 2 — UX & design
Wireframes, prototyping and Material Design implementation
We design the navigation structure and screen flows in clickable prototypes so you can validate the user experience before any code is written. The visual design follows Material Design 3 guidelines and your own brand identity. Special attention goes to accessibility: contrast standards (WCAG AA), screen reader support and touch targets large enough for all ages.
Phase 3 — Development
Agile sprints with weekly demos
Development runs in two-week sprints. At the end of each sprint, we demonstrate working functionality on a real Android device. You get access to an internal testing track (Google Play Internal Track or Firebase App Distribution) so you and your colleagues can test in between. Our CI/CD system runs automated builds and unit tests on every commit, so regressions are caught early.
Phase 4 — Testing
Quality assurance on real devices and API level
Alongside unit tests, we write instrumentation tests that simulate the complete user flow through the app (Espresso or Compose test APIs). We test on a broad selection of Android versions (at least API 26 unless agreed otherwise) and screen sizes, including tablets. API contracts are validated with integration tests. Performance analysis via the Android Profiler identifies memory leaks and slow render frames before the app goes live.
Phase 5 — Publication
Play Store review and staged rollout
We guide you through the entire Play Store process: setting up the developer account (if needed), completing the app listing, privacy policy, content ratings, and supplying the required screenshots and graphic assets. We use Google Play's staged rollout feature to first release the app to a small percentage of users, so any production issues are identified early, before the full release goes live.
Phase 6 — Aftercare
Monitoring, updates and ongoing development
After launch, we monitor crashes via Firebase Crashlytics and analyse usage patterns. Annual Android OS updates may require adjustments; we schedule regular maintenance windows to keep the app compatible and secure. For ongoing development, we work in the same sprint rhythm as during the initial build, so new features can be added quickly and in a controlled way.
Technologies and tools in our Android toolkit
The tools we use are not arbitrary choices. Each part of the stack is selected for stability, community support and alignment with Google's Android ecosystem.
Language & runtime
- Kotlin 2.x
- Coroutines + Flow
- Kotlin Serialisation
- Gradle (Kotlin DSL)
- Build variants & flavours
UI layer
- Jetpack Compose
- Material Design 3
- Navigation Component
- Accompanist libraries
- Adaptive layouts (tablet)
Data & persistence
- Room (SQLite ORM)
- DataStore (preferences)
- Retrofit + OkHttp
- Moshi / kotlinx.serialization
- Paging 3
Architecture
- MVVM + Clean Architecture
- Hilt (DI)
- ViewModel + StateFlow
- Repository pattern
- Use cases
Testing
- JUnit 5 + Mockk
- Espresso (UI tests)
- Compose testing APIs
- Robolectric
- Firebase Test Lab
Firebase & services
- Firebase Crashlytics
- Firebase Analytics
- Firebase Authentication
- Firebase Cloud Messaging
- Remote Config
CI/CD & releases
- GitHub Actions
- Fastlane
- Play Store Internal Track
- Firebase App Distribution
- ProGuard / R8 minifier
Cross-platform (optional)
- Flutter 3.x + Dart
- React Native (Expo)
- Kotlin Multiplatform
- Riverpod / Bloc
- Shared business logic
The choice of specific tools always depends on your project. At the start of every engagement, we discuss the requirements and select the most suitable combination. See also our overview of our app development services for more context on how we structure projects.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Why choose Appfront for your Android app
Many parties build Android apps. Here is what sets Appfront apart — and why that matters for your project.
- Fully in-house team. Design, development and testing are carried out by permanent Appfront staff — no freelance network or external subcontractors with whom you have no direct line. You know who is working on your product.
- Agile, without the jargon. We work in sprints and show working software every two weeks. You don't need to take a Scrum course to take part: every demo is a straightforward conversation about what has been built and what is next on the plan.
- Transparent about what is and isn't possible. If a feature is too complex for the available budget, or if a technical choice carries a risk, we say so. We don't make promises we can't keep just to win a contract.
- Dutch team, direct communication. No language barriers, no time zone issues, and no account managers filtering information. You have direct access to the people building your app.
- Focus on transferability. The code we write is well documented and follows widely accepted Android architecture patterns. If you later wish to continue development with an in-house team, you can do so without starting from scratch.
- From mobile to full platform. Does your Android app need a dashboard, admin environment or API backend? Appfront can build the full platform, mobile, web and backend, so no integration risks arise between different suppliers.
What we build
Security and compliance for Android applications
Security isn't a feature you can plug in afterwards. We build security-first: the measures are built into the architecture and the development workflow, not just a final check.
Code hardening
ProGuard and R8 obfuscation
Production APKs and AABs are optimised and obfuscated with R8. Class names, method names and variables are converted into meaningless characters, which makes reverse engineering considerably harder. Sensitive logic can be shielded from external access through sealed classes and internal API design.
Network security
Certificate pinning and HTTPS enforcement
Through the Android Network Security Configuration file we enforce HTTPS for all connections and block cleartext traffic. For applications where man-in-the-middle risks weigh especially heavily, we implement certificate pinning with OkHttp: the app only accepts connections with a predefined certificate or public key.
Authentication
BiometricPrompt and secure token storage
We implement sign-in via fingerprint or facial recognition using the BiometricPrompt API, which makes use of the device's secure hardware enclave. Tokens and sensitive credentials are stored in the Android Keystore — a hardware-backed storage layer that cannot easily be read by apps, or even by a rooted device.
OWASP Mobile
OWASP Mobile Top 10 checklist
For projects with elevated security requirements, we work through the OWASP Mobile Application Security Verification Standard (MASVS). This includes checks for insecure data storage, improper authentication, code injection risks, and the correct handling of deep links and intents. We document the findings and adjustments in the test report.
Play Store policy
Policy compliance and privacy label
Google Play requires an accurately completed Data Safety form, stating which data the app collects, for what purpose, and whether it is shared with third parties. We guide this process, align the form with the actual data flows in the app, and ensure the privacy policy and the app's implementation are consistent — a common cause of rejections during Play Store review.
GDPR
Privacy by design for the Dutch market
For applications that process personal data, we apply privacy by design: data minimisation (collecting only what is necessary), explicit consent for analytics trackers, the right of access to and erasure of user data, and encryption of sensitive fields in the local database. We advise on registration obligations with the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) where applicable.
Frequently asked questions about building an Android app
Practical answers to the questions we receive most often.
The investment depends on complexity, the number of features and the technology chosen (native or cross-platform). A simple app with a few core screens and a backend integration is very different in scope from an application with complex offline sync, real-time data or integrations with several external systems.
After a discovery call, we prepare a custom quote. Our page on how much custom app development costs gives an honest overview of the factors involved. We work on either a fixed project price or time-and-materials billing per sprint, depending on how certain the scope is.
The timeline varies. A focused MVP with a limited feature set can be ready for the Play Store in two to three months. More complex applications, with multiple user roles, extensive backend logic or hardware integrations, typically take four to six months.
The discovery and design phase at the start determines the quality of the plan. The better the requirements are worked out before the development sprints begin, the more reliable the time estimate. We always present a sprint-by-sprint plan before you approve the project.
The choice depends on your goals and constraints. Native Kotlin is the best option when you need deep platform integrations (BLE, NFC, custom camera, widgets), when you only support Android, or when every millisecond of performance matters.
Cross-platform (Flutter or React Native) is worth considering when you want to support Android and iOS at the same time with one development team, and when the feature set does not require deep platform-specific integrations. In practice, cross-platform covers the vast majority of business use cases. We advise based on your specific situation, not on a preference for any particular technology.
A native Kotlin app runs exclusively on Android. If you also want to support iOS, there are two routes. The first is building two separate native apps: one in Kotlin for Android and one in Swift for iOS. The second is choosing a cross-platform approach with Flutter or React Native, where the business logic and a large part of the UI are shared.
With cross-platform, we save development effort, but the two platforms each have their own deployment process (Play Store for Android, App Store for iOS). We guide you through both processes. You can read more about our approach on our app development page.
Publication runs through your own Google Play Developer account. Creating an account costs a one-time fee of $25 (paid to Google). If you do not yet have an account, we will help you register. The app is then delivered as an Android App Bundle (AAB), the format Google requires for all new apps.
We take care of the complete listing: descriptions in Dutch (and optionally other languages), screenshots in the correct formats, feature graphic, content rating questionnaire and the Data Safety form. Google usually reviews new apps within one to seven working days. We schedule the publication so that any review feedback can be addressed in good time.
Android releases a major OS update every year, and Google Play regularly tightens its API policy. Apps using outdated target SDK levels are flagged or even made unavailable for new downloads. Maintenance is therefore not an optional extra but a necessity for every live app.
We offer two forms of maintenance: an SLA with a fixed monthly retainer for monitoring, patching and minor adjustments, or individual sprints for larger updates and new features. In both cases we work with the same team that built the app, so there is no ramp-up period. Get in touch to discuss which maintenance structure suits your situation.
Ready to build your Android app?
Tell us about your project. We'd like to arrange a no-obligation conversation to discuss scope, platform and approach. No sales pitch: just a technical discussion with the people who will be building your app.