Every iPhone and iPad in your organisation can run the whole product right now, in Safari: approvals, purchase orders, requests, invoices, tickets, reports. What a native app adds is the hardware — the camera, working with no signal, and push that arrives with the browser closed. That app is a build rather than a rewrite: the iOS half of the codebase is already written and the Xcode project is already in the repository. Below is exactly how far it has got, the five pieces of work that finish it, and how to put your team at the front of that queue.
The distinction is worth drawing carefully, because a native app is often read as the only way onto a phone, and for a manager doing approvals from a taxi that is not where the line falls. The line is the hardware: anything that needs the camera, the filesystem or a background process is what the app adds, and everything else runs in Safari today.
AWRA OpsHub is a responsive web application and it runs on an iPhone or iPad the same way it runs on a laptop. Approvals, purchase orders, requests, invoices, tickets, reports — all of it. A manager approving a requisition from a taxi is doing something the product supports today, on iOS, with no app involved.
Sign-in, multi-factor, session limits, session timeout, password policy, IP allowlisting, device approval and the audit trail are all server-side. They apply to an iPhone signing in through Safari exactly as they apply to a laptop. None of that is waiting on an app.
Barcode and QR scanning through the device camera, work that continues with no signal and syncs when the signal returns, push that arrives with the browser closed, and a signature captured with a finger. These are what the native app adds to an Apple device, and they are why it is worth building rather than a nicety.
Worth being precise about one thing, because it changes which route suits you: today the web app is responsive, so adding it to your home screen gives you a fast bookmark. An installable, offline-capable web app for iOS is on the list of things we can build, and for a team that mostly needs the browser it is the nearer-term route of the two. We will tell you which one fits your field work rather than sell you both.
The Android app was written as one cross-platform codebase with one platform switched on, and the iOS arm of it was written at the same time. That is why the remaining work is a list of build tasks rather than a project.
The thirty-five platform branches are the interesting number. They are the places where iOS and Android genuinely differ — keyboard behaviour, safe areas, permission prompts, how a share sheet opens — and the iOS side of each was written at the time rather than left as a stub. Each one is waiting to be run on a device and confirmed, which is a real piece of work and it is testing rather than building.
None of these is a research problem. They are the ordinary cost of adding a second mobile platform, and the reason they are still ahead of us is that we took Android all the way to a real release first.
The iOS project already declares what it needs; installing those dependencies and pinning them in a lock file is what produces the first build of the target. It is the first task on the list and the one that surfaces whatever else wants updating.
Apple's distribution model runs on certificates, an app identifier, capability entitlements for camera and push, and a provisioning profile for each of them. It is administrative rather than difficult, and it is a fixed, known piece of work.
Our build script already produces an Android release and ships it to testers. Adding the iOS lane beside it is what turns a local build into a repeatable release, a TestFlight route, and a build we can hand to a customer who wants to try it.
Notification delivery, the per-device token records and the failure diagnostics that tell an administrator why a push did not arrive are all built, against the Android transport. Apple's notification service is a second transport wired into those same diagnostics rather than a second notification system.
Managed configuration, jailbreak and root checks, and blurring the app in the task switcher are platform-specific by nature, so each has an iOS equivalent that is built alongside the app rather than ahead of it. The Android page describes them the same way round, so the two pages agree.
What you get instead of a date is the list above and the sheet at the top of this page, both read from the repository, so you can judge the distance yourself — and a conversation about what commissioning it would look like, if your deployment needs it sooner than a queue would deliver it. A date here would be a guess in the clothes of a commitment, and the people who planned around it would be the ones it let down.
The mobile app exists for scanning, receiving, counting, custody handovers and signature capture — work done standing up, often with no signal, on a device the organisation bought. In the markets we serve, that device is overwhelmingly an Android one, frequently a rugged handheld, and often a shared device rather than a personal phone.
The work an executive does on a phone — approving, reviewing, checking a figure — is the work the web app already does well on iOS. So the platform gap and the capability gap point in nearly opposite directions, which is why the ordering was what it was.
A cross-platform codebase makes it tempting to ship both at sixty per cent. We took the view that a field team with an app that does not reliably work offline is worse off than a field team that knows it needs paper, so Android was taken to a real release — on Google Play, with the sideloaded channel retired — before the second platform was opened.
That decision is why the remaining iOS work is a build list you can read in five items rather than a project we would have to start from the beginning.
If your field teams are on iPhones, that is genuinely useful for us to know and it is the single thing most likely to move this up the list. The form below is the input to that decision rather than a marketing capture.
One email the day a build is ready for you to install, and mobile-operations updates in the meantime. Your address is used for that and nothing else.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
If your field teams are on iPhones, tell us — it is the single input most likely to move this up the list, and a committed customer with a real deployment date changes the arithmetic entirely.
The same codebase, shipped and live on Google Play.
What working with no signal actually means, and what happens to the queue when it returns.
Scanning into a browser session from a paired device — the nearest thing to a scanner without the app.
Proof of handover at the bay, and where it works today.
Server-side, so it already covers the iPhone signing in through Safari.
The platform-independent surface every client is built against, the iOS one included.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
