You sent a tester an iOS install link — or someone sent you one — and tapping it does nothing. No alert, no spinner, no install sheet. The page just sits there, and there is no error to search for.
The silence is the clue. An itms-services:// link fails quietly in a short, well-defined list of ways, and the list below is ranked by how often each one turns out to be the culprit. The first cause alone accounts for most of the taps that go nowhere — we know, because every BetaDrop install page has code watching for it.
First: what a working tap looks like
In Safari on an iPhone, tapping a valid install link produces a sheet: “example.com would like to install ‘MyApp’”. Tap Install and the app icon lands on the Home Screen with a progress ring. If you got that far — sheet and icon — the link itself is fine, and your problem is cause 5 at the bottom of this page. If the tap produced nothing, start at cause 1 and work down.
1. The link was opened inside an in-app browser
Slack, Instagram, Gmail, LinkedIn, Discord — when you tap a link inside these apps, it opens in the app’s own embedded browser, not in Safari. That webview renders web pages fine, but it does not handle the itms-services URL scheme, so the tap is swallowed without a message. Nothing is broken; the component your link landed in simply has no idea what to do with an iOS install request, and ignoring unknown schemes is what webviews do.
This is first on the list from direct experience: every BetaDrop install page checks whether it is being rendered by an iOS in-app browser and, when it is, shows an “open this in Safari” prompt before the tester ever taps into the void. That detection exists because the in-app browser is, by a wide margin, the most common reason an OTA install link “doesn’t work”.
The fix: get the link into Safari yourself. Long-press the link and copy it (or use the app’s own menu item — Slack, Gmail and LinkedIn all have an “open in browser” option behind the share or … button), open Safari, paste, go. One thing no install page can do is jump to Safari for you: iOS gives web pages no way to force that switch, which is why even a page that detects the problem can only ask.
2. The manifest URL is not HTTPS, or not reachable
An install link is really two URLs. The visible one uses the itms-services scheme and carries the second in its url parameter:
itms-services://?action=download-manifest&url=https://example.com/manifest.plistiOS fetches that manifest URL, and it insists on HTTPS with a certificate it trusts. A plain http:// manifest, an expired or self-signed certificate, a server that is down, or a link that has expired all kill the install — sometimes with a terse “Cannot connect to example.com” alert, sometimes with nothing at all. The same rule applies one level deeper: the .ipa URL inside the manifest must also be HTTPS. A perfectly secure manifest pointing at an insecure package fails just the same.
The test: take the manifest URL out of the link and paste it into Safari on its own. If XML does not come back, iOS never had a chance, and the fix is on the server, not the phone.
3. The manifest.plist is malformed
If the manifest downloads but iOS cannot parse it, the tap dies as silently as in cause 1. The file is ordinary XML, which means one unclosed tag or a stray character from a copy-paste is enough. This is the smallest manifest iOS will accept:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>https://example.com/builds/MyApp.ipa</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>com.example.myapp</string>
<key>bundle-version</key>
<string>1.0.0</string>
<key>kind</key>
<string>software</string>
<key>title</key>
<string>MyApp</string>
</dict>
</dict>
</array>
</dict>
</plist>Two of those keys punish mistakes differently. Broken XML or a missing software-package entry kills the tap outright. A manifest that parses but carries the wrong bundle-identifier — it must match the app’s CFBundleIdentifier exactly — lets the whole download run and then fails at the last moment with “Unable to Download App”. bundle-version should match the build’s version, and kind is always software. For the full setup around this file, including icons and MIME types, see how OTA IPA installs work.
4. The device blocks profile-based installs
Some iPhones are configured to refuse apps from outside the App Store no matter how correct the link is. Screen Time does it via Content & Privacy Restrictions (common on family-managed devices), and corporate MDM does it by policy on supervised phones. On a locked-down device the tap can be silently ignored, which looks identical to causes 1–3 from the outside.
The test: open the same link on a second, unmanaged iPhone. If it installs there, the link is healthy and the restriction is on the device — which means the fix is a Screen Time passcode or a conversation with whoever administers the phone, not anything in your manifest.
5. The build has a signing problem — which fails after the tap
Signing is the cause people suspect first, and it is last on this list for a reason: a signature problem does not make the tap do nothing. The install sheet appears, the icon appears, the download runs — and the failure shows up afterward, as “Unable to Install” on an ad-hoc build whose provisioning profile is missing the device, as the Untrusted Enterprise Developer alert on an enterprise build, or as the integrity error at launch. If your symptom is one of those, the link has done its job and you want the fix for “app integrity could not be verified” instead. A genuinely dead tap is a delivery problem — one of the four causes above.
When the link was never going to work
Two cases need no debugging. An itms-services link does nothing on Android, Windows, or macOS by design — only iOS and iPadOS understand the scheme, so an Android tester needs an APK link, not a fixed manifest. And if every tester you have is happy on TestFlight, you may not need itms-services at all: App Store Connect handles distribution with no manifest to break and no hosting to certify, at the price of Apple’s beta review and the TestFlight app itself. OTA links earn their keep when you need installs immediately, outside that pipeline — ad-hoc and enterprise builds, delivered straight from a URL.
Or skip the manifest entirely
Causes 2 and 3 are hosting problems, and hosting is automatable. Upload a signed .ipa to BetaDrop and it generates the manifest for you, hosts both the manifest and the package on HTTPS, and hands back an install link and QR code — with the in-app-browser detection from cause 1 built into every install page, so your testers get pointed to Safari instead of tapping into silence. Causes 4 and 5 stay yours: device policy and Apple signing live outside any hosting service, and nothing can host its way around them.
Frequently Asked Questions
Why is there no error message when an itms-services link fails?
Because the failure usually happens before iOS is involved at all. An in-app browser that does not recognize the itms-services scheme simply ignores the tap, so nothing runs and nothing can complain. iOS itself only starts showing alerts once it has accepted the link and begun fetching the manifest, which means a completely silent tap almost always points at the link never reaching iOS in the first place.
Do itms-services links work in Chrome or Firefox on iPhone?
Not reliably. Safari handles the scheme consistently on every iOS version; third-party browsers vary by app and by release, with some handing the link through to iOS and others dropping it without a message. If a link does nothing in Chrome or Firefox on an iPhone, paste it into Safari before assuming anything is wrong with the link itself.
Why does an itms-services link do nothing on Android or a desktop?
The itms-services scheme is Apple's over-the-air install protocol, and only iOS and iPadOS register a handler for it. Android, Windows, and macOS have nothing to pass the link to, so the tap or click is ignored by design. An Android tester needs an APK link instead, and someone at a desktop can read the page hosting the link but cannot install from it.
Does every URL in the chain really have to be HTTPS?
Yes. iOS requires HTTPS with a certificate it trusts both for the manifest URL inside the itms-services link and for the software-package URL inside the manifest that points at the .ipa file. Plain HTTP or a self-signed certificate at either step stops the install, and there is no device setting that overrides this.
The install sheet appeared but the app never finished — same problem?
No. Once the install prompt has appeared, the itms-services link and the manifest have done their entire job. A download that starts and then fails, an icon stuck on Loading, or an integrity alert at first launch all point at the build itself — its signing and provisioning — not at the link that delivered it.
In short
A silent itms-services link is almost never a signing problem. Check the browser first (copy the link into Safari), then the manifest URL (paste it into Safari — HTTPS, reachable, valid XML), then the keys inside it, then the device’s restrictions. And if you would rather not host manifests at all, upload the IPA and send the link BetaDrop gives you back.
