Home / Insights / Why Building Internal iOS Apps Is Harder Than It Looks

Why Building Internal iOS Apps Is Harder Than It Looks

If you’ve ever asked a developer for “a quick app for the team’s iPhones”, you may have been surprised by the answer. Building internal iOS apps is rarely held up by the code. It’s held up by how Apple controls who can install software on an iPhone or iPad, and how. That’s a deliberate design choice with real security benefits, but it does shape what smaller organisations can realistically build, and it’s one reason some end up running their in-house apps on Android instead.

This article sets out how distribution works on each platform, using the published programme rules, so you can make a balanced decision rather than a rushed one.

What you can do without a paid Apple Developer account

Anyone with an Apple Account can download Xcode and build an iOS app for free. The catch is what happens next. Without a paid membership, Xcode uses what Apple calls a “Personal Team”, and Apple’s own documentation sets tight limits on it:

• Up to 3 registered devices, and those registrations expire after 7 days.
• Up to 3 apps installed per device.
• Provisioning profiles expire 7 days after they’re issued, so the app has to be rebuilt and reinstalled each week.

That’s fine for a developer testing on their own phone. It is not a way to roll an app out to a team, let alone to clients.

What the paid programme unlocks, and what it asks of you

To share an app properly you need the Apple Developer Program, which Apple lists at US$99 a year (charged in local currency where available). Organisations enrol as a legal entity rather than as an individual, which involves Apple verifying the organisation before membership is approved.

Membership opens up several routes, each with its own trade-offs:

• App Store. Public distribution, subject to App Review against Apple’s guidelines. Not a natural fit for a tool only your staff or one client should use.
• TestFlight. Built for beta testing rather than long-term use, so it suits trials and pilots rather than day-to-day operations.
• Ad hoc distribution. Installs on devices you register individually, with a cap on registered devices per membership year. Workable for a small, stable group of devices, awkward as people join, leave or replace phones.
• Custom apps via Apple Business Manager. Apps can be distributed privately to the specific organisations you choose, usually alongside a mobile device management (MDM) platform. These still go through App Review, so there’s a submission and approval step on every release.

There is also the Apple Developer Enterprise Program, listed at US$299 a year, for distributing proprietary apps directly to employees. Apple restricts eligibility to organisations that meet its criteria and have an internal use case the standard routes can’t meet, and it reviews applications. It isn’t a shortcut for small businesses, and it can’t be used to distribute apps to customers.

None of this is unreasonable from Apple’s point of view: review and signing are part of why the iPhone has a strong security reputation. But for an organisation that wants a simple app for a field team, a stocktake, or a client portal, the cost, the paperwork, the review cycle and the device admin all add up.

Why client apps are harder still

Internal apps at least sit on devices you can manage. Client-facing apps are another step up. If the app isn’t suitable for the public App Store, custom app distribution means each client organisation needs to be set up to receive it, typically through its own Apple Business Manager. Many smaller clients simply don’t have that in place. So the “easy” options narrow quickly to publishing in the App Store, with review and public listing, or not building a native iOS app at all.

How Android distribution differs

Android takes a more open approach, and that’s why it often ends up being the platform for in-house tools:

• Registering for Google Play has a one-off fee rather than an annual one.
• Through Android Enterprise and managed Google Play, an organisation can publish private apps to its own managed devices via its MDM, without a public listing.
• Apps can also be installed outside an app store (“sideloading”), once the user or the device policy allows installs from unknown sources.

That flexibility is genuinely useful, but it moves more responsibility onto the organisation. When apps can come from anywhere, the job of making sure only trusted, up-to-date software reaches staff devices falls on your MDM policies, your app signing and your update process. A well-managed Android fleet, with sideloading locked down and apps delivered through managed Google Play, can be run securely. An unmanaged one, where staff are told to “allow unknown sources” to install a work app, carries more risk.

It’s also worth knowing the Android picture is changing. Google has introduced developer verification for apps on certified Android devices. It took effect on 30 September 2026 in Brazil, Indonesia, Singapore and Thailand for apps installed from participating stores, and Google says it plans to expand it globally in 2027. Organisations building their own Android apps should keep an eye on what that will mean for their signing and registration.

So which should you choose?

Neither platform is simply “secure” or “insecure”. They make different trade-offs between control and flexibility:

• iOS centralises trust with Apple. That gives you strong guarantees, at the cost of fees, enrolment, review and device limits.
• Android lets you hold more of that control yourself. That means lower barriers, but your own device management has to do more of the work.

Before commissioning an internal or client app, it’s worth asking a few practical questions:

1. Which devices do staff and clients actually use, and do you manage them?
2. Do you have, or need, an MDM platform for either Apple or Android devices?
3. Would a secure web app or progressive web app meet the need without app store distribution at all?
4. Who will own the developer account, the signing keys and the release process long term?
5. If you go with Android, how will you stop unmanaged sideloading on work devices?

Getting those answers first will save a lot of rework later. If you’re weighing up options, our guide on how to prepare for an IT project is a good starting point, and our IT consultancy and managed IT services teams can help you plan device management and app distribution that fits your organisation. Get in touch for a no-pressure conversation.

Sources: Apple Developer Program and account help pages (developer.apple.com/programs, developer.apple.com/help/account); Android developer verification (developer.android.com/developer-verification).