An Android app developer in Dubai, testing on the phones your customers carry

Android is not one platform in the way iOS is. Samsung, Xiaomi, Oppo, Huawei and others ship their own versions of it on phones that range from flagships to budget models several years old, with different screen sizes, memory and battery rules. An app that is only tested on one recent phone will meet the rest for the first time in the hands of a customer.

There is a regional detail worth knowing early. Recent Huawei phones ship without Google Play services, so features that depend on them, such as Firebase push notifications and Google sign-in, need an alternative or are accepted as a gap, and Huawei has its own store, AppGallery. Whether that matters depends on your audience, and it is decided before the build rather than after the first complaint.

I build Android apps in React Native rather than Kotlin. The app is a real Android app using Android's own components, and it shares its code with the iOS version, so a feature or a fix is built once. For the kind of apps most businesses need, the difference to a user is not visible; the difference to a budget is.

What does not come for free is Android's own behaviour, and it is built deliberately: the system back gesture, how the keyboard pushes a form up, runtime permissions, notification channels a user can switch off one at a time, and background limits that some phone makers apply more strictly than others. The shared build is covered on the React Native development page.

Testing happens on real devices across ages and price points, not only in the emulator. Small screens, large font settings, Arabic right-to-left layouts, low memory and weak connections each find different problems, and each reflects someone in your audience. A form that hides its submit button behind the keyboard on a small phone is a lost lead that no report will explain.

Where a wider spread of devices is needed than a desk can hold, a device cloud such as Firebase Test Lab runs the app across many more models. Crashes and slow screens in production are reported back through crash reporting, so problems on a particular model show up as data rather than as one-star reviews.

Apps are published through Google Play Console under your organisation's account. Builds go first to internal testing, then closed or open testing tracks, and releases to the public can be staged so an update reaches a share of users first. New personal developer accounts must complete a closed test with real testers before publishing, which is one reason a business should publish under an organisation account.

Each app also needs its Data safety section, which declares what data is collected and shared, a content rating and a target audience, and it has to meet Google Play's current target API level. The store listing is a conversion page: a short description of up to 80 characters, screenshots that show the app doing its job, and custom store listings where a campaign deserves its own version.

Google Play passes campaign details to the app through the Play Install Referrer, so installs can be attributed to the campaign that produced them, and app campaigns in Google Ads and Meta use that data to find more of the right users. In-app events, an enquiry, a booking, a brochure download, go to Firebase Analytics and GA4 so you can see what installs turn into.

Leads created in the app should land in the same CRM as everything else, with their source attached, which is the job of the app back end and the CRM integration behind it. The iPhone side of the same app is on the iOS app developer page.