eSign on iOS 26: How IPA Signing Actually Works
Every eSign guide online is the same three screenshots and a download button. Almost none of them explain the part that decides whether your apps still open next week: eSign does not give you a certificate. It uses one you bring, and where that certificate comes from is the entire story.
Here is what the tool actually does, the three ways people get a certificate into it, why shared ones die in waves, and what that “DNS profile” everyone recommends is really doing to your phone.
What eSign is
eSign is an IPA signer that runs on the phone. You hand it an app file and a certificate, it re-signs the app on-device and installs it — no Mac, no cable, no Apple Configurator. That is the genuine appeal, and it is why the tool has survived through iOS 26 while simpler tools broke.
What it needs from you is a pair of files:
- a .p12 — the signing certificate and its private key
- a .mobileprovision — the provisioning profile that says which devices and capabilities the signature covers
Feed it both, point it at an IPA, and it does the rest. Skip either one and nothing installs. Every “eSign not working” thread comes down to this pair being wrong, expired, or revoked.
Where the certificate comes from — the three routes
Your own developer account. You pay Apple $99 a year, generate your own certificate, and sign your own apps. Nobody can revoke it out from under you except Apple, and only if you abuse it. It is the sturdy option and almost nobody takes it, because $99 to install a few tweaks is a hard sell.
A free personal certificate. The one Xcode hands out with any Apple ID. It works, and it expires in 7 days — after which every app signed with it stops opening until you re-sign. That is the treadmill, and it is why “how to stop refreshing every 7 days” is one of the most searched things in this whole niche. We wrote up every free route and what each one costs you in effort.
A shared or sold certificate. This is what most eSign users actually run: an enterprise certificate circulating in Telegram channels and forums, sometimes free, sometimes sold as a “lifetime” slot. One certificate, thousands of strangers, and every app any of them signs is traceable to it.
Why shared certificates die, and why it happens to everyone at once
An enterprise certificate is meant to let a company distribute internal apps to its own staff. Using one to sign apps for thousands of unrelated people is exactly the abuse Apple watches for, and when they find it they revoke the certificate.
Revocation is not gradual and it is not personal. The certificate goes dark, and every app signed with it stops launching the same day — yours, and everyone else’s on the same slot. Nothing you did caused it and nothing you can do fixes it, other than importing whichever new certificate the community circulates next and re-signing everything again.
That is the honest arithmetic of free signing: the tool is free, the certificate is borrowed, and the borrowing is the risk. We went through the full mechanics of revokes — what triggers them, what a revoke wave looks like, what actually survives one — in developer certificate revokes: the reality of iOS sideloading.
The DNS profile, explained honestly
Sooner or later a guide tells you to install a DNS profile “so your apps never get revoked.” Here is what it does.
When you launch a signed app, iOS checks the certificate’s status against Apple’s servers. The DNS trick points that check at a server that never answers, so the phone cannot learn the certificate was revoked and keeps opening the app.
It works, with three caveats nobody puts in the thumbnail. You are blocking a system check, not fixing a certificate — the certificate is still dead everywhere else. Fresh installs of anything signed with it still fail, because installing needs a valid signature, not just a launch. And you are routing DNS through a stranger’s server for as long as the profile stays on the phone. We laid out the full trade-off in the free certificate method and its DNS bypass.
Direct install, and what it does not solve
eSign’s direct install pulls an IPA straight from a URL and signs it in place, so you never handle the file yourself. It is a real convenience and it removes a genuine annoyance — juggling multi-gigabyte IPAs in Files on a phone.
It does not change anything about the signature. The app still lives or dies with the certificate underneath it. Direct install makes step two faster; the certificate is step one.
Is eSign safe?
The tool itself is not the problem. Two things around it are.
There is no single canonical download. Search the name and you get a dozen sites all claiming to be official, plus mirrors on GitHub. When a tool has no authoritative home, “I downloaded eSign” is not a statement about what you installed. Take the same care you would with any IPA from a search result.
Nothing about signing needs your Apple ID password. A signature needs a certificate and a device identifier — that is it. Any site, app or seller asking for your Apple ID credentials is collecting accounts, not signing apps. That pattern, and the other tells of a certificate scam, are in what to watch for.
When eSign is the right tool
If you have your own developer account and sign your own builds, eSign is genuinely good: on-device, fast, no computer in the loop. Same if you are technical, you like the tinkering, and an app going dark on a Tuesday is an inconvenience rather than a problem.
If what you want is that the app you installed still opens next month, the variable to look at is not the signer — it is who holds the certificate and how many strangers share it. Managed signing exists for exactly that: the certificate is maintained, your device sits on it by UDID, and installs stay signed instead of expiring on a timer. On builds.io that means a one-tap install from the phone, with a one-time Apple processing step of up to three days when a new device is added — explained here.
Either way, the question to ask before you sign anything is the same one: whose certificate is this, and what happens to my apps the day it goes?