How to make a mobile app for your business — from choosing a platform to publishing it

A mobile app's schedule has two parties who never appear in the contract: Apple and Google. A contractor can build the app on time and still miss the launch date — because the company doesn't yet have the number needed to open a developer account, because a new Google Play account requires a two-week test, or because the store review sent a version back for changes. None of this shows up in a quote, and each one moves the launch date.

This article is about that second half of the work. It shows which platform to start from, how native and cross-platform apps differ, what changes when you design for a phone, and what an app's route to the store looks like, step by step, with the timelines Apple and Google publish themselves. We cover the project itself, from brief through prototype to handover, in our article on how to build an app for your business; here we focus on what's different about an app for a phone.

Does it have to be a store app

Before you start planning a mobile app, it's worth settling whether it really has to reach the App Store and Google Play. Some of what companies mean when they ask for "a phone app" is better served by a well-built website or web app, and some by a PWA — a website you can install on a phone without going through a store at all.

The criteria for that decision — how often users come back, whether you need phone features, and whether the store is a channel for reaching people — are covered in our article on what a mobile app is and when it makes sense for a business, and the limits of a PWA on iPhone and Android in our article on progressive web apps: what they are and when they replace a store app. From here on, we assume the decision is made: the app has to be in a store.

Android or iOS — where to start

The first design decision is usually which platform comes first. The market points to Android. In Poland in August 2026, Android held 69.3% of phone page views and iOS 30.64% (StatCounter). With a lead like that, starting with Android looks obvious.

Who will actually use your app, though, can look quite different from the Polish average. Starting with one platform cuts off a significant part of your audience — and not always the part you expect. That's a reason to check your own numbers rather than lean on a single national figure: look at your own analytics for the share of visitors on iPhone versus Android, or, if the app is for staff, at the phones the company actually issues. Only those two numbers tell you whether to build for both platforms from day one, or start with one — and which.

Native or cross-platform — what React Native and Flutter are

The second decision is about how the app gets built. There are two main routes.

A native app is written separately for each system, in the tools and languages Apple and Google provide. It makes the fullest use of what the phone can do, but it means two codebases, two sets of tests, and usually two teams — or one team that knows both worlds well.

A cross-platform app is built from a single codebase that ships to both systems. Two technologies are most commonly used for this. React Native, maintained by Meta, lets you write the app in JavaScript and, as its documentation puts it, creates the corresponding Android and iOS views at runtime (React Native). Flutter, maintained by Google, uses the Dart language and draws its own interface with its own rendering engine. Either way, the user gets an app that looks and feels native, and the company gets one codebase.

Watch out for the word "hybrid". It usually means a website wrapped in a native shell, not an app built in React Native or Flutter — and in sales pitches it's sometimes used for both, which makes quotes harder to compare. If a contractor proposes a "hybrid app", ask exactly what technology they mean.

A cross-platform app doesn't change one thing: you write it once, but you publish it twice. There are two stores, two accounts, two reviews and two sets of requirements that change every year. The saving on code is real; there's no saving on the route to the store.

Designing for mobile

Designing for a phone isn't a smaller-scale version of designing a website. Three differences change decisions that don't matter at all on a computer.

A thumb, not a mouse. An app is often used one-handed, on the move, in gloves or with a bag in the other hand. The most important actions need to sit within a thumb's reach, and buttons need to be large enough to hit without aiming carefully. What's a minor inconvenience on a computer is a reason to give up on a phone.

Patchy signal. A phone loses its connection in a lift, in a warehouse basement, on the road. The app has to know what to do when there's no network: show saved data, accept an entry and send it later, or say honestly that a feature needs a connection. That's a decision to make at the design stage, not after the complaints start.

Notifications as part of the product. On a phone, a notification is often the main reason someone opens an app. You have to design when to send them, about what, how often — and what happens if the user says no. An app that loses its point without notifications should ask for them at the moment their value is obvious, not on first launch.

Apple and Google guidelines — two conventions, one app

Each platform has its own design rulebook: Apple publishes the Human Interface Guidelines, Google the Material Design guidelines. They describe how basic elements look and behave — navigation, buttons, lists, dialogs, going back to the previous screen. Users know these conventions from every other app on their phone, even if they've never read a word of the guidelines themselves, and any departure from them reads as "something isn't right".

For a cross-platform app, that's a challenge, because one codebase has to feel natural under two different conventions. Good teams solve it by keeping the logic and brand look shared, while system elements — navigation, gestures, dialogs — behave the way each platform expects. Ask your contractor how they handle this. If the answer is "the app looks the same everywhere", it will look foreign on one of the two systems.

Beyond that, designing a mobile app runs the same course as any other: from a wireframe, through a clickable prototype, to visual design. We describe that part, and the client's role at each stage, in our article on how an app project runs.

A mobile app needs a back end

A phone app rarely works alone. Orders, submissions, customer data or stock levels have to be stored somewhere and come from somewhere — a server the app talks to through an API. If you already have a web app or a customer portal, the mobile app can use the same back end. If not, it has to be built, and that's a separate line in the schedule: under the rules we use to plan projects, preparing an API for a mobile app alone takes three to six weeks.

The second thing is the systems you already use. A sales app that can't see stock levels from your warehouse system, or a field-service app that doesn't log jobs in your CRM, quickly becomes one more place someone has to copy data into by hand. Each such integration is separate work and a separate risk — worth listing in the brief before your contractor names a date.

Developer account: Google Play and the Apple Developer Program

For an app to reach a store, someone has to publish it there from their own developer account — the Apple Developer Program for the App Store, the Google Play Console for Google's store. And here comes a decision that looks like a formality but has long-term consequences: whose account it is.

The account should belong to your company, not your contractor. Whoever holds the account is the app's publisher: their name appears in the store, they take the payments, and they decide on every version. If the app is published from a contractor's account, changing contractor later means moving the app between accounts, which isn't always simple — and, in the worst case, republishing from scratch, losing ratings and downloads along the way.

Both stores distinguish between personal and organisation accounts. For a business, an organisation account is the right one, and both stores require the same document for it: a D-U-N-S number (Apple, Google Play). We set out account fees and the costs that recur every year in our article on mobile apps in a business.

What a DUNS number is and where to get one

A D-U-N-S number is a nine-digit business identifier issued by Dun & Bradstreet. Apple and Google use it to check that the company opening an account exists and is who it says it is. Without one, you can't open an organisation account with either store.

The good news is that the number is free, and many companies already have one without knowing it. Apple offers a lookup tool to check, and a form for requesting a new number. The bad news is about time: Apple recommends allowing up to five business days to receive the number from Dun & Bradstreet, and up to two more before Apple has the data and lets you open a business account (Apple, D-U-N-S Number).

In practice, it's worth checking or requesting the D-U-N-S number right at the start of the project — the same week you sign the contract with a contractor. Left until the end, it pushes the launch back by a week and a half, for a reason that has nothing to do with the app itself.

Closed testing and review — the route to the store

Once the app is ready, a stage begins over which your contractor has the least influence. The figure below brings all the steps together, with the timelines the stores themselves publish.

Closed testing in Google Play. Google requires developers with personal accounts created after 13 November 2023 to run a closed test with at least 12 testers, continuously enrolled for at least 14 days, before publishing (Google Play). Until December 2024 the requirement was 20 testers, which is why that figure still circulates in a lot of guides. Google's page describes this obligation for personal accounts; it says nothing about organisation accounts. That's another reason to publish a company's app from a company account — but if for any reason you start from a personal one, build those two weeks into your schedule.

Store review. Every app goes through review before it reaches users. Apple states that it reviews 90% of submissions in under 24 hours (Apple, App Review). Google notes that for some accounts and apps review can take up to seven days, and longer in exceptional cases (Google Play). A fast review doesn't always mean a positive one, though: a rejection asking for a fix is a normal part of a first submission, and it's worth leaving room for it.

Every subsequent version. Review doesn't end after the first launch. Every update — even a bug fix — goes back into the queue. For a web app, you push a fix in minutes; for a store app, you have to add review time, separately for each store.

Testing a mobile app on real devices

An app that works on the developer's own phone doesn't necessarily work on your customer's. On iPhone, the problem is smaller, because there are few models and most users update quickly. On Android it's the opposite: many manufacturers each make their own changes to the system, screens and processing power vary, and old system versions live on for years. A bug that only shows up on one model from a popular brand can still reach a large share of your users.

That's why mobile testing happens on real devices, not only in an emulator. In our own process, that's a matrix of three to five iPhone models on the two latest iOS versions, and four to six Android models from several brands on the three latest system versions, checked under different network conditions — from good Wi-Fi to no signal at all. If the app is for your own staff, the simplest rule is: test on the phones you actually hand out.

Ask your contractor which devices they'll test on, and ask for that list in writing. "Emulators and our own phones" as an answer means some bugs will only be found by your users — and in a store app, every fix still has to go through review.

How long a mobile app takes

The clock on a mobile app is really two clocks: building it, and the stores. In our process, building breaks down into stages whose length depends on scope: Discovery takes one to three weeks, visual design and UX two to four, development six to twenty-four, testing on real devices two to four, and store publication one to three weeks. If the app needs its own back end to talk to, under the rules we use to plan projects, that adds three to six weeks for the API.

The store clock runs partly in parallel — but only if someone looks after it. A D-U-N-S number and business accounts can be set up in the project's first week, while Discovery is under way. Left until the end, they add an unplanned week and a half to the deadline. The same goes for testing: if testers from your own company use test builds from the middle of development onward, nobody has to wait for them at the end.

After launch

An app in a store isn't finished. Apple and Google release new system versions every year, and the stores update their requirements — on privacy, permissions, or the minimum tooling an app is built with. An app nobody updates eventually stops meeting those requirements and can be hidden from the store, or fail review at the next fix.

That's why maintaining a mobile app is an ongoing cost, not a one-off: updates for new systems, fixes after store changes, renewing the Apple account. We break down what that bill is made of in our article on app development cost, and the market prices for the build itself in our report on mobile app costs — our study of the Polish market.

When you're looking for a contractor

If, after reading this, you know you need a store app and are looking for a company to build it and carry it through publication, we describe how we build mobile apps for businesses — from Discovery, through testing on real devices, to publishing from an account that belongs to you.