On this page
In short
- A progressive web app is often enough for lookups, approvals and forms. Native or React Native earns its place with offline work, heavy camera or device use, or dependable notifications.
- Decide early whether the app runs on company-owned devices, personal phones or both. That choice drives device management, security and distribution.
- Sign people in through your identity provider, keep as little company data on the phone as the job allows, and make it removable when someone leaves.
- Internal apps don't have to be public in the app stores, but private distribution depends on how devices are managed. The developer accounts should belong to your company.
Start with the job, the people and the phones
The technology choice follows from a few plain facts about how the app will be used. Get these down before comparing options:
- The tasks. Looking things up and approving requests is very different from filling in long inspections with photos in a basement.
- Connectivity. Will people have signal wherever they use it, or do they need to keep working without it?
- The devices. Company-issued phones, personal phones, or a mix? iPhone, Android or both? Tablets?
- Device features. Camera, barcode scanning, location, Bluetooth accessories, notifications.
- How often. An app used all day by a few dozen people and an app opened monthly by hundreds call for different trade-offs.
If the app is for operators or crews on shared, rugged or company-managed devices, our guide to mobile apps for plant-floor and field teams goes deeper on offline sync, shared devices and scanners. This guide focuses on apps for staff more broadly, including on their own phones.
PWA, native or cross-platform
Ways to build a mobile app for employees
Progressive web app (PWA)
- Strengths
- One codebase with your web app; no app store; updates reach everyone on the next load
- Watch for
- Install is a manual step on iPhone; offline storage, background work and device access are more limited, especially on iOS
Native iOS (Swift, SwiftUI)
- Strengths
- Best integration with iPhone and iPad: camera, notifications, secure storage, background tasks
- Watch for
- iOS only; Android users need a separate app
Native Android (Kotlin)
- Strengths
- Full access to Android devices and their features
- Watch for
- Android only; a second codebase if you also support iPhone
Cross-platform (React Native)
- Strengths
- One codebase for iOS and Android, with native access to device features
- Watch for
- Some device SDKs need native modules; still two store submissions
| Option | Strengths | Watch for |
|---|---|---|
| Progressive web app (PWA) | One codebase with your web app; no app store; updates reach everyone on the next load | Install is a manual step on iPhone; offline storage, background work and device access are more limited, especially on iOS |
| Native iOS (Swift, SwiftUI) | Best integration with iPhone and iPad: camera, notifications, secure storage, background tasks | iOS only; Android users need a separate app |
| Native Android (Kotlin) | Full access to Android devices and their features | Android only; a second codebase if you also support iPhone |
| Cross-platform (React Native) | One codebase for iOS and Android, with native access to device features | Some device SDKs need native modules; still two store submissions |
A PWA is a good default when the app is mostly forms, approvals and lookups for people who are usually online. Apple added web push notifications for web apps added to the Home Screen in iOS 16.4, which closed one of the biggest gaps, but web app capabilities on iPhone still trail native apps and have changed between iOS releases, so test on the iOS versions your staff actually run. Choose native or React Native when people must work offline for long stretches, when the camera or accessories are central to the job, or when notifications need to be dependable across both platforms.
Company-owned devices or personal phones
This is often the decision with the most consequences, and it's as much an HR and policy question as a technical one.
How device ownership changes the plan
Management
- Company-owned devices
- Enrolled in mobile device management (MDM), such as Microsoft Intune or Jamf
- Personal phones (BYOD)
- Staff often won't accept full management of their own phone; lighter options are needed
Separating company data
- Company-owned devices
- The whole device is the company's
- Personal phones (BYOD)
- Android work profiles, Apple's user enrollment, or app-level protection policies keep company data apart
Installing the app
- Company-owned devices
- Pushed silently by the MDM
- Personal phones (BYOD)
- Installed by the user from a store, a private link or the browser
When someone leaves
- Company-owned devices
- Wipe or reassign the device
- Personal phones (BYOD)
- Remove company data and access, never the person's own data
Support
- Company-owned devices
- One or two known models
- Personal phones (BYOD)
- Many models and OS versions, some out of date
| Question | Company-owned devices | Personal phones (BYOD) |
|---|---|---|
| Management | Enrolled in mobile device management (MDM), such as Microsoft Intune or Jamf | Staff often won't accept full management of their own phone; lighter options are needed |
| Separating company data | The whole device is the company's | Android work profiles, Apple's user enrollment, or app-level protection policies keep company data apart |
| Installing the app | Pushed silently by the MDM | Installed by the user from a store, a private link or the browser |
| When someone leaves | Wipe or reassign the device | Remove company data and access, never the person's own data |
| Support | One or two known models | Many models and OS versions, some out of date |
For personal phones, Microsoft Intune's app protection policies can protect company data inside approved apps without enrolling the device, and conditional access can require those apps before company data is reached. A custom app generally has to integrate Microsoft's Intune App SDK (or, in some cases, be processed with the Intune App Wrapping Tool) to support those policies, which is work to plan into the build. Other MDM vendors have their own equivalents. Whatever you use, check with HR how personal-phone use, reimbursement and after-hours notifications fit your policies, particularly for hourly staff, and tell employees plainly what the company can and can't see on their phone.
Sign-in and data on the phone
- Single sign-on. Sign people in through the identity provider you already run, such as Microsoft Entra ID or Okta, using OIDC with the authorization code flow and PKCE in the system browser, as the OAuth guidance for native apps (RFC 8252) recommends. Libraries such as Microsoft's MSAL handle most of this. Our guide to SSO and least privilege for internal apps covers the server side.
- No passwords in the app. Store tokens in the platform's secure storage (the iOS Keychain or Android Keystore), and allow a biometric unlock to resume a session instead of asking for credentials every time.
- Keep less on the device. Cache only what the job needs offline, and clear it on sign-out. Data that never reaches the phone can't leak from it.
- Revocable access. Short-lived access tokens and a server that checks every request mean disabling someone in the identity provider cuts off the app too, even on a phone you don't manage.
- Careful notifications. Lock-screen notifications are visible to anyone holding the phone. Say that something needs attention, not the sensitive details.
Getting the app onto phones
An internal app doesn't need to be publicly listed, but every route onto an iPhone or Android phone has conditions. Apple and Google adjust these programs over time, so confirm the current terms before planning around one.
Common distribution routes for internal mobile apps
Web link (PWA)
- How it works
- People open a URL and add it to the Home Screen
- Fits when
- The app works well as a web app; no store review
Apple custom apps
- How it works
- Distributed privately through Apple Business Manager, installed by your MDM or with redemption codes
- Fits when
- iPhones are managed, or you can hand out codes to a known group
Apple unlisted app
- How it works
- A normal App Store app that isn't searchable, reached by a direct link
- Fits when
- Staff use personal iPhones and you want a simple install
Managed Google Play private app
- How it works
- Published only to your organization and installed through the MDM
- Fits when
- Android devices are fully managed or have a work profile
Public store listing
- How it works
- Listed in the App Store and Google Play; sign-in restricts use to staff
- Fits when
- Simplest for personal phones when the listing itself isn't sensitive
Test channels (TestFlight, Play testing tracks)
- How it works
- Limited testers, builds that expire
- Fits when
- Pilots and testing, not permanent distribution
| Route | How it works | Fits when |
|---|---|---|
| Web link (PWA) | People open a URL and add it to the Home Screen | The app works well as a web app; no store review |
| Apple custom apps | Distributed privately through Apple Business Manager, installed by your MDM or with redemption codes | iPhones are managed, or you can hand out codes to a known group |
| Apple unlisted app | A normal App Store app that isn't searchable, reached by a direct link | Staff use personal iPhones and you want a simple install |
| Managed Google Play private app | Published only to your organization and installed through the MDM | Android devices are fully managed or have a work profile |
| Public store listing | Listed in the App Store and Google Play; sign-in restricts use to staff | Simplest for personal phones when the listing itself isn't sensitive |
| Test channels (TestFlight, Play testing tracks) | Limited testers, builds that expire | Pilots and testing, not permanent distribution |
Apple custom and unlisted apps still go through App Review, so plan for review time and give reviewers a demo account. Apple's Developer Enterprise Program for in-house distribution has its own eligibility rules and obligations; check whether it applies before assuming you need it. Whichever route you take, enroll the Apple Developer and Google Play accounts in your company's name (Apple requires a D-U-N-S number for organizations), not in a developer's or contractor's personal account. For an app your customers download, our guide to publishing a company app on the App Store and Google Play covers accounts, disclosures and review.
Updates and upkeep
- Operating system updates. Apple and Google release major OS versions yearly, and Google Play raises the Android API level most apps must target each year. Budget for testing and updating the app each year.
- Minimum versions. Build in a way for the server to tell outdated app versions to update, so an old version on someone's phone can't keep calling an API that has moved on.
- Crash and usage reporting. Add crash reporting from the first release, so problems on a specific phone model show up before users give up on the app.
- A pilot first. Start with one team, collect feedback for a few weeks, then widen.
Questions to settle before you build
Take this to the business, IT and HR
- What tasks will people do in the app, where, and how often?
- Do they need to work without a connection, and for how long?
- Will the app run on company-owned devices, personal phones or both, and which platforms?
- Which MDM or app protection approach applies, and does the app need Intune App SDK or similar support?
- Which identity provider will people sign in with, and how is access removed when someone leaves?
- What company data will be stored on the phone, and how is it cleared?
- How will the app be distributed, and whose name are the developer accounts in?
- Who approves personal-phone use and after-hours notifications from an HR point of view?
- Who owns the app after launch, including yearly OS updates?
Planning an app for your staff?
Tell us who will use it, on which devices, and what they need to do. On a scoping call we'll talk through the kind of app that fits, how it's secured and distributed, and what a fixed-price build would cover.
Not ready to talk yet? Draft a project brief first
Our experience includes native iOS apps in Swift, SwiftUI and UIKit, cross-platform apps in React Native, push notification systems, and OAuth and OIDC authentication flows. See mobile app development for what we build, and web application development for the APIs and web apps a mobile app depends on.
Sources
- Web Push for Web Apps on iOS and iPadOS (WebKit)
- App protection policies overview and preparing line-of-business apps for app protection policies (Microsoft)
- User Enrollment and device management (Apple) and work profiles (Android Developers)
- RFC 8252: OAuth 2.0 for Native Apps (IETF) and MSAL overview (Microsoft)
- Apple: distributing apps for business, unlisted app distribution, Apple Developer Enterprise Program and enrollment
- Publish private apps from managed Google Play and target API level requirements (Google)
See it applied
- Illustrative sample. Not client work.See a sample scope for an internal tool →An invented request and approval portal that replaces a spreadsheet and email, on an existing SQL Server database with the company's existing single sign-on.
- Illustrative sample. Not client work.See a sample handover package →The handover index for an invented plant-floor dashboard: repositories, infrastructure as code, the pipeline, runbooks, a data dictionary, the credential handover list, alerts, known limitations and sign-off.