If you want to check iOS Signing Certificate (P12) instead, please use my online certificate checker. Or if you want to check an iOS Configuration Profile (mobileconfig), please use this Configuration Profile checker.
What this tool does
The checker above reads an iOS provisioning profile, the .mobileprovision file, and lays out everything Apple packed inside it.
You get the profile name, the type, the App ID it is tied to, the team that owns it, the platforms it targets, when it was created and when it expires, the signing certificates baked into it, the full entitlements, and the part most people came here for: every device UDID the profile is provisioned for, in a list you can actually search.
Nothing you upload is kept. The profile is read in memory, parsed, and gone the moment the page finishes loading.
There is no outbound network call at all, so unlike the certificate checker this one never even phones home.
I built it because reading a provisioning profile by hand means dumping the signed blob, fishing the plist out of it, and then squinting at raw XML to count devices.
This does the whole thing in one shot and puts it in plain language.
So what is a .mobileprovision file?
A provisioning profile is the permission slip that lets an app run on a device outside the App Store. On its own a signing certificate proves who you are, but it does not say what you are allowed to run or where.
The profile fills that gap. It bundles four things together: which signing certificate is allowed, which app the profile is for, what the app is permitted to do (the entitlements), and which devices it can run on.
Under the hood the file is not plain text. It is a signed container (PKCS#7) with an XML property list tucked inside it. Apple signs it so a device can trust it. This tool reaches in, pulls the plist out, and reads it.
Worth being straight about one thing: it reports what is inside the profile, it does not verify that the signature is validly Apple’s.
For an inspector that is the right call, because you often want to see inside a profile regardless of whether it would pass validation. Just know the difference between reading contents and proving authenticity.
Reading the results, one field at a time
Name
The label Apple or the developer gave the profile. Purely cosmetic, but it often hints at the purpose, like a distribution or development tag.
Type
Development, Ad Hoc, App Store, or Enterprise In-House.
This is the most important line, because it decides how the profile can be used and which devices, if any, it covers. More on each below.
App ID name and App ID
The App ID name is the human readable label.
The App ID itself looks like TEAMID.com.company.app. If it ends in a wildcard star, the profile covers a whole family of bundle IDs rather than one specific app.
Team name and Team ID
Who owns the profile. The Team ID is the ten character code that ties the profile, the certificate, and the App ID to one Apple developer account.
The team name is the real world name on that account, which is often the most revealing field in the whole file.PlatformWhich Apple platforms the profile targets.
If you see both xrOS and visionOS here, that is not a bug. xrOS was the original internal name for visionOS, and Apple never fully scrubbed it from the tooling, so profiles list both names for the same Vision Pro platform.
Profile UUID
The unique ID of this specific profile. iOS uses it to tell one installed profile from another.
Created and Expires
The life window. A profile past its expiry date is dead, and any app relying on it will stop launching.
The tool also flags how long is left or how long ago it lapsed.
Push environment
If the app uses push notifications, this shows whether it is wired for the development or production push servers.
Xcode managed
Whether Xcode created and maintains this profile automatically, as opposed to one built by hand in the developer portal.
The registered devices list
This is the section people usually open the tool for. Development and Ad Hoc profiles carry a list of device UDIDs, and that list is exactly which physical devices the app is allowed to run on. If a device is not in the list, the app will not install or launch on it, full stop.
A UDID is a Unique Device Identifier, the fingerprint of one specific iPhone or iPad. Older devices show a forty character hex string.
Newer ones use a shorter form with a dash in it. The checker lists every UDID with a running count, lets you filter the list live as you type, and gives you a one click copy of the whole set, which is handy when you are moving devices between profiles or reconciling a registration list.
Two profile types show no devices, and that is expected. App Store profiles are not tied to specific hardware, so there is nothing to list.
Enterprise In-House profiles set a flag that says provision all devices, so there is no list either, by design.
The profile types you will run into
Development
For building and debugging your own app on devices you have registered. It carries a device list and the get-task-allow entitlement, which is what lets a debugger attach.
Ad Hoc
For handing a build to testers outside the App Store. It also carries a device list, but without the debug entitlement. This is the classic way to distribute to a fixed set of devices, up to one hundred per device type per membership year.
App Store
For a build headed to the App Store. No device list, because Apple distributes it to everyone through the store instead.
Enterprise (In-House)
Issued through the Apple Developer Enterprise Program, meant for a company to push internal apps to its own staff without the App Store and without registering each device.
It provisions all devices, which is exactly why this type is the one that gets abused for public sideloading, and the one Apple revokes the fastest.
How provisioning profiles work for iOS sideloading
iOS by itself will not run unsigned code, and outside the App Store a valid signature alone is not enough.
The app also needs a provisioning profile that says this certificate may run this app, with these entitlements, on these devices. Signing certificate plus provisioning profile is the whole game. Sideloading is just the craft of getting a valid pair onto a device and keeping it valid.
With a free Apple ID, the profile lasts about seven days and covers only a handful of apps, which is why tools like AltStore, SideStore and Sideloadly exist to re-sign on a timer.
With a paid account you get a year and Ad Hoc distribution, but you are pinned to the UDIDs you registered, and Apple has gotten noticeably twitchier about how many devices you add and how often.
Enterprise profiles skip the device list entirely, which is the whole reason the sideloading scene has leaned on them so hard, and the whole reason a revocation there can kill thousands of installs at once.
The signing certificates inside the profile
A profile embeds the actual signing certificates it authorizes, so the device can check that the app was signed by an identity the profile trusts. The checker parses those and shows you the certificate name and its expiry.
This matters because a profile can be perfectly valid while the certificate inside it has expired or been revoked, and when that happens the app dies even though the profile still looks fine on paper.
If you want to check whether one of those certificates has actually been revoked by Apple, run its .p12 through the certificate checker, which does a live revocation lookup.
Why a profile stops working
Three different things can kill a profile, and they get mixed up constantly. The profile itself can expire, which you can see coming from the expiry date.
The signing certificate inside it can expire or get revoked by Apple, which is sudden and is the usual cause when a whole sideloaded app store goes dark overnight.
Or the device simply is not on the list, which is why a build that runs fine for you refuses to install for someone else. The fix depends on which one it is, and this tool plus the certificate checker between them tell you which.
What happens to your file
A provisioning profile is less sensitive than a signing key, since it holds no private key, but it does carry real information: your team name, your App IDs, and a list of your devices. So here is the honest accounting.
The profile is received, held in memory only, read, and discarded when the request ends. It is not written to disk. It is not saved in any database.
And there is no outbound network call whatsoever, so none of what is in your profile leaves the server that rendered the page.
Frequently asked questions
What is the difference between a .mobileprovision and a .p12?
The .p12 is your signing identity, the certificate and its private key. The .mobileprovision is the permission slip that says which app that identity may run, with which entitlements, on which devices. You need both to sideload.
Why does my profile show no devices?
Because it is an App Store profile, which is not tied to hardware, or an Enterprise In-House profile, which provisions all devices and so carries no list. Only Development and Ad Hoc profiles list specific UDIDs.
What is a UDID and why does it matter?
It is the unique identifier of one device. For Development and Ad Hoc profiles, only devices whose UDID is in the profile can run the app. Not on the list means it will not install.
My app installs for me but not for a friend. Why?
Most often their device UDID is not in the profile, so it was never authorized for them. Add their UDID, regenerate the profile, and re-sign. It can also be an expired profile or a dead certificate.
Can this tool add a device or edit the profile?
No. It only reads and reports. Editing a profile happens in Apple’s developer portal.
Does it verify the profile is validly signed by Apple?
No. It reads and shows the contents. It does not validate the signature, so treat it as an inspector, not an authenticity check.
Why does my profile list xrOS and visionOS?
They are the same platform. xrOS was the original name for what shipped as visionOS, and Apple left the old name in the tooling, so both show up.
Who made this
I am GeoSn0w, and I run iDevice Central. I spend my time on iOS security research, reverse engineering, and responsible disclosure, and I have read more provisioning profiles and chased more dead certificates than I would like to admit.
I wrote this tool and this guide because the questions around them come up constantly and the answers are usually buried in terminal commands and raw XML. If you spot something inaccurate, tell me, I would rather fix it than leave it wrong.
