Mobile Development: Android, iOS and React Native

Start with the need

A mobile app should make a specific task easier

Start with users, their devices and the circumstances in which they work. A customer booking a visit and a field worker recording a delivery need different journeys.

Mobile development combines interface design, application logic, device capabilities and connected services. Useful applications can support customer self-service, orders, learning, appointments or work away from a desk. Choose a small set of important tasks before expanding the feature list.

A website that fits a phone remains a website. An installed app has its own distribution and update responsibilities. A responsive website or progressive web app may be enough for some needs; available installation, background and device features depend on the browser and platform.

Mobile application screens and connected digital services.

Choose a platform

Native and cross-platform approaches

The choice depends on the audience, device integrations, existing skills and the cost of maintaining each platform.

Native Android or iOS

Platform-specific development can suit deep device integration or highly specialized interactions. Separate implementations require their own development, testing and maintenance plans.

React Native

React Native uses React and native platform capabilities to build Android and iOS applications. Shared application code is possible, while platform-specific work and testing remain necessary.

A mobile web option

A browser-based experience can reduce installation friction. Evaluate required device access and offline behavior on the actual supported browsers before choosing it.

Useful capabilities

Select features around real journeys

Each capability needs a purpose, clear behavior when it fails and a defined source of information.

Accounts and access

Sign-in, account recovery and role-based actions, with sensitive permissions checked by the server.

Orders and self-service

Search, forms, bookings, status tracking and history, designed for short sessions and interruptions.

Notifications

Relevant updates with user preferences and a useful destination when opened; delivery should not be the only record of an important event.

Device features

Camera, location or file access where justified. Use platform pickers where possible, request necessary permissions at the right moment and handle refusal gracefully.

APIs and offline work

Connect mobile, web and operational systems

A backend built with Django or Node.js can expose an API used by both a website and a mobile application.

Agree which system owns each record, who can change it and how the app reports errors. Plan session expiry, validation, pagination and retries so a slow connection does not create duplicate submissions. Existing APIs need a compatibility review before promising reuse.

Offline work is an explicit design choice. Identify which records can be viewed locally, which actions can be queued and what must wait for a connection. Decide how to protect stored information, show synchronization status and resolve conflicting changes. Test interrupted uploads and repeated requests.

Quality and privacy

Test the experience people actually use

Agree on supported devices and operating systems, then combine automated checks with testing on representative physical devices.

Check text size, contrast, screen readers, touch targets, right-to-left layouts and keyboard behavior in every supported language.
Exercise slow networks, lost connections, denied permissions, interrupted sessions and app restarts.
Measure startup, scrolling, battery and data usage on realistic devices and realistic records.
Review sensitive storage, secure transport, server-side authorization and third-party dependencies; collect only information needed for the agreed purpose.

From idea to release

Build through visible, reviewable stages

A staged process lets users validate the direction before the full application is completed.

Discover and scope
Identify users, priority tasks, supported platforms, integrations and acceptance criteria.
Design and prototype
Review navigation, screen states, language and accessibility with a clickable prototype.
Build and connect
Implement agreed journeys, APIs and device features in demonstrable increments.
Test and run a beta
Check real devices, difficult conditions and user feedback before preparing release builds.
Prepare and submit
Prepare listings, screenshots, privacy information and review access; respond to store feedback.
Release and support
Plan rollout, monitor reported issues and agree how fixes and later improvements are handled.

Ownership and handover

Make delivery responsibilities clear

The agreement should specify what is delivered and who controls the accounts needed to operate and update the app.

Define ownership and access for source code, design files, developer accounts, signing credentials, domains and backend services.
Document build and release instructions, environments, API dependencies and operational contacts.
Agree training, data export arrangements and the process for access transfer or revocation.

Budget and support

Plan the ongoing product, as well as the first release

Estimate after the scope, integrations and acceptance criteria are understood. A phased release can keep initial work focused.

Development effort

Platforms, unique screens, offline rules, device features, integrations and testing coverage influence time and cost.

Recurring services

Allow for developer accounts, hosting, messaging, storage, monitoring and other usage-based services where needed.

Maintenance and change

Define response hours, issue priorities, compatibility updates and the difference between correcting defects and adding new capabilities.

Questions before starting a mobile app

Clarify these choices before committing to a feature list or release date.

Do I need an app or a mobile-friendly website?

Compare installation, repeat use, required device access and distribution needs. A responsive website may meet the goal with less operational work.

Can one project cover Android and iOS?

A cross-platform approach can share code, but each platform still needs its own configuration, device checks and release preparation.

Can the app connect to an existing website?

Often, if suitable APIs and permissions exist. Review the backend, data model and integration limits before confirming the scope.

Will it work without internet?

Only the tasks designed and tested for offline use. Local storage, synchronization and conflict rules must be included explicitly.

Are payments and location included?

They are optional capabilities. Provider availability, permissions, platform rules and the exact user journey need review before implementation.

Who owns the store accounts?

Ownership and access should be written into the agreement so the organization can operate the app and authorize future releases.

Can a store release date be guaranteed?

Development milestones can be planned; external review and approval remain outside the development team’s control.

What happens after launch?

Agree monitoring, defect reporting, compatibility work and support coverage. New features can then be prioritized as separate improvements.

Official references

Use current platform guidance when confirming technical choices and release requirements.

React Native components
How React Native uses native Android and iOS capabilities.
Android permissions
Permission types, user choice and minimizing access requests.
Android offline architecture
Local information, network access and synchronization design.
Android app quality
Usability, accessibility, reliability and security considerations.
Apple App Review Guidelines
Preparation and requirements for App Store review.

Start with the tasks your users need to complete

Describe the audience, devices, essential journeys and existing systems to shape a practical first release.

Discuss your mobile project