Every app I'd built died on the same morning, and there were no crash logs

One morning every app I had ever built stopped working on my own phone. Tap the icon, the splash screen flashes for a fraction of a second, and you're back on the home screen. Twelve of my apps were installed on that device. Eight of them were dead. Apps from the App Store were all fine.

The part that cost me the most time: there were no crash logs. Not in Xcode's Devices window, not in Settings → Privacy → Analytics Data, nowhere. I spent a while assuming the logs were being hidden from me somehow, because an app that disappears half a second after launch has obviously crashed.

It hadn't. That's the whole clue, and it took me too long to hear it.

No crash log means the process never started

A crash report is written by the crash reporter inside a running process. If the system refuses to start the process at all, there is nothing to report and nothing gets written. An empty Analytics Data list isn't a missing log — it's the answer.

So instead of hunting for logs, launch the app from the command line, where the failure has to be reported to you as an exit status:

xcrun devicectl device process launch \
  --device <DEVICE-UDID> com.yourcompany.yourapp

The error that comes back is errno 85 (ENEEDAUTH) — “Need authenticator”. That is the system telling you the binary's code signature is no longer trusted on this device. It is not a bug in your app. Your app was never given the chance to run.

The certificate expires, not the profile

Here is the trap that made this take hours instead of minutes. I went and checked the provisioning profile's expiry date, saw it was almost a year away, and crossed signing off the list. Wrong date.

A provisioning profile and the signing certificate embedded inside it have two different expiry dates. I just checked a profile on this machine, right now:

DIR=~/Library/Developer/Xcode/UserData/"Provisioning Profiles"
PROFILE="$DIR/<uuid>.mobileprovision"

# The profile's own expiry — the number that misled me
security cms -D -i "$PROFILE" | plutil -p - | grep ExpirationDate
#   "ExpirationDate" => 2027-08-12

# The certificate actually embedded in that same profile
security cms -D -i "$PROFILE" \
  | plutil -extract DeveloperCertificates.0 raw -o - - \
  | base64 -d | openssl x509 -inform DER -noout -dates
#   notBefore=Aug 10 15:05:28 2026 GMT
#   notAfter =Aug 10 15:05:27 2027 GMT

Two days apart here — it can be much further apart in practice, because the profile gets regenerated on its own schedule. Either way, the certificate is the one that stops your apps from launching, and it's the one nobody looks at.

The one command worth remembering

Skip the profile entirely. Ask the keychain what your signing certificates are and when they run out:

security find-identity -v -p codesigning

security find-certificate -c "Apple Development" -p -a \
  | openssl x509 -noout -dates -subject

Look at notBefore as well as notAfter. That start date is the anniversary your apps will die on, and knowing it is the difference between an annoying morning and a lost one.

Fixing it, and the two things that go wrong while you do

The fix itself is unremarkable: let Xcode issue a new certificate, then rebuild and reinstall each app. Nothing is lost — app data on the device survives, because you are replacing the binary, not the container. But two things reliably get in the way.

Xcode stops with “No Account for Team”. Your Apple ID session has quietly expired along with the certificate. There is no way to script around it — open Settings → Accounts and sign in again by hand before anything else will work.

Fixing one app does not mean the others are fixed. The renewal can issue more than one certificate on the same day, and the earlier one gets revoked. Some of your projects will have embedded the good one and some the dead one, so they fail independently. Check the certificate inside each project's profile rather than assuming a single fix covered everything.

The practical lesson: when the first one breaks, sweep the whole device at once. I fixed them one at a time as I noticed them, which meant discovering the same problem eight separate times.

What I do now

• A calendar reminder on the certificate's notBefore date, one week early. It is a fixed annual event, so there is no excuse for being surprised by it.
• When an app installed from Xcode won't launch, run security find-identity -v -p codesigning before anything else. It takes two seconds and rules out the most likely cause.
• No crash log is information, not an absence of information. It narrows the problem to “the process never started”, which is a much smaller space to search.

None of this affects anyone who installed your app from the App Store — those builds are signed by Apple with a distribution certificate and keep working. It only hits the apps you side-load onto your own device, which, if you build things for yourself, is most of them.