Mobile Apps
Choosing between native and cross-platform apps
Mobile app projects often begin with a decision that shapes everything afterwards: native or cross-platform. Native means building separately for iOS and Android using each platform's own tools. Cross-platform means writing one codebase that runs on both. Each approach has real trade-offs in cost, performance, and how the app feels to use.
What a native app is
A native app is built specifically for one platform. An iOS app is written with Apple's tools; an Android app with Google's. Because the code targets a single system, native apps can use that platform's features directly, and they tend to feel consistent with other apps on the device.
The cost is duplication. If you need both iOS and Android, you're effectively funding two builds, two sets of updates, and two release processes. For complex apps that rely on device features, that cost is sometimes justified.
A cross-platform app uses a shared codebase to produce versions for both iOS and Android. One team maintains most of the logic in one place, which reduces cost and keeps the two versions closer in behaviour. This is a common choice for business apps where the interface is largely forms, lists, and content.
The trade-off is that some platform-specific behaviour needs extra work, and very demanding interfaces can be harder to tune. For most business applications, cross-platform is a reasonable starting point.
What a cross-platform app is
How to decide
Look at what the app actually needs to do. If it mainly displays information, collects data, and connects to an API, cross-platform usually covers it. If it depends heavily on device sensors, background processing, or tight integration with platform services, native may be the better route.
Budget and timeline matter too. Two native builds take longer and cost more than one shared codebase. Decide whether you genuinely need both platforms at launch, or whether starting with one is acceptable.
Signs native may fit
- ●The app depends on device sensors, camera features, or background processing that needs platform-level access.
- ●The interface has demanding animations or custom interactions that are harder to tune across two platforms.
- ●Both iOS and Android versions are needed at launch, and the budget supports two builds.
Signs cross-platform may fit
- ●The app mainly displays information, collects form data, and connects to an API or content service.
- ●One team will maintain the logic, and keeping the two versions close in behaviour matters more than platform-specific tuning.
- ●You want to reach both platforms sooner without funding two separate builds.
UI and UX on small screens
Mobile design is not a shrunken website. Screens are small, attention is short, and gestures replace the mouse. UI/UX design for an app focuses on clear navigation, readable text, and controls that are easy to tap.
Prototyping helps here. A clickable prototype in Figma lets you test a sign-up flow or a booking sequence before development, when changes are still inexpensive. This stage is easy to skip and expensive to skip.
When testing, walk through the app on a real device rather than a desktop preview. Tap targets should be comfortable for a thumb, text should stay readable at arm's length, and each screen should make the next step obvious without extra explanation.
Connecting to your systems
Most business apps connect to something: a CRM, an ordering system, a payment provider, or a content service. That connection is done through APIs. A headless CMS such as Strapi, for example, can deliver content to both a website and an app from one source, so editors update in one place.
Plan the API surface
Agree early on which systems the app reads from and writes to, and what each call is expected to return. That list becomes the contract between the app and your backend.
One source for content
A headless CMS can feed the website and the app from the same place, so editors publish once and both surfaces update without a new release.
Handle slow networks
Apps should handle slow networks and unavailable services gracefully, and users should see a clear message rather than a blank screen.
Release and store requirements
Publishing to the Apple App Store and Google Play involves review processes, privacy disclosures, and account setup. Both stores require information about what data the app collects and how it's used. Preparing this early avoids delays at submission.
Updates follow the same route. A native app update goes through store review each time. Cross-platform apps usually do as well, unless the change is delivered through a server-side update.
Store accounts and review
Set up developer accounts for both stores well before launch. First submissions often take longer than expected.
Privacy disclosures
Describe what data the app collects, why, and where it goes. Both stores ask for this before the app goes live.
Update route
Decide which changes can be pushed from the server and which need a full store submission and review cycle.
Maintenance for mobile apps
Mobile apps need ongoing attention: operating system updates, library updates, store policy changes, and occasional fixes. Support arrangements should specify how often updates are released and who handles store submissions.
OS and library updates
New iOS and Android releases change how apps behave. Libraries the app depends on also need updates to keep working as platforms move.
Device fragmentation
Android runs across a wide range of screen sizes and versions. Testing across a representative set catches layout and performance issues early.
Store policy changes
Apple and Google adjust their review rules over time. An app that passed last year may need small changes to stay listed and updateable.
Support scope
Agree who responds when something breaks, how quickly fixes ship, and whether new features are covered or handled separately.
Starting a mobile project
Before development, settle four things: which platforms you need, whether the app is customer-facing or internal, which systems it must connect to, and who will maintain it after launch. Answers to those four questions shape the estimate more than anything else. If any of them is unclear, discovery is the place to resolve it.
Which platforms
iOS, Android, or both at launch. This is the first decision and it changes the shape of the rest.
Who it's for
Customer-facing apps carry different design and release pressure than tools used only by your own staff.
Which systems
The CRM, ordering system, payment provider, or CMS the app must connect to through APIs.
Who maintains it
The person or team responsible for updates and store submissions after launch.
Questions worth settling early
Do we need both iOS and Android at launch? +
Not always. If most of your users are on one platform, starting there and adding the other later can keep the first release focused. It also gives the team real usage to learn from before funding a second build.
Can we start cross-platform and switch later? +
It happens, but it is a rebuild rather than a settings change. Moving from cross-platform to native means writing the platform-specific parts again. If you expect to need native early, plan for it from the start.
How much of the app can be tested before development? +
A clickable prototype covers the main flows: sign-up, booking, checkout, or search. It will not prove performance or device behaviour, but it catches layout and wording problems while they are still cheap to change.
Who handles store submissions after launch? +
That should be written into the support arrangement. Submissions need account access, release notes, and a response to reviewer questions, so it is worth naming one owner rather than assuming it will be handled.
How do apps handle losing connection? +
Good apps assume the network will fail sometimes. They show a clear message, keep already-loaded content visible, and let the user retry instead of dropping to a blank screen.
Where to go next
Read how projects are run, look at design and UX in more detail, or ask about a specific mobile project.
Start with the four questions
Platforms, audience, systems, and maintenance. Settle those and the rest of the mobile app plan gets much easier to scope.