Where enterprise apps break

What is enterprise mobile app development?

Enterprise mobile app development is the practice of building mobile software for a known, managed population of users (employees, contractors, field crews, partners) rather than for an open consumer market. The visible interface is the smallest part of the job. What decides the outcome is device management, corporate identity, offline behaviour, and integration with systems of record that were never designed to be read on a phone in a warehouse.

That changes the definition of success. A consumer app is judged on installs and retention. An enterprise app is judged on whether a task that used to need a laptop and a desk now finishes on a handset in the field, and whether the data arriving in the back office is cleaner than it was before. Optimise for the consumer metrics and you get a well-designed app that quietly loses to a paper form.

The enterprise app features that decide adoption are rarely the ones on a vendor checklist. They are single sign-on, offline capture, role-scoped data, audit logging, a remote kill switch, and a configuration channel that lets IT change the server URL without shipping a release. Everything else is negotiable. If you are scoping a build, our mobile app development practice treats those six as the baseline, not the roadmap.

Does enterprise app security start with MDM?

Mobile device management (MDM) is software that lets IT enforce security policies, push configuration, and remotely lock or wipe company-managed and BYOD devices that touch enterprise data. It is necessary. It is not a strategy. MDM tells you a device is enrolled and compliant; it tells you very little about what a user does inside a third-party app on that device.

The pressure is real and it is rising. In 2025, 85% of organisations reported mobile device attacks were increasing¹, and 75% increased mobile security spending over the previous year¹. The largest single worry was not malware. It was data leaving through generative AI: 64% named employees entering sensitive information into genAI tools as their top mobile risk¹, at a point where 93% of employees were already using genAI tools on their devices for daily work¹.

That gap is the honest case for MDM: enrolment correlates with the discipline to audit, because the same teams that manage devices tend to manage policy. It is not evidence that enrolment alone contains the risk. Treat MDM as one layer in a stack:

• Identity. Single sign-on with multi-factor authentication and conditional access, so a compromised device cannot silently become a compromised session.
• Device. MDM or mobile application management for policy, configuration push, jailbreak and root detection, and remote wipe scoped to the work container on BYOD hardware.
• App. Certificate pinning, encrypted local storage, screenshot suppression on sensitive screens, and no credentials or tokens written to shared storage.
• Data. Role-scoped queries at the API rather than filtering in the client, field-level encryption for regulated fields, and logging on every export path.

On BYOD, assume you do not control the device. You control the app and the identity, so the container has to be self-sufficient. And given how widely genAI is already in use on personal handsets, plan for it: give people a logged, permission-scoped assistant inside the app rather than a blocking policy they will route around.

How do offline first apps actually work?

An offline-first app is one where core functions (data entry, viewing, the key workflow) work fully with no network, using local storage and a sync engine that reconciles once connectivity returns. The mistake is treating this as a feature toggle added late. It is a data model decision, and it is made at the schema layer before a screen is designed.

Three questions settle the architecture:

1. Which entities are writable offline? Inspection records, time entries and photo capture usually are. Payments, approvals and anything requiring a real-time balance usually are not. Say so explicitly, per entity, and make the app show the difference rather than failing silently.
2. How are conflicts resolved? Last write wins is cheap and loses data. Field-level merge is better when two users edit different attributes of the same record. Server-authoritative rejection with a rework queue is the right answer for regulated records, because a human resolves the clash instead of an algorithm guessing.
3. How does the sync queue behave badly? Idempotency keys so a retried upload does not duplicate a record. Ordering guarantees for dependent writes. Schema versioning so a handset that has been offline for three weeks can still post against a server that has moved on.

Test against the real failure mode, which is not airplane mode. It is one bar of signal, a captive portal in a hotel lobby, a lift shaft, and a device that has been out of coverage for a full shift. Field teams do not experience connectivity as on or off; they experience it as unreliable, which is much harder to code against.

What changes when enterprise apps carry AI agents?

Gartner expects up to 40% of enterprise applications to feature task-specific AI agents by the end of 2026, up from fewer than 5% in 2025², and projects that agentic AI could account for roughly 30% of enterprise application software revenue by 2035, more than $450 billion, against 2% in 2025².

For a mobile build, that forecast turns into three concrete requirements. First, an agent must inherit the signed-in user’s entitlements, not a service account’s, or it becomes a privilege escalation path with a chat box on it. Second, every agent action needs the same audit record as a human action, including the prompt and the data it touched. That is the same auditing discipline that separates the mature organisations in the Verizon data from the rest. Third, agents and offline-first fight each other: a model call needs a network. Queue the user’s intent, not a fabricated answer, and show honestly that the step is pending.

Native, cross-platform or PWA?

The framework debate absorbs more attention than it deserves. Among developers of all experience levels in 2024, Flutter was used by 9.4% and React Native by 8.4%³, close enough that hiring is not the differentiator vendors imply. Both ship credible enterprise apps. The dominant cost driver sits somewhere else entirely: integration with single sign-on, legacy ERP and CRM APIs, and the middleware that translates between them. That work is framework-agnostic, and it is where budgets go.

A workable default: cross-platform for form-driven internal apps with two target platforms; native when you depend heavily on device capability (Bluetooth peripherals, camera pipelines, sustained background location, deep MDM app-configuration plumbing); a progressive web app for read-mostly internal tools where no store review and instant updates outweigh weaker background sync and the loss of managed-catalogue distribution.

Whichever you choose, the admin console, reporting and configuration surface will be a browser application. Scope it as such from the start, alongside the handset work, rather than discovering it in month four. Our view on that split sits in the web development practice.

Why do enterprise mobile apps fail to get adopted?

Because they are offered rather than required. An app positioned as a convenience competes with an existing habit that already works well enough, and habits win.

An enterprise app that competes with a paper form usually loses to the paper form.

What holds instead:

• Replace a mandatory workflow, and retire the alternative on a fixed date. If the paper form still exists in week six, the app has already lost.
• Pilot with the hardest crew, not the friendliest. The team with the worst connectivity, the oldest devices and the most scepticism will surface every defect that matters. A willing pilot group tells you nothing.
• Measure task completion and time on task, not installs. Installs are guaranteed when IT pushes the app. They mean nothing.
• Get first run under two minutes. Single sign-on, no manual server configuration, environment pushed by MDM. Every field a user types on first launch costs you people.
• Staff the first two weeks with a named human. Not a ticket queue. Early friction that goes unanswered becomes a permanent workaround.

Design for the actual conditions too: gloves, direct sunlight, one-handed use, a cracked screen, and a user who is standing up. Those constraints change type sizes, tap targets and colour contrast more than any brand guideline will.

What drives cost and timeline in enterprise mobile app development?

Five variables move the number more than anything else: how many systems of record the app touches, how much of the workflow must survive offline, whether the data is regulated, how varied the device fleet is, and how many countries are in scope. A single-integration, online-only app for one country is a different order of work from a four-integration, offline-first, multi-country rollout, even when the screens look identical.

Multi-country adds specific items rather than a general multiplier. Data residency may force regional backends. MDM policy differs per region, so one enrolment profile rarely fits. Right-to-left languages change layout, not just strings. Device fleets are older in some markets, which sets your minimum OS version. And in several jurisdictions, features that monitor location or productivity require employee representative consultation before they ship, which is a calendar item, not an engineering one.

Release logistics are usually faster than teams fear and less forgiving than they assume. Around 90% of App Store submissions are reviewed in under 24 hours⁵, but roughly 22% of 2025 submissions were rejected⁴. Enterprise apps trip on a predictable set of causes: a sign-in wall with no reviewer demo account, missing justification for background location, and unclear handling of the data the app collects. Prepare those three before the first submission and the review stops being a schedule risk.

Sequence the build so the risky parts come first: identity and one real integration in the first increment, offline sync in the second, the remaining integrations after. That ordering is the same discipline described in our note on the software development life cycle, applied to a delivery where the hardest problems are invisible in a design file. A sync model and an MDM policy are both cheaper to argue about on a whiteboard than to unpick in production, which is why our engineering work puts both in the first increment.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.