“Our contractors need to do this from their phones.” Soon after that request, someone asks, “Do our contractors need an app?” This guide works from the tasks to the technology. We build React web apps and native iOS and Android apps, so we have no format to push; the answer depends on your tasks, your signal and who your crews work for.
The short answer: start from what crews do on their phones
Before anyone compares technologies, write down every task a crew member or contractor does away from a desk. For each one, note four things:
- Where it happens: a truck with good signal, a basement or plant floor with none, a rural site where signal comes and goes.
- What the phone has to do: show and submit a form, open the camera, read a barcode or NFC tag, know where it is, or alert someone.
- How often: twice a week, or forty times a shift.
- Who does it: employees on company phones, or contractors on their own phones who also work for other companies.
Then mark each task web-friendly or native-leaning using the sections below. If every task is web-friendly, you have your answer. If one or two lean native, you may need native only for that part. If the core daily task leans native, such as all-day scanning or work where there’s no signal, a native app is the safer choice.
Example (hypothetical)
A commercial HVAC service company lists eleven phone tasks for its technicians and subcontracted installers, from viewing today’s jobs and completing service checklists to capturing signatures, logging parts and taking before-and-after photos. Ten are forms, photos and status screens. The eleventh, scanning equipment serial numbers, leans native, but it happens a few times a day, so scanning through the phone camera in a web app is acceptable. Not client data.
What a mobile-friendly web app handles well for field crews
A mobile-friendly web app is a website designed for phones first: short forms, big buttons, screens sized for a thumb, running on the same system your office uses on a desktop. It covers a lot of everyday field service work:
- Forms and checklists. Service reports, inspections, sign-up and completion forms. Fields open the right keyboard, and drafts can save as people go.
- Photos and file uploads. An upload field can open the phone’s camera directly, using the capture attribute from the W3C’s HTML Media Capture Recommendation.
- Assignments and status. Today’s jobs, open work to apply for, where each assignment stands and what’s waiting on the crew.
- Location when it matters. A web page can read the phone’s location to stamp a check-in. The W3C Geolocation API requires the user’s express permission and sends position updates only to pages that are open and visible.
- Sign-offs and updates. A customer signature on screen, an approval with a name and timestamp, a new phone number.
Why operations teams like the web option
- Onboarding is a link in a text message or email. No app store, no install, no storage warnings.
- Everyone gets the new version when you release it. Nobody is stuck on last spring’s app.
- The phone screens and the office’s desktop screens are one system, so a fix happens once.
The limit is signal. A standard web app needs a connection for most actions, and large photo uploads over a weak connection need careful handling: compression, visible progress, automatic retries and a clear message when something didn’t go through.
When a native iOS or Android app earns its cost
A native app is installed from the App Store or Google Play and runs directly on the phone. It costs more to build and run: two platforms, an app store review for each release, and older versions in the field that your system still has to support. It earns that cost when the work needs one of the following.
Offline work in dead zones
Basements, mechanical rooms, rural sites, the far end of a large plant. Web apps can work offline to a degree: a service worker can cache screens and step in when there’s no network (MDN: Service Worker API). But browser storage is “best-effort” by default and can be cleared under storage pressure, and Safari deletes script-created data for a site with no user interaction in the last seven days of browser use when cross-site tracking prevention is on (MDN: storage quotas and eviction criteria).
If crews can go hours or days without signal and their unsent work has to survive, native storage and a sync queue you control are the safer design.
Background location tracking
A web page gets location only while it’s open and visible. Recording a route while the phone sits in a pocket, or reacting when someone arrives at a site, takes a native app, and even then Apple asks developers to consider carefully whether they need background updates at all (Apple: handling location updates in the background). With contractors, check with your legal team before tracking anyone’s location.
Barcodes, NFC tags and other hardware
An occasional scan through the phone camera is workable in a web app. All-day scanning, NFC tags and Bluetooth devices are a different story. Web NFC works in Chrome on Android but not on iPhone (Chrome for Developers: Web NFC; MDN: Web NFC API), and MDN marks both the Barcode Detection API and the Web Bluetooth API as limited availability, because they don’t work in some of the most widely used browsers. If a scanner or sensor maker provides only an iOS or Android SDK, that settles it.
Alerts that have to reach people
On iPhone, a web app can send push notifications only after the person adds it to their Home Screen, which Apple has supported since iOS and iPadOS 16.4, and the permission request has to come from a tap, such as on a subscribe button (WebKit: Web Push for web apps on iOS and iPadOS). If a missed alert means a missed job, native notifications don’t depend on that extra step. Text messages are another route that needs no app at all.
Heavy camera workflows
Five photos per job is a web task. Fifty photos per job from a site with weak signal is where native helps: the app can keep photos on the phone and finish uploading when signal returns, while the crew moves on to the next job. The web’s tool for deferring work until there’s a connection, the Background Synchronization API, is marked limited availability by MDN, so you can’t count on it across your crews’ phones.
One native task doesn’t make the whole system native
If only one workflow needs a scanner or long offline stretches, a small native app for that workflow, next to a web app for everything else, can be simpler to build and change than putting the entire system in an app.
Not sure which of your tasks lean native?
Send us your task list, or a login to the system your crews use now. Your first call is with an engineer who builds both web and native apps.
Contractors aren’t employees: installs, app stores and device policies
When your field team is employees on company-managed phones, IT can push an app to every device and keep it updated. Installing a native app is an IT task, not a favor you’re asking.
Contractor networks are different. Contractors use their own phones, may work for several companies and may not accept enrolling their phones in your device management. Every install step is a point where a new contractor gives up or calls your office.
Getting a native app to contractors without a public listing
If you do go native, there are ways to distribute an app other than a public store listing, each with conditions:
- Apple unlisted distribution. The app is on the App Store but “discoverable only with a direct link,” and Apple lists partners, franchisees and business affiliates among the audiences it suits. You still submit the app to App Review (Apple: unlisted app distribution).
- Apple custom apps. Visible only to organizations you name in Apple Business or Apple School Manager, then distributed through device management or redemption codes (Apple: custom apps).
- Private apps on managed Google Play. Restricted to the organizations you choose and distributed through your device management (EMM) console (Google: private apps on managed Google Play).
Managing only a work area on a personal phone is possible. Android work profiles let IT control company apps and data while people keep using their personal apps (Android Developers: work profiles), and Apple’s account-driven User Enrollment is designed for devices the user, not the organization, owns (Apple Platform Deployment: User Enrollment). Both still ask an independent contractor to let your IT team onto their phone.
Middle paths: progressive web apps and wrapped web apps
Progressive web apps (PWAs)
A progressive web app is a web app that can be added to the phone’s Home Screen and opens like an app. On iPhone, people add it from Safari’s Share menu with Add to Home Screen. With a web app manifest, the site then opens like any other app instead of in the browser, and it can ask permission to send push notifications (WebKit). Add a service worker and it can cache screens and hold simple submissions until the app is next open with signal.
Compared with a native app, a PWA keeps the web’s advantages for field workers: no app store, one codebase, updates when you release them. It doesn’t remove the limits above. And the Home Screen step is one more thing to explain to contractors. Some will never do it, so a PWA has to work well as a plain web page too.
Wrapped web apps
A wrapped web app puts your web screens inside a native shell, so it gets a store listing and can use some native features. On Android, a Trusted Web Activity opens your PWA from an Android app, with the app and site verified as coming from the same developer (Chrome for Developers: Trusted Web Activity). For iPhone, Apple’s guideline 4.2 says an app should include features that “elevate it beyond a repackaged website” (App Store Review Guidelines), so a thin wrapper around your site risks rejection.
A wrapper makes sense when you need a store listing or one or two native features and want to keep most screens on the web. It still brings store releases and installs, so it doesn’t solve contractor onboarding.
Making an existing desktop system work on phones first
Often the real request isn’t for something new. Crews already use a web system built for desktops, and on a phone it means tiny links, wide tables and forms that scroll sideways. Before choosing web or native for a new build, find out whether the system you have can be made to work on phones.
A mobile-friendly retrofit redesigns the screens people use on the go for phones, one page at a time, so crews see improvements without waiting for a big launch day. Run your key pages through our free mobile-friendly test, which can check pages behind a login too, and see how we make existing web apps mobile-friendly.
That’s how we’re modernizing Amusement Advantage’s existing contractor portal, page by page, for a network of 60,000+ contractors, so contractors can register, find and apply for assignments, check status, update info and upload photos from their phones. Each page is tested on a staging copy before production, and the work continues as ongoing maintenance. Mobile-responsive pages now cover about 90% of the contractor workflow, and there have been 20–30% fewer support requests for login assistance, opportunity search/updates and assignment/project status. Read the Amusement Advantage case study.
Planning screens for a contractor portal? Our guide to contractor portal features that cut support requests lists them in the order contractors use them.
Decision table: web app, PWA or native app for your field team
Find each task your crews do, then read across.
Then weigh the rows by frequency. A task crews do every hour should decide the build; a task they do once a month shouldn’t. If the result is a mix, consider a web app for most of the work plus a native piece for the one workflow that needs it. Our other guides cover portals, modernization and maintenance.