Mobile app development
An app-store icon is expensive when the job still works perfectly in a browser.
The short answer
Build a mobile app when the job depends on device capabilities, reliable notifications, frequent on-the-go use or work without a stable connection. Start with one complete mobile task, design the offline and permission states early, share business rules with the web product where practical and plan app-store releases as part of normal delivery.
Mobile is a product constraint, not a smaller screen. The useful question is not whether customers own phones. It is whether the job needs to leave the browser and what becomes harder once it does. A sound mobile plan earns the app-store overhead by naming the capability or behaviour that requires it.
Make the app justify its place on the device.
A responsive web application covers a surprising amount of mobile use. It opens from a link, updates immediately and avoids a separate store release. A native or cross-platform app becomes the better answer when the work needs reliable push notifications, camera capture, location, device storage, background activity or dependable access where the signal disappears.
Frequency matters too. A task someone completes twice a year rarely deserves an installation step. A task a field worker repeats throughout the day may benefit from a home-screen place, faster access and local data even if it uses no unusual hardware.
Write the mobile-only reason in one sentence before the build. If the sentence is only that people use phones, test the browser experience first. If it names a device capability or repeated field task, the team has a concrete constraint to design around.
Design the task around interruption, not an ideal session.
People use mobile products while moving, waiting, switching networks and responding to something else. A desktop flow can assume a stable session and enough room to compare information. A mobile flow has to preserve progress, make the next action obvious and recover when the operating system closes or pauses the app.
Start with the task that matters away from a desk. Map the minimum information needed to complete it and which parts can wait until a stronger connection returns. Remove fields that exist only because an old form had them. If a person needs reference information while entering data, keep it visible without forcing them through several screens.
1. Choose the field task
Name the action that benefits from being on the device and the conditions around it: light, gloves, movement, noise, signal and time pressure.
2. Map permissions and device access
Ask for camera, location, files or notifications only when the task needs them. Explain the consequence before the operating system prompt appears.
3. Define interrupted states
Decide what is saved when the app closes, the network drops or a call interrupts the task. A user should know whether their work is local, submitted or waiting.
4. Test on ordinary devices
Use older phones, small screens, limited storage and uneven connections. A fast simulator on a development machine hides the conditions that justify the app.
Offline is a state model, not a switch.
An offline requirement sounds binary until two people change the same record or a submitted photo is still waiting on the device. The product needs to distinguish work saved locally, work queued for upload, work accepted by the server and work that conflicts with a newer version.
Decide which tasks must work with no connection and which only need a clear blocked state. Download only the information a person needs for the next task, not the entire account. Encrypt sensitive local data, remove it when access changes and give the user a visible way to retry a failed sync.
Conflict rules belong to the product owner, not only to the sync library. Sometimes the latest change wins. Sometimes both versions must be preserved. Sometimes a supervisor decides. The correct answer depends on the work and should be written before an edge case silently overwrites it.
| State | What the app should communicate | What the system should do |
|---|---|---|
| Saved locally | The work is safe on this device | Persist it and retain the account context |
| Waiting to send | Submission has not reached the server | Queue it, retry and show status |
| Accepted | The server has the current version | Store a receipt or updated timestamp |
| Conflict | Another version needs a decision | Preserve both and follow the written rule |
One product does not mean one identical interface.
Sharing code across iOS and Android can reduce duplicated work, especially when the application is mostly forms, lists, content and familiar device features. It does not remove the need to respect each platform's navigation, permissions and release behaviour. Shared business rules are valuable. Forced visual sameness is not the goal.
The mobile and web products should usually share a backend and the rules that determine what a user may do. That keeps a change from being implemented three different ways. The interfaces can then adapt to the task: a compact capture flow on the phone, a broader review surface on the web and one accountable record underneath both.
We choose the approach against the product, the maintenance team and the device capabilities involved. The framework name is a consequence of those decisions, not the opening argument.
App-store delivery is part of the operating model.
A web release can reach every visitor at once. A mobile release passes through store review, reaches people gradually and may leave older versions active for months. Plan backward compatibility, minimum supported versions and the messages shown when an upgrade is required.
The client should own the Apple and Google accounts, signing access and store listings. Keep release notes, screenshots, privacy declarations and review credentials current. These are not launch paperwork to assemble after the code is finished. They are part of keeping the product available.
After release, watch crashes, failed network requests, sync queues and the completion of the core task. Download numbers say the app arrived. They do not say the mobile job became easier.
Review supported devices and operating-system versions as the product changes. Retire old versions deliberately, with enough notice and a tested upgrade path, rather than letting unsupported clients keep reaching a backend whose rules have moved on.
Worth knowing before you start
Write the device capability or repeated field task that makes an installed app necessary before approving the build.
Test interrupted, offline and denied-permission states in the first complete flow, not in a polish phase.
Put store accounts and signing ownership in the client's organisation from the beginning.
Measure completion of the mobile task after launch. Installs and opens are weak substitutes for useful work.
Related work
Common questions
Start with the job. A responsive web app is usually enough for occasional tasks that need a connection. An installed app earns its cost when people use it frequently, depend on notifications, need camera or location features, or must keep working through unreliable connectivity.
Often, especially for products built around forms, lists and shared business rules. The decision changes when the product relies heavily on platform-specific hardware, background behaviour or interfaces. Choose against the maintenance team and the actual device requirements rather than treating one codebase as a goal on its own.
Define which tasks work offline, what is stored on the device, how the user sees pending work and what happens when two versions conflict. Offline support needs a product rule for each state. A technical sync library cannot decide which person's change should win.
The client should own the store accounts, signing access and listings. A delivery team can manage releases, but the product should not depend on that supplier keeping an account open. Ownership also makes a future handover or team change much easier.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.