Getting a Mobile App Built: When You Need One and How React Native Development Works

No. A good share of the app requests that reach me turn into a website or a mobile-friendly admin panel once we talk through the need. Apps carry a hidden cost: your customer has to find yours, download it and consider it worth keeping on their phone. A website is one tap away; an app means going to the store, waiting for the install and freeing up space on the phone. Only apps that are used regularly get over that hurdle.

If your business comes from Google searches (restaurants, tours, car servicing, clinics and so on), your customer finds you at the moment of searching and decides on the spot. You can't get them to download an app at that moment; a good mobile site does the same job without the friction. The same goes for the admin panels I build for internal teams: a mobile-friendly panel that opens in the browser covers most businesses' needs out in the field.

In these cases, invest your money not in an app but in a good website or panel:

• Customers visit you once a month or less often
• Your business comes mainly from search engines and ads
• The goal is to provide information or take bookings or appointments
• Only your own team will use it, and there's always an internet connection

There are three concrete capabilities that justify an app. The first is offline use: if the user needs to keep working where there's no internet or a weak connection, a browser won't do. The second is notifications: if you need to reach the user (reminders, order status, new content), an app does that reliably. The third is device features: if you need deep access to hardware such as the camera, location or sensors, you're in app territory.

Then there's frequency. If we're talking about a tool the user will open every day, for studying, tracking or logging, having an icon on the home screen is valuable in itself. That was exactly why I built KPSS Hazırlık as an app: candidates studying for the exam solve questions on the shuttle bus, on the road and in places with no signal. A solution that didn't work offline couldn't have met that need.

If one of these statements is true for you, an app is worth discussing:

• My users need to be able to use it without an internet connection
• I need to reach my users; I can't wait for them to remember me
• The camera, location or another device feature is at the heart of the job
• Users will open this tool several times a week, or even every day

The traditional route means writing one app for iOS and a separate one for Android. That's two codebases, two development processes and, over time, two apps that drift apart. It's the most expensive way to bring an app idea to life. React Native produces real, store-ready apps for both platforms from a single codebase; the interface is drawn with the device's own native components, so the result feels like an app, not a web page.

I use React Native together with the Expo toolkit. Expo is a layer that streamlines building, test distribution and updates. It also makes it possible to get some small fixes to users without waiting for store review. In KPSS Hazırlık, the question bank, topic tracking, pomodoro timer and statistics all shipped to both iOS and Android from a single codebase with this setup.

Let me be honest about the limits too: for apps with heavy 3D graphics, games or very hardware-specific work, developing in each platform's own language may be the better choice. But the vast majority of business apps, anything that revolves around records, tracking, lists, forms and notifications, are squarely React Native's territory.

Getting into the stores is a separate process that begins where the technical work ends. Both stores require a developer account; Apple's has an annual renewal fee, Google's a one-off fee. Ask for the accounts to be opened in your name so that you own the app; many people who don't settle this detail at the start end up struggling with it later.

Both stores review every app submitted. Apple's review is stricter; being rejected on the first submission is a normal part of the process: you fix what's missing and resubmit. Review times are in the stores' hands, so be wary of anyone who promises you a firm store release date. When I plan, I factor in store review from the start as a wait that can't be negotiated.

What needs to be ready before you submit:

• Apple and Google developer accounts (in your name)
• The app name, description and store screenshots
• A live privacy policy page
• A build tested on real devices, on both platforms

KPSS Hazırlık brings together in one app the tools an exam candidate uses throughout the day: a question bank, topic tracking, a pomodoro timer and study statistics. The starting point was fragmentation: candidates used one app to solve questions, somewhere else to track topics and a third tool to stay focused. Its source code is public on GitHub; anyone who wants to see my mobile work can look at the code itself.

The clearest lesson was about scope. Trying to put every feature into the first version is why app projects never get finished. I cut the first version down to the core a candidate would use every day; everything else was left for later versions. In client projects I devote the first conversation to exactly this: what won't be in the first version needs to be just as clear as what will.

The second lesson was that offline architecture has to be set up from the start. Keeping data on the device and syncing it when a connection returns isn't a feature you add later; it's an architectural decision made at the very beginning. If your app will work offline, raise it on day one.

Once a website goes live, it can carry on by itself for a while; an app can't. Apple and Google update their operating systems regularly, and the stores require apps to target recent system versions. Apps that aren't kept up to date gradually lose visibility and can even be removed from the store. Maintenance isn't a nice-to-have extra; it's the condition for staying in the store.

What maintenance includes: keeping up with operating system and library updates, fixing bugs reported in user reviews, tracking changes to store policies and releasing new versions. I run this cycle myself for my own app, and in client projects I discuss post-launch maintenance from the start and write it into the scope. If you've seen a quote that gives a price without mentioning this item at all, you now know what's missing.