Getting internal apps onto employee phones — without the App Store

The app your nurses need was never meant for the public

A hospital wants to put a patient-intake and care-coordination app in the hands of its nursing staff. A regional bank wants a compliance checklist and audit-capture tool on the phones its branch advisors already carry. A logistics operator wants proof-of-delivery and dispatch on the devices its drivers use every shift. None of these are consumer products. None of them should ever be searchable by a stranger. And in the first two cases, the data flowing through the app is exactly the kind of data a regulator has opinions about.

And yet the default path every engineering team reaches for to get a native app onto a phone is the same one built for a completely different job: submit to the public App Store, wait for review, ship an update, wait for review again. That pipeline was designed to protect consumers browsing a public catalog of apps from strangers. It was not designed for an operational tool that a hospital, a bank, or a fleet operator needs to push to its own employees, on its own schedule, without ever appearing in a catalog at all.

Apple has long understood that this is a distinct problem — its managed and enterprise distribution model exists precisely because internal, employee-only software shouldn't have to travel through the same review and identity pipeline as a consumer app. But knowing the right category of solution exists is only the first step. Getting there in practice — without a mobile team, an EAS subscription, and a third-party mobile backend sitting between your data and your own network — is the harder problem. This post is about why the usual answers fall short for regulated organizations, and the delivery layer we built instead.

Why the usual answers fail

Public App Store submission. Every update — a bug fix, a new form field, a routing change — goes through a review queue you don't control and can't expedite. Worse, a public listing means a public identity: your internal dispatch tool now has an app name, an icon, and a listing page that anyone with the App Store installed can find, even if they can't log in. For a hospital or a bank, an internal tool having any public-facing footprint is itself a disclosure most compliance teams would rather avoid answering questions about.

A consumer mobile-backend-as-a-service. Plenty of teams route around the App Store review problem by building on a third-party mobile backend — push notifications, over-the-air updates, device management — hosted by yet another vendor. That solves the update-cadence problem, but it does so by inserting a new company into the data path. Every OTA bundle, every device check-in, every piece of telemetry now flows through infrastructure you don't operate and (in a regulated environment) can't always get a signed BAA or equivalent agreement for. You've traded "app review is slow" for "our patient data touches a vendor no one on the compliance team has vetted."

Apple's enterprise developer program. This is closer to the right shape — it exists explicitly for internal distribution — but it comes with its own constraints: program enrollment and renewal, a distribution model built around your organization directly signing and pushing binaries, and an assumption that you're running the mobile toolchain yourself. For a team that has already invested in a no-code platform for its operational workflows, standing up a second, parallel mobile engineering practice just to get builds signed and distributed is a real cost — and it still doesn't solve where the backend lives.

None of these are bad tools. They're just built for a different problem than "get an internal, compliance-sensitive app onto an employee fleet, updated on our schedule, without a new vendor in the data path."

The choice: FastYoke Substrate

We build FastYoke on the premise that the workflow logic, the forms, and the data governing your business should run where you say they run — in our cloud, in your own data center, or fully air-gapped. Mobile delivery was the one piece of that story we hadn't closed, so we're building FastYoke Substrate: the native mobile delivery layer for FastYoke apps. Substrate is in early access now, with general availability targeted for Q1 2027 — the design below is what it's built to do, and early-access conversations are open today for teams that want in ahead of GA.

The shape of it is straightforward. You build the app the same way you build any other FastYoke app — the same no-code App Builder, the same schema-driven forms and workflows — and Substrate is designed to compile that into a native Android and iOS build. From there, distribution is built to happen two ways, neither of which touches a public catalog:

• Through your existing MDM. If your organization already manages devices with Microsoft Intune or Jamf, Substrate hands you a build your MDM can push directly — enrollment, certificates, and compliance profiles stay exactly where they are today, under your device-management team's control. Substrate doesn't try to replace your MDM; it just gives it something private to distribute.
• Through a token-gated install link, for teams without an existing EMM, so a fleet of field devices can enroll without a public listing ever existing.

Once an app is installed, updates are designed to ship as signed, over-the-air bundles — content-addressed and scoped to your tenant — that a device picks up silently on its next launch. No review round-trip, and critically, no fleet fragmentation where half your drivers are three versions behind because they didn't tap "update" in a public store.

And because Substrate is built on the same platform as FastYoke On-Prem, the whole thing is designed to work air-gapped. The OTA bundles, the build artifacts, the app itself — all of it can be served from hardware inside your own network, with nothing reaching out to a cloud endpoint at all.

Why this is the compliance path, not just the convenient one

The reason this matters for regulated organizations specifically is that every piece of the usual alternative — public listing, third-party mobile backend, review cycle — is a new place PHI, financial records, or operational data could touch infrastructure outside your control. Substrate is designed to remove each of those one at a time:

• No public catalog identity. The app never has a listing, an icon in a public store, or a name a stranger could search for. There is nothing to disclose because there is nothing published.
• No third-party mobile backend in the data path. Distribution and OTA updates are designed to run on FastYoke's infrastructure — the same infrastructure already running your workflows — or on your own hardware if you're On-Prem. There isn't meant to be a second vendor's servers to add to a data-flow diagram.
• Silent, fleet-wide updates. A compliance-relevant form change or a security fix is meant to reach every enrolled device the same way, on the same day, without depending on individual employees tapping "update" in a store they may never open.
• An air-gap path that actually air-gaps. For deployments where PHI or operational data must never leave the network — the extreme end of healthcare and critical-infrastructure requirements — Substrate paired with On-Prem is built so the build artifacts and the update bundles never leave the building.

None of this requires exotic engineering on your part. It requires that the platform building your workflows also be the platform delivering the app that runs them — so there's one trust boundary to reason about, not three.

The payoff

Put together, what an operations or compliance lead gets from this, once Substrate is in place, is:

• A real air-gap option, for the subset of deployments where that's not a nice-to-have but a requirement.
• No store review and no public app identity to explain to an auditor or a security team.
• Fleet-wide control — updates land everywhere, on your timeline, not whenever individual employees get around to it.
• Data and build sovereignty — the same principle that governs where your workflow logic runs governs where your mobile builds and updates live.

That last point is the throughline across everything we've been building under this banner. We've written before about how FastYoke keeps your tenant data recoverable and independently verifiable even if our infrastructure disappeared, and about why tenant logic runs in a sandbox that makes the same promise for compute as Substrate is designed to make for distribution. Substrate is the mobile chapter of that same story: your app, on your employees' phones, without a third party standing between them.

Substrate is in early access today, with general availability targeted for Q1 2027. If you're evaluating how to get an internal app onto a regulated device fleet, see what FastYoke Substrate covers — including current early-access status, the On-Prem air-gap path, and where it fits alongside an existing MDM deployment.