What makes Android different
Android runs on most of the world's smartphones. But Android isn't a single phone. It's hundreds of models from different manufacturers, with different screens, memory, custom skins, and battery-saving settings.
For a business, that's both an opportunity and a challenge. On one hand, your app reaches the widest possible audience and can run on affordable work devices. On the other, it has to be tested on far more models than an iOS app.
Benefits of native Android development
- Full system access. Background services, actionable notifications, widgets, file sharing between apps, and external hardware such as receipt printers, scanners, and scales.
- Stable on low-end devices. Native code usually uses less memory and battery, which matters for budget phones and terminals that run a full shift.
- Flexible distribution. Beyond Google Play, the app can be installed directly on company devices without publishing it to the store.
- New Android features right away. When Google adds a capability, native code gets it immediately, with no wait for framework support.
Limitations and challenges
- Device fragmentation. What works on one phone may behave differently on another. Testing takes up a noticeable share of the project.
- Aggressive battery optimization. Some manufacturers force-stop background processes, so reminders and location tracking need careful testing.
- Devices without Google services. Some devices, such as Amazon Fire tablets and certain Huawei phones, don't have them, so push notifications, maps, and Google sign-in have to be implemented separately.
- Google Play requirements. The store regularly raises the target Android version requirement. Apps that go a long time without updates eventually stop showing up for people with newer phones.
- One platform only. iPhone users will need a separate app with its own codebase.
When another route makes more sense
We'll advise against native Android if:
- you need both platforms at once and the features are standard, in which case a cross-platform app with a single codebase is more cost-effective;
- your audience mostly uses Apple devices, in which case it's smarter to start with an iOS version;
- the app only needs to let customers browse a catalog and submit a request, which a well-built mobile website often handles better.
Kotlin and Jetpack Compose
Today, the primary language for Android is Kotlin. Google recommends it, and new tools and documentation are built Kotlin-first. It's fully interoperable with Java, so older apps can be migrated gradually, piece by piece.
We build the UI with Jetpack Compose. Screens are defined in code rather than separate XML layouts, so they're faster to change and the design never drifts from the behavior. In older projects, Compose can be adopted screen by screen without rewriting everything at once.
Apps for customers and for employees
Customer apps cover catalogs and ordering, loyalty programs, booking, and customer accounts. What matters most here is an easy-to-use interface, fast startup, and well-handled notifications.
Work apps for couriers, warehouse staff, sales reps, or field service engineers have different requirements:
- work offline and sync data as soon as a connection is available;
- read barcodes with the terminal's built-in scanner, not just the camera;
- run in kiosk mode, with only one app open on the device;
- update centrally across all company devices.
For tasks like these, native Android is often the most reliable option.
New app or improving an existing one
For a new app, we start by choosing the target devices and the minimum Android version, since that determines which features are available and how much testing is needed.
An existing app gets an audit first: how much code is still in Java, how old the libraries are, crash reports, and compliance with current Google Play requirements. Then we propose a plan: what to fix right away and what to modernize gradually between releases.
An interface that feels like Android
A common mistake is to take the iOS design and simply port it to Android. Users notice the difference immediately: the Back button works differently, and menus, toggles, dialogs, and date pickers look different.
We build on Material Design without making the app generic: your brand colors, fonts, and illustrations sit on top of familiar Android patterns. We also check how the interface looks with a large system font, in dark mode, and on the narrow screens of budget models.
Google Play publishing and support
We recommend registering the Google Play developer account in your company's name, so the app, its analytics, and its reviews belong to you. We prepare the store listing, screenshots, description, data safety form, and content rating.
We roll out new versions gradually: first to a small percentage of users, and only to everyone once crash reports look clean. After launch, we can take the app on for support and ongoing development: monitoring errors, keeping up with new Google Play requirements, and adding features.
What affects the cost
- Device list: modern smartphones only, or also older models, tablets, and specialized terminals.
- Server side: we connect to your API or build the backend and admin panel from scratch.
- Background and offline work: location tracking, data queues, and syncing.
- Hardware: scanners, printers, payment terminals, and other external devices.
- Code condition: for existing apps, the amount of Java code, outdated libraries, and test coverage.
We provide an exact estimate after reviewing your requirements and show you the stages the work breaks down into.
Frequently asked questions
Will the app work on older phones? That depends on the minimum Android version we choose together. The older the devices we support, the more limitations and testing there are.
Can the app be installed without Google Play? Yes. For internal company apps, this is standard practice: they're installed directly on work devices.
Do we have to rewrite our old Java app? Not necessarily. New parts can be written in Kotlin, and the old code migrated gradually as you get to it.
Will the app work on devices without Google services, such as Huawei phones or Amazon Fire tablets? Yes, but features that depend on Google services need to be implemented separately for them. We discuss this at the start.
Can we add an iPhone version later? Yes. The server, user flows, and design will already be in place, so an iOS version usually takes less work. Sometimes at that point we recommend considering a shared codebase for both platforms.
Why Promodex
We've been in business since 2015 and have delivered 750+ projects. Mobile apps in our portfolio include Fuelio, Idram, My Viva, and List. UX, design, and development are handled by our full-time in-house specialists, and we never bring in outside contractors. We don't disappear after the Google Play launch: we update the app for new Android versions and keep developing it as your business grows.
