An enterprise mobile app is one built for your own staff, not for the public. The five essential features it needs are seldom in the first draft of the specification, because none of them shows up on a mock-up of the screens. They are sign-in through the company’s own accounts, an API shared with your other systems, permissions enforced on the server, the ability to work without a signal, and a controlled way to distribute and update the app. Each one is cheap to plan for and expensive to add afterwards.
1. Sign-in with the company account
Staff should sign in to the app with the account they already use for email. This is single sign-on, usually shortened to SSO. In a business that runs Microsoft 365, the account lives in Microsoft Entra ID, the service that was called Azure Active Directory until Microsoft renamed it in 2023.
There are practical reasons for insisting on it:
- Nobody has another password to forget, and the app does not have to store passwords at all.
- Multi-factor authentication, where a code or an approval on the phone is needed as well as the password, applies automatically if the company already enforces it.
- When someone leaves and their account is disabled, their access to the app ends with it.
- The company can set conditions, for example that only phones with a screen lock and a current operating system may connect.
Three details belong in the specification. Name the directory the app must sign in against. State how quickly a signed-in phone loses access once the account is disabled, because an app can otherwise stay signed in for days. Decide what happens for people with no company account, such as agency staff and subcontractors.
2. An API shared with your other systems
An API (application programming interface) is the set of defined requests through which one program asks another for data or asks it to do something. The mobile app should hold no business rules of its own. It should ask an API, and the office system and any customer portal should ask the same one.
The reason is consistency. Suppose a job cannot be closed without a customer signature. If that rule lives in the API, it applies whether the job is closed from a phone, the office or a nightly import. If it lives in the app, the office system will sooner or later disagree with it.
A shared API also protects the investment. The app can be rewritten, or a second one added for a different group of staff, without touching the system behind it.
If the existing system has no API, building one is the first piece of work and frequently the largest. It is the same job as any other system integration, and it should be investigated before anyone quotes for the app. Ask too how the API will cope with old versions of the app, since not every phone updates on the same day.
3. Permissions enforced on the server
Different people need different things. An engineer sees their own jobs. A supervisor sees the team’s. Payroll details are for HR alone. Showing each role only what is relevant also makes the app quicker to use.
The point that gets missed is where the check happens. Hiding a button in the app is not security. An app on a phone can be taken apart and its requests imitated, so the server has to check every request against what that user is allowed to see and do. The test is simple to describe: sign in as an engineer and ask for another engineer’s jobs by a route the screens do not offer. Make that test part of acceptance.
The same thinking applies to what is kept on the phone. Store as little as the task needs, encrypt it, and make sure it can be removed remotely if the device is lost.
4. Working without a signal
Enterprise apps are used in plant rooms, basements, lifts and lay-bys. An app that shows a spinner whenever the connection drops will be replaced by paper.
Offline working means the app keeps the data for today’s work on the phone, lets the user carry on, and sends the changes when a connection returns. Three decisions need making, and they are business decisions:
- Which tasks must work offline. Viewing assigned jobs and recording work usually must. Searching ten years of history usually need not.
- What happens on a conflict. If the office reassigns a job while the engineer is completing it offline, one of them has to win, or someone has to be asked.
- What the user is told. People need to see plainly what is saved on the phone and still waiting to be sent.
Offline support is often one of the largest factors in the cost of an enterprise app, so settle it before the price is agreed. It is one of the problems discussed in the challenges of the mobile workplace.
5. Controlled distribution, updates and support
An internal app should not sit in the public app stores for anyone to download. Both platforms provide a private route. On Apple devices, a custom app is offered privately to a named organisation through Apple Business, the service that replaced Apple Business Manager in April 2026, and is installed through mobile device management or redemption codes. On Android, a private app in managed Google Play is visible only to the organisations it has been restricted to.
Whichever route is used, the Apple and Google developer accounts should be in your company’s name, not your supplier’s. Otherwise a change of supplier depends on the old one agreeing to hand the app over.
Getting the app onto phones is the start. Plan for what follows:
- Annual operating system releases. Apple and Google each release a major new version of their phone operating system every year, and the app has to be tested against it, ideally before staff phones update. This is the main reason an app needs a maintenance arrangement from the day it goes live.
- A minimum version. The app should check on start-up whether it is too old to be allowed to connect, so that a version with a fault can be retired.
- Diagnostics. Crash reports, and a way for a user to report a problem that attaches the app version and device model automatically, save a great deal of guessing.
- Someone to ask. Decide who staff contact when the app misbehaves, and how that person passes a real fault on to the developers.
Before you approve the specification
One decision sits underneath all five: whether to build a native app for each platform, a single app with a cross-platform framework such as .NET MAUI, React Native or Flutter, or a web application that needs no installation at all. Many internal tools need nothing more than the last of these, and we compare the options in native app or web app.
Whichever you choose, put these questions to whoever is quoting:
- Which directory does the app sign in against, and how soon does a disabled account lose access?
- Is there one API, and does the office system use it too?
- Where is each permission checked, and how will that be tested?
- Which tasks work offline, and what is the rule when two changes conflict?
- Whose name are the Apple and Google accounts in, and who tests the app against each year’s new operating systems?
A supplier with clear answers has thought about how the app will live after launch. Vague answers to the first three are a reason to pause before signing.