Enterprise Mobile Apps for Your Workforce

A Different Product

Almost Every Consumer App Assumption Is Wrong Here

The mechanics of building are the same. Nearly everything around them is not.

Consumer App

You Have to Earn Every Open

Found through store search, judged on screenshots
Success is retention, and a deleted app is gone forever
Runs on whatever handset the user happens to own
One person, one account, one phone

Workforce App

They Have to Use It. That Is the Risk.

Pushed to the device; the first screen is a sign-in, not a sales pitch
Success is task completion and fewer phone calls to the office
Runs on a known fleet, sometimes a five-year-old rugged handheld
One device, three shifts, and nobody signs out properly

The thing to take from that: a workforce app cannot be judged by whether people like it, because they will use it regardless. It is judged by whether the job gets done faster than the paper form it replaced. If it does not, you will hear about it from a supervisor rather than from a review page, and usually not until the rollout is already halfway done.

Distribution

Getting the App Onto the Phones Without a Public Listing

Four routes, and the right one depends on who owns the devices rather than on what the app does.

Private Distribution Through the Platforms

Apple has business programmes that let an app be made available to a named organisation instead of the public store
Google has private apps published into managed Google Play and restricted to your enterprise
The app never appears in public search and cannot be installed by someone outside the organisation
You still get proper signing, proper updates and platform-level distribution rather than a file on a share drive

Pushed Silently by Device Management

On a company-owned device the app is installed without anyone touching it, before the device is handed over
Updates arrive the same way, so you are not chasing three hundred people to press update
Combined with managed configuration, a new starter gets a working app with the right server already set
This is the route we recommend wherever the fleet is managed, because it removes the whole class of setup errors

Personal Devices, Work Container

Company data lives in a managed space that can be removed on its own, leaving personal photos and messages alone
What you can enforce is narrower: no full-device wipe, no background location outside working hours, no arguing about passcodes
The app has to behave correctly when it is inside that container and when the container is removed mid-session
Cheaper in hardware, more expensive in policy conversations. Decide it before the build, not during rollout

Why Not Just Send People a File

It works for five devices and collapses at fifty, because nothing tracks who has which version
Certificates and provisioning expire, and when they do every installed copy stops opening on the same day
There is no update mechanism, so your fleet fragments within one release cycle
Any app carrying real business data deserves a distribution route with revocation in it

Platform programme names, eligibility rules and enrolment steps change periodically. We confirm the current route with your IT team at kickoff rather than assuming last year’s process still applies.

Managed work handsets being configured for a field team rollout

MDM and Configuration

Nobody Should Ever Type a Server Address

Managed app configuration is the quiet feature that decides how much your service desk hears from the field. Your device management platform sends a small dictionary of settings into the app, and the app reads them on launch instead of asking a human.

We define those keys during the build and hand your IT team a documented schema, so provisioning a replacement handset for someone whose device went into a puddle takes minutes and involves no phone call.

Environment, tenant, site or depot identifier pushed rather than typed
Optional modules switched on per group, so the warehouse and the drivers get different apps from one build
Per-app VPN or certificate delivery where the backend sits inside your network
Managed data boundaries, so a selective wipe removes work data and nothing else
A configuration test group so IT can prove a change before it reaches the fleet

Identity

Sign-On That Uses the Directory You Already Have

Nobody wants another username. More importantly, nobody wants an account list inside an app that HR cannot see.

Your Identity Provider, Not Ours

The app signs in through your existing corporate identity system using the standard protocols rather than storing passwords itself. Multi-factor, conditional access and device compliance rules you already enforce apply to the app automatically, without us reimplementing any of it.

Groups Become Roles

What someone can see and do comes from their directory group, so a promotion or a transfer changes the app without anybody editing a table. Permissions are checked on the server as well as hidden in the interface, because a hidden button is not a security control.

Leavers Lose Access Immediately

Disabling the directory account stops the app at the next token refresh, and for sensitive data that refresh window is short and backed by server-side revocation. No app-specific offboarding step that somebody forgets on a Friday.

Sign-In That Survives a Shift

A driver does not want to authenticate at every stop, and a warehouse handheld cannot do a full sign-in flow with no signal. Sessions are designed around the shift, with a short local unlock and a token that refreshes when connectivity comes back, not one that expires at the worst moment.

Shared Device Sign-In

Where one handset passes between three shifts, sign-in has to be fast enough that people actually do it — a badge tap, a short code, a scanned identity card. Sign-out has to be automatic at the end of a shift, because relying on people to press a button means the night shift works as the day shift.

Attribution That Holds Up

If an audit needs to show who confirmed a delivery or approved a count, the record has to name a person and not a device. That requirement changes the sign-in design, so we settle it at scoping rather than discovering it during an audit.

Offline First

The Signal Will Drop. The Job Still Has to Finish.

Basements, lift shafts, cold stores, rural routes, steel-framed buildings and customer sites with guest Wi-Fi that asks you to accept terms. Field work is offline work with occasional connectivity, not the other way round.

The Device Holds the Truth

The app reads from a local database and writes to it first, so every screen opens instantly regardless of connectivity. Syncing happens in the background and is never in the way of a person trying to finish a task. The status is visible — what is saved, what is queued, when it last synced — because an invisible queue is one people do not trust.

Queued Work Cannot Duplicate

Every queued action carries its own identifier, so a retry after a dropped connection updates the same record rather than creating a second one. This is the single most common defect in offline apps built without it, and it surfaces as phantom duplicate jobs weeks after launch.

Conflicts Get a Rule Per Data Type

Two people edit the same record from different places. For a status field, the later change usually wins. For a running count, the changes are merged rather than replaced. For a signed document or a photo, nothing is overwritten at all and a supervisor is asked. We decide this per data type during design instead of applying one rule and losing somebody’s work.

Attachments Are the Hard Part

A dozen photos taken in a basement are megabytes sitting on a device with no signal. They are compressed on capture, queued separately from the fast data, uploaded in chunks that survive an interrupted connection, and continue in the background when the app is not open. Otherwise the queue never clears and the device fills up.

End of Shift Is a Design Problem

Somebody hands the handset back with forty queued actions and a flat battery. The app has to make that visible before they leave, sync on the charging cradle, and survive being force-closed halfway through. Otherwise the work reappears as a discrepancy the following week.

Clocks and Time Zones Lie

Device clocks drift, get set manually, and cross time zones mid-route. Anything that depends on ordering uses server time and records both, so a delivery does not appear to have happened before it was dispatched.

The server side of this — delta sync, idempotent writes, conflict handling and the push channel — is covered in more detail on mobile backend and APIs.

Hardware

Rugged Handhelds, Shared Tablets, Kiosks and Scanners

Enterprise fleets contain devices that would never appear in a consumer test matrix, and they behave differently enough to break an app built only on a modern phone.

Rugged and Shared Devices

Older processors and smaller screens than anything on a desk, so the interface has to be tested there and not only in a simulator
Gloved hands and cold stores mean bigger targets and physical keys where they exist
Screens used in direct sunlight need contrast well above the usual minimum
Battery swaps, charging cradles and devices that are never fully powered down for weeks
A device passed between shifts must hold no personal state from the last user

Kiosk and Single-App Mode

The device boots into one app and cannot leave it, reach settings, or install anything
Configured through your management platform on company-owned hardware, not by the app itself
The app has to assume there is no browser, no email client and no way out for a normal user
A supervisor exit needs a credential, and an unattended kiosk needs a session timeout back to a clean state
Crash recovery matters more than usual: if the app dies, the device has to return to the app, not to a blank screen

Barcode and QR Scanning

A dedicated imager with a hardware trigger is faster and less tiring than a camera, and staff scanning all day can tell the difference
Some handhelds deliver a scan as keyboard input, others through a vendor interface — the app supports whichever the fleet uses
Continuous and batch scanning need an interface designed for a rhythm, with the confirmation visible without looking closely
Validation has to work offline, so the codes and rules needed to check a scan are already on the device
Damaged, curved and poorly printed labels are the normal case, not the exception

NFC and Tags

Tapping an asset tag, a badge or a location marker is faster than typing an identifier and far less error-prone
Reading works widely; writing tags and more advanced card interaction vary by platform and device
Badge-tap sign-in on a shared device is one of the few things that makes proper per-person attribution realistic
Always paired with a manual fallback, because tags get damaged and readers fail

Security Review

The List Your IT and Security Team Will Send Us

We would rather answer these at scoping than in a questionnaire two weeks before go-live.

Device and App Attestation

Both platforms provide a mechanism for the server to check that a request came from a genuine, unmodified copy of your app on a genuine device. Used where it matters, it stops a scripted client talking to your API pretending to be the app.

Certificate Pinning

The app accepts only certificates you expect, which defeats interception on a hostile network. It also breaks the app the day a certificate rotates unexpectedly, so it needs a backup pin and a documented renewal process. We implement it where the risk justifies that operational cost and say so plainly when it does not.

Storage on the Device

Tokens and credentials go into the platform keystore, not into ordinary app settings. The local database holding work data is encrypted, and anything genuinely sensitive is kept out of the device entirely rather than protected there.

Remote Wipe and Revocation

Work data removable on demand through your management platform, sessions revocable server-side, and a device that has been reported lost blocked from syncing again. Selective on personal devices, full on company-owned ones.

Screens, Copying and Screenshots

Where regulated data is shown, screenshots and screen recording can be blocked and content masked when the app is backgrounded, so it does not appear in the task switcher. Worth doing selectively; applying it everywhere mostly annoys staff.

Audit Logging

Who did what, on which device, at what time, recorded server-side rather than only on the handset. Designed around what your auditors actually ask for, which is usually narrower and more specific than a general log everything instruction.

Root and jailbreak detection is on that list too, and we will be honest about it: it raises the effort for a casual attacker and is defeated by a determined one. It belongs in a layered approach alongside server-side checks, not as the thing you rely on. More on the wider picture on app security and privacy.

Rollout

These Projects Are Won or Lost on the Shop Floor

The code is rarely what kills an internal app. It is a rollout that surprises people who were already busy.

01

One Site First

A single depot, ward, store or crew, chosen because they are representative rather than because they are enthusiastic. Real work, real devices, real network, for a fixed period with a named person collecting problems.

02

Super-Users, Not a Memo

Two or three people per site who saw it first and can answer the obvious questions without anyone ringing IT. This is the cheapest support channel you will ever have and the one most often skipped.

03

Fix the First-Week List Fast

The complaints in week one are mostly small, specific and correct. Turning them round quickly is what converts a sceptical shift into people who defend the app. Leaving them for the next quarter is what creates the workaround spreadsheet.

04

Retire the Old Way Properly

Running the paper process alongside forever guarantees half the data is missing. A short overlap with a stated end date, then the old route is genuinely closed and everyone knows the date in advance.

Training for a Captive Audience Is Different

You cannot rely on people exploring the app out of curiosity, and a long onboarding tour gets skipped by someone standing in the rain. What works is a single printed card at the workstation, a short first-run walkthrough of the one main task, and in-app help that is available at the point of confusion rather than in a manual nobody opens. We build the app so the main path needs no explanation at all, which is a better outcome than training people to tolerate a confusing one.

FAQ

Questions From IT and Operations

Does an internal app have to go through the public App Store and Play Store?

No. Both platforms have routes for distributing an app privately to an organisation, so the listing never appears in public search and only people in your company can install it. On Apple that runs through the business programmes and the app is redeemed by your organisation rather than downloaded by the public. On Android the equivalent is a private app published into managed Google Play and made available only to your enterprise. In both cases the app can also be pushed silently by your device management platform so nobody has to be talked through an install. We set up whichever route fits how your devices are owned and managed.

What is managed app configuration and why does it matter?

It is a set of settings your device management platform sends into the app, so the app already knows things like the server address, the tenant or site identifier, which optional modules are enabled and which sign-in method to use. Without it, someone on a loading bay has to type a server URL correctly on a small keyboard, and roughly one in ten will not. We define the configuration keys during the build and document them for your IT team, which means a new device can be handed over already pointing at the right environment with nothing to set up by hand.

Our staff use their own phones. Does that change the build?

It changes what you can reasonably ask for. On a personal device you cannot wipe the whole phone, you cannot demand a device passcode policy without pushback, and you should not be collecting location outside working hours. The usual answer is a work container or managed application model, where company data lives in a space that can be removed on its own and personal data is never touched. We design the app so the sensitive data stays inside that boundary, so a departure means removing the work data rather than negotiating with someone about their own phone.

Half the warehouse has no signal. Can the app still work there?

Yes, and for field and warehouse work it is the default rather than an extra. The app keeps its own database on the device and reads from that, so screens open instantly whether or not there is a connection. Work done offline is queued and sent when signal returns, with each action carrying an identifier so a retry cannot duplicate it. What needs deciding up front is the conflict rule: what happens when two people change the same record from different places. We agree that per data type during design, because the honest answer differs between a stock count, a signature and a free-text note.

Can a device be locked so it only runs our app?

Yes. Both platforms support a kiosk or single-app mode where the device boots into one application and the user cannot leave it, reach settings, or install anything else. It is configured through your device management platform on company-owned hardware, and it is the right answer for shared tablets on a counter, handhelds on a shop floor, and anything mounted in a vehicle or a fixed stand. The app itself has to be built for it too: no dependence on an external browser, no assumption that a user can reach system settings, and a way for a supervisor to get out with a credential.

How do we cut off access the day somebody leaves?

Access comes from your existing directory rather than from a user list inside the app, so disabling the account in one place stops the app at the next token refresh. For higher-risk cases that is backed by shorter session lifetimes and server-side revocation, so a device that is already signed in loses access in minutes rather than at the end of a long-lived session. On a managed device the work data can also be removed remotely without touching anything personal. Which combination you need depends on what the app can see, and we size it against that rather than applying the strictest option to everything.

Do you work with our device management platform, or do we need a specific one?

We work with what you already run. The app-side work is the same regardless of vendor because the platforms expose a standard mechanism for pushing configuration into an application, and the management products all build on it. What we need from your IT team is the configuration schema signed off, a test group of devices enrolled the way real ones will be, and somebody who can push a build to that group. Where you have no management platform yet, we describe the options honestly rather than recommending whichever one we saw last.

All Mobile Services Pricing

Tell Us What Your Team Is Doing on Paper

Send the process, the device fleet and the systems it has to talk to. You get a scope, a rollout plan and a cost range within two business days.

Request Free Quote Call +1 341 208 1344

Apps for the People Who Work for You, Not the People Who Buy From You