Mobile apps for plant-floor and field teams: offline work, shared devices and MDM

What's different about apps for operations teams

• Connectivity is uneven. Metal buildings, freezers, basements, tanks and remote sites all create dead zones. The app has to keep working through them.
• Devices are shared. A tablet on a line or a handheld in a charging rack may be used by several people in a day.
• The hardware matters. Rugged Android handhelds with built-in scanners, tablets in cases, and phones used with gloves or in bright light.
• IT manages the device. Apps are installed, configured and updated through mobile device management, not the public app stores.
• The data feeds other systems. Inspections, readings, work orders and counts end up in databases, the MES or reports, and have to be trustworthy when they arrive.

If the app shows live machine data, our guide to getting plant data across the OT/IT boundary covers reading it without touching the control network; control actions stay in the control system. For office, sales and service staff, often on their own phones, see a mobile app for your staff.

Browser, native or cross-platform

A browser app is often right for screens used on fixed, well-connected devices. A native or React Native app usually earns its place when people must keep working offline, when the app relies on scanners or the camera, or when it needs push notifications and background sync. Many rugged handhelds run Android, and their scanners are commonly reached either as keyboard input or through the manufacturer's SDK or intent-based services, so confirm the device model early.

Designing for offline work

Offline-first means the app reads from and writes to a store on the device, and synchronizes with the server whenever it can. The person using it never waits for the network to save their work.

• Client-generated IDs. Each record gets a unique ID on the device, so a change sent twice after a dropped connection is applied once.
• An outbox, in order. Pending changes are queued and sent in order, retried with back-off, and kept until the server confirms them.
• Visible sync status. People can see what's waiting to send and when the device last synchronized. Silent failures are how data goes missing.
• Reference data downloaded ahead. Lists of assets, lines, parts and checklists are cached with a version, so forms work offline and the server knows which version was used.
• Server-side validation too. The device checks entries as they're made, and the server checks them again, because the rules may have changed while the device was offline.
• Two time stamps. Record when the event happened on the device and when the server received it. Device clocks drift, so treat the device time as reported, not authoritative.
• Decide what must be online. Some actions, such as approvals or anything that depends on another person's latest change, may be better blocked offline with a clear message.

Conflict rules for each kind of record

When two people change the same thing while one of them is offline, the app needs a rule. Write the rules down per record type with the people who own the process, rather than letting the last sync win by accident.

Shared devices and sign-in

A device signed in with one person's account all shift makes every record anonymous. The common pattern is a limited identity for the device or station, with each person identifying themselves for their session, by badge scan or short PIN, backed by your company identity provider. Our guide to SSO and least privilege for internal apps covers the station-identity design.

• Platform shared-device features. Microsoft Entra ID offers a shared device mode for iOS and Android apps built to support it (on iOS it also needs the Microsoft Enterprise SSO plug-in deployed through your MDM), and Apple supports Shared iPad for organizations using Apple Business Manager. Check which fits your devices and identity provider before designing sign-in.
• Local data follows the person. Cached records and the outbox are tied to the user who created them, and anything sensitive is cleared or locked when they sign out.
• Unsent work survives a handover. If someone signs out with changes still in the outbox, they should still sync under that person's name, not be lost or reassigned.
• Short sessions. Sign out after inactivity, and let the next person switch in quickly.

Device management and distribution

Company-owned devices are usually managed with a mobile device management (MDM) tool such as Microsoft Intune, Jamf or similar. Plan the app's distribution and configuration with whoever runs it.

• Avoid public store listings for internal apps. Private distribution keeps the app off the public stores. Apple's Developer Enterprise Program is only for cases the standard program can't cover, and requires 100 or more employees and Apple's verification, so Apple Business Manager is the usual route for companies that can use it.
• A minimum supported version. The server can tell an outdated app to update before it syncs, so old versions with old rules don't keep sending data.
• Staged rollouts. Update one line, one crew or one site first, then everyone.
• Crash and sync reporting. Collect crash reports and sync errors centrally, so problems are found before someone reports missing data.

Designing for gloves, glare and scanners

Many of these apps replace paper forms and clipboards.

Testing and rollout

• Test where it's used. Walk the app through the dead zones, the freezer, the far end of the yard. Airplane mode on a desk is a start, not a test.
• Test long offline periods. A device offline for a full shift, or a weekend, then brought back with a large outbox.
• Test the awkward cases. Two people editing the same work order, a device with the wrong clock, an app update while changes are still waiting to send.
• Pilot with one team. One line or one crew first, with a quick way to report problems, before rolling out wider.
• Write acceptance criteria for offline behavior. For example: "A record created offline appears on the server within 2 minutes of the device reconnecting, exactly once."

Questions to settle before you build

Our experience includes native iOS apps in Swift, SwiftUI and UIKit, cross-platform apps in React Native, push notification systems, and web and mobile HMIs and dashboards for production data. See mobile app development for what we build, and the manufacturing page for what we build for plants.

Sources

• Shared device mode overview (Microsoft)
• Shared iPad overview (Apple)
• Distributing apps for business and Apple Developer Enterprise Program (Apple)
• Publish private apps from managed Google Play and lock task mode (Google)