mirror of
https://github.com/SignTools/SignTools.git
synced 2026-04-26 02:15:54 +03:00
[GH-ISSUE #631] Recurring "Unable to verify app" #121
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/SignTools#121
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @WalkmanAzimi on GitHub (Jan 16, 2026).
Original GitHub issue: https://github.com/SignTools/SignTools/issues/631
Environment:
– SignTools web service hosted on VPS (Docker)
– SignTools-CI builder on GitHub Actions
– Using Developer Account method (Apple ID + p12)
Problem:
When signing an app with bundle ID net.whatsapp.WhatsApp1, the build fails with: An App ID with Identifier 'net.whatsapp.WhatsApp1' is not available. Please enter a different string.
This happens during the fastlane produce create step when registering the app with Apple.
What I've tried:
– The bundle ID extensions (.NotificationExtension, .Intents, etc.) are already registered in my Apple Developer account
– The main bundle ID net.whatsapp.WhatsApp1 cannot be manually created in Apple Developer Portal either (same error)
– Other signing tools (Sideloadly, AltStore, ESign) can sign with this bundle ID without issues.
Expected behavior:
SignTools should be able to sign apps with any bundle ID without requiring Apple to accept the App ID registration, similar to how other sideloading tools work.
Why I'm using Developer Account method instead of Custom Provisioning Profile:
I'm already using the Custom Provisioning Profile method with other tools (Feather, ESign, AltStore) and still experiencing frequent OCSP verification blocks ("Unable to verify app"). I wanted to try the Developer Account method to see if it would have fewer verification issues since the apps are properly registered with Apple. However, I can't even get past the signing stage due to this bundle ID restriction.
Question:
Is there a way to skip the fastlane produce create step and use an existing wildcard provisioning profile instead? Or sign without registering the bundle ID with Apple?
@ViRb3 commented on GitHub (Jan 16, 2026):
SignTools has two methods of signing - Apple Account or Provisioning Profile. The former requires a globally unique Bundle ID. The latter depends on the profile you give it. If you give it a wildcard one, it will indeed be able to sign any bundle ID. This is what probably every other signing app does. Read the SignTools docs on how to set up both.
Ah, same here actually. I'm pretty sure this is a bug that started happening after upgrading to iOS 26. I don't think the way you sign will make a difference. I noticed all of my sideloaded apps last exactly 14 days and then I have to install a fresh provisioning profile in my device to get another 14 days. I've been meaning to reset my phone and see if it fixes it, but still haven't gotten to that.
@WalkmanAzimi commented on GitHub (Jan 16, 2026):
I thought it was a sideloading app issue, so I wanted to test it with signtools.
I don’t think resetting the phone helps though. I bought a brand-new phone a few days ago, made a fresh certificate, and it still got revoked within a few days.
Yours lasting 14 days is good. Mine sometimes gets revoked twice in the same day, so I’m not even hitting that window.
If that’s the case, even using signtools won’t fix it for me, right?
@ViRb3 commented on GitHub (Jan 17, 2026):
It sounds like we are having different issues then. Mine doesn't get revoked, it's just that the phone can't verify the validity. As far as I know, the "grace period" is two weeks, that's why it happens at that interval. I have another phone with the same signed apps and it has no issue.
For your case, twice a day sounds like something completely different is happening. Feel free to try all options in SignTools and see if anything helps.
@WalkmanAzimi commented on GitHub (Jan 17, 2026):
I don’t think mine is getting revoked in the usual sense. I can still use the date trick to reopen the apps, and I rely on that most of the time instead of creating a new certificate.
What I do is set the phone date to a future year, like 2032, restart the phone, then open the app to trigger the “app not available” error. After that, I set the date back to today, don’t open the app again, re-sign only one of the apps, and install it. Once I do that, all the apps that were showing the “unable to verify” error start working again.
I shared this method on Reddit a few weeks ago and it works for other people too.
The problem is it’s not permanent. Sometimes it lasts a week, sometimes only a few hours. I honestly don’t understand the logic behind it.
@ViRb3 commented on GitHub (Jan 17, 2026):
You can try something that works for me - using iMazing, export the provisioning profile of your app to your computer, delete it from the phone, then import the exact same file right back. This "resets" the 14 days for me.
@WalkmanAzimi commented on GitHub (Jan 19, 2026):
Thank you, I’ll definitely try that.
One last question: the signed apps on signtools disappear from the web after about an hour or so, probably to save storage. Is there a way to make them stay longer, like 24 hours?
@ViRb3 commented on GitHub (Jan 19, 2026):
No, apps never disappear in SignTools unless you specifically click "Delete" on each one. If you're using Docker, you are probably not mounting the data as a volume and it gets reset between container restarts. Double-check the docs: https://github.com/SignTools/SignTools/blob/master/INSTALL.md#3b-docker
@WalkmanAzimi commented on GitHub (Jan 20, 2026):
Got it, thanks for clarifying. That makes sense now. I will double check my docker volume setup and the docs.