You tapped a beta build to open it and iOS put a small alert in the way instead:
Unable to Verify App
An internet connection is required to verify the app.
The alert is telling you the truth, which is the first useful thing to know about it. The app is installed and nothing about the file is corrupt. iOS is trying to phone Apple to check the certificate that signed the build, and that call is not going through.
Five things stop that call, ranked below by how often each one turns out to be the culprit. Each has something to check before you change anything.
Why iOS needs a network to launch an app that is already on the phone
An App Store app carries Apple’s own signature behind it, so nothing is re-checked when you tap the icon. A build that arrived any other way is. Apple’s rule is specific: developer accounts created after June 6, 2021 must have their development- and ad hoc-signed apps check in with a service Apple calls PPQ the first time the app launches, and the device has to reach https://ppq.apple.com to do it. If that connection fails, the app may not launch.
Two terms the rest of the page leans on. Ad hoc distribution is Apple’s route for handing a signed build straight to named devices, and a provisioning profile is the file inside that build stating which app, which certificate and which devices it may run on.
The check is not strictly one-and-done either. Apple documents the verification as happening at first launch, and its guidance on extended offline validity refers to apps needing to run offline for more than 30 days after that — which implies roughly a 30-day offline window rather than an indefinite pass. That is why a build that opened fine every day last week can throw this alert on a Monday when nothing about the app has changed.
1. The phone had no working internet the moment you tapped Open
Working is doing real work in that sentence. Full Wi-Fi bars mean the phone joined a network, not that the network passes traffic. A hotel portal you have not signed into yet, or a guest SSID that quietly dropped you an hour ago, looks connected on screen and answers nothing.
Check it by opening Safari and loading a page you have not visited today, so you get a real request rather than a cached one. If that hangs, the launch check hung for the same reason.
Switch to cellular data and reopen the app. If you have already been sent to Settings, go to General → VPN & Device Management and find the developer entry: when the check never completed it reads Not Verified, with a Verify App button beside it. Tap that once you are online and the build launches. No reinstall.
2. A VPN, a firewall or a DNS blocker is eating the request
This one catches whole teams at once, because the network is fine for everything except the thing you need. Corporate Wi-Fi filters outbound hosts. An always-on VPN pushed by an MDM sends the traffic somewhere that never answers. Apple documents the requirement plainly: if you are behind a firewall, it has to be configured to allow connections to https://ppq.apple.com.
Test it from the phone, not from your laptop. Open https://ppq.apple.com in Safari on the device that is failing. You are not looking for a useful page, only for a response of any kind. A timeout or a certificate warning on a network that is otherwise healthy is your answer.
Turn the VPN off, drop any DNS-filtering profile, or move to cellular, then relaunch. If you are asking a network admin to open the host, warn them that allowing the one name is not always sufficient. Administrators on Apple’s developer forums report the trust flow touching more than that single address, so a rule scoped to exactly one host can still fail.
3. The signing certificate is revoked or expired
Causes 1 and 2 are the check never completing. This one is the check completing and coming back negative. Apple revokes enterprise certificates when in-house apps get distributed outside the company that holds them, and every certificate and profile expires on its own clock regardless of behavior.
You can separate this from a network problem in about a minute: try the same build on cellular, on a second device, on a different network. A dead certificate fails everywhere, identically, for every tester. A blocked network fails only on that network.
Nothing on the device fixes it. The build has to be re-signed with a live certificate and redistributed, which is the developer’s job, not the tester’s. If the same build is also producing a trust prompt in Settings, the Untrusted Enterprise Developer fix covers the approval half of the same certificate story.
4. This device is not in the provisioning profile
Being straight about the ranking: a missing device usually fails earlier, during install, as “integrity could not be verified”. If you got as far as an icon and a launch attempt, this is the least likely of the five. It still turns up on re-signed builds, where the profile inside the package names a different set of devices than the last one did.
A UDID is the identifier that names one specific iPhone, and an ad hoc profile lists them one by one. Two tools settle it. Run the .mobileprovision through the provisioning profile decoder to read out its device list and expiry date, then open the UDID checker in Safari on the failing iPhone to get that device’s identifier. If it is not in the list, the developer adds it, re-signs, and sends a fresh link.
5. The clock is wrong
Last because it is rare, and included because when it is the cause nothing else you try will work. A certificate is valid between two timestamps. A device whose date has drifted outside that window reads a perfectly good certificate as not yet valid or long dead.
Open Settings → General → Date & Time and switch Set Automatically on. If it was already on and the date is still wrong, the time zone service needs a network too, so fix cause 1 first.
One thing not to do: winding the clock backwards to run an expired build is a trick that circulates on forums, and it half-works for about an hour before HTTPS starts failing across every other app on the phone. Get the build re-signed instead.
Which “cannot verify” error do you actually have?
Four different iOS failures get reported as “it will not verify”, and only the one on this page is about connectivity: it appears when you launch the app, it names an internet connection, and it clears the moment the device can reach Apple, while the other three break at a different point in the install and take completely different fixes. So the timing is what tells them apart.
| What you see | When | What fixes it |
|---|---|---|
| “Unable to Verify App”, internet connection required | At launch, first time or on a later re-check. | Get the device to Apple: cellular data, or unblock ppq.apple.com. Causes 1 and 2 above. |
| “Untrusted Enterprise Developer” | At launch of an enterprise-signed build. | Approve the signer once in Settings. See the Untrusted Enterprise Developer guide. |
| “Integrity could not be verified” | During install, before any icon settles. | Usually a device missing from the ad hoc profile. The developer adds it and re-signs. |
| The install link does nothing at all | On tap, before an install starts. | Usually an in-app browser swallowing the tap. See itms-services links that do nothing. |
If you are the one shipping the build
The uncomfortable part first: you cannot host your way around this. The PPQ check runs between the tester’s phone and Apple, and no distribution service sits on that path or can suppress it. Any tool claiming to remove the verification step is describing something else.
What you can control is smaller and still worth doing. Say in the same message as the link that the first launch needs a network, because testers will otherwise assume your build is broken. Watch certificate and profile expiry dates instead of learning them from a support thread. And if a tester really is stuck behind a locked-down network, teams created after June 2021 can issue an offline provisioning profile that runs for a week without contacting the service.
The delivery half is where a tool helps. Upload a signed .ipa to BetaDrop and you get back an OTA install link, meaning the tester taps a URL and iOS installs the app over the air through itms-services rather than through the App Store. Free accounts take builds up to 500 MB, links default to 3 days, and testers never make an account. It changes nothing about the launch check. It removes the manifest and the HTTPS host between your build and the person testing it. See how OTA IPA installs work for the mechanics underneath.
Android has no equivalent of any of this. An APK is checked against its own signature at install time, on the device, with no launch-time call to a signing authority at all, so an Android tester either has the app or is looking at a plain install failure. If you ship both, upload the APK the same way and expect a quieter inbox from that half of your testers.
Frequently Asked Questions
Why did the app work yesterday and show Unable to Verify App today?
Because the pass you got at first launch does not last forever. Apple documents the check at first launch and describes extended offline validity in terms of apps running offline for more than 30 days, so the practical window is around a month rather than permanent. A build that launched fine all week can stall on the morning the network changes, an always-on VPN comes up, or the certificate behind it expires.
Can I install the app now and verify it later, without internet?
Yes. Install it while offline and the developer entry under Settings, General, VPN and Device Management reads Not Verified, with a Verify App button next to it. Put the device on a network that can reach Apple, tap Verify App, and the build launches. You do not have to reinstall anything.
Does Unable to Verify App mean the app has malware?
No. The alert says nothing about what is inside the app. It reports that iOS could not finish an online check of the certificate that signed the build, which is a connectivity result rather than a scan result. Judge the app on whether you were expecting a build from the organization that signed it.
Will deleting and reinstalling the app clear Unable to Verify App?
Rarely, and it costs you whatever data the app was holding. A reinstall changes nothing about the certificate or the route from the device to Apple, so the same check fails the same way. Cellular data instead of Wi-Fi, and switching off any VPN profile for a minute, are the two things worth trying first.
Do App Store apps ever show this error?
No. Apps from the App Store are signed by Apple itself and are not subject to the launch-time developer check, so they open with no network at all. If you are looking at this alert, the app reached the device some other way: an install link, an in-house app catalog, or a cable from Xcode.
Can a developer ship a build that never needs the check?
Only inside limits Apple sets. Teams created after June 2021 can generate an offline provisioning profile valid for seven days. Apple also says an app that needs to run offline for more than 30 days after first launch can request extended offline validity, though at the time of writing it describes that request form as still to come. Neither is something a tester can switch on from the device.
In short
“Unable to Verify App” is a network message wearing an error’s clothes. iOS wants to ask Apple whether the certificate on this build is still good, and something between the phone and ppq.apple.com will not carry the question. Try cellular data, then look for a VPN or a filtering profile, and only then suspect the build. If it fails on every network and every device, the certificate is the problem and only a re-signed build fixes it.
