A React Native developer in Dubai, one app for iPhone and Android

React Native suits the large majority of business apps: screens of lists, forms, search, maps, media, accounts and notifications. That covers customer apps, booking apps, loyalty and content apps, and the internal tools sales teams use. For those, one React Native codebase produces a real app for iPhone and Android, using each platform's own interface components, and every later change is made once.

It is the wrong tool for a narrow set of apps: games and constant heavy graphics, deep custom hardware work, or a product whose value depends on the newest Apple or Google features on the day they ship. If yours is one of them, I will say so. The fuller argument, written so you could use it against me, is in native vs cross-platform.

Much of my app work is for property sales teams, and it shapes how I build. A sales app is used in front of a buyer, on a tablet in a sales centre or a phone in a meeting, so it has to be fast, obvious and right. The work has included 3D views of buildings and floors a buyer can rotate, unit availability read from the CRM so it is true at the moment it is shown, and live project data such as pricing, payment plans and construction progress.

Two examples written up as case studies show the range. The LEOS mobile app is a React Native app for iOS and Android from one codebase. The LEOS sales application shows the same thinking on a showroom touch screen: every development in one place, 3D floor plates and availability from the CRM.

Most slow React Native apps are slow for the same few reasons: long lists rendered all at once, images downloaded at full size, and screens that re-render whenever anything changes. Long lists use virtualised components, explained in FlatList vs ScrollView, images are sized and cached, and state is structured so a change redraws only what it affects.

The app is then measured on the phones your customers carry, which in this market includes plenty of mid-range Android devices, not only the newest iPhone on the developer's desk. Start-up time, scrolling and memory are checked on real hardware before each release, because an app that stutters on first launch rarely gets a second one.

Analytics go in during the build. Screen views and the handful of events that matter to the business, such as an enquiry, a booking or a brochure download, are sent to Firebase Analytics and GA4, and to Meta and Google where app campaigns are running. Deep links let a campaign open the app on the right screen rather than its home page, which is often the difference between an install and a lead.

Leads created in the app go to your CRM with their source, the same as a website enquiry, through the app back end. The store listings are written as conversion pages, and each store has its own rules, covered on the iOS app developer and Android app developer pages.

Builds run through Expo's build service or the native toolchains, and every release goes to testers first, TestFlight on iOS and a testing track on Android, before the public stores. Small JavaScript fixes can ship as over-the-air updates within the stores' rules, so a typo does not need a full review cycle.

The code is TypeScript in a repository you own, and the Apple and Google accounts are yours from the first submission. Handover includes how to build and release, so another developer could pick the app up. If you are still deciding whether you need an app at all, the mobile app development page starts there.