Apple Silicon app builds but cannot launch

I had this same problem, and I was able to fix it by turning on "Automatically manage signing" in my target settings.

Unfortunately, I'm still getting the same error even after checking automatic signing. I've also confirmed the resulting binary and any embedded libraries are all signed with codesign, but I continue to see the permission complaint in Finder and the launch error in Xcode.

I don't have any good ideas where to look next to identify the problem. I was hoping the launch error would propagate some more meaningful reports somewhere, but I haven't found any. Without being able to run, debugging is quite tricky, so maybe the only option is to strip out code to see if it reaches a point of being able to run, although I'm not sure that will help. I have the distinct sense it's something else (probably a tiny thing), just can't put my finger on it.

I have this same problem

I have this problem too. Has anyone managed to solve it?

Solve the problem by deleting the files in
/Users/{username}/Library/Developer/Xcode/DerivedData/{project id}/Build/Products/Debug-iphoneos

Or clean xcode cache by command + K

Same thing happens to me when attempting to run an iOS app, written 100% in SwiftUI (if that makes a difference), with a target of "My Mac (Designed for iPad)." It worked fine for the first few days, but now I get the same error. I've restarted, deleted Derived Data, cleared the cache, and all the usual jazz.

It will build and run without errors on a physical iPhone X.

MBP M1 2020, Big Sur 11.1, Xcode 12.4.

My solution: modify the "Signing & Capabilities" --> "Team id", "Bundle Identifier"

I got 2 team id, one is my personal(free account),another is my company's team developer id(not free account), I'm part of group.

I crash at second account(and I checked the systemLog by Console,no useful information), so I change to the first one(free one), and it worked now. I don't know why.

---

Ps: And, I'm confused, because at 4 month ago, apple don't allow free account run Mac-M1-iOS-App, I found it can run right now.

(Today: 2021-11-03)

My device : Mac-mini-M1
My macOS : 12.0.1 Xcode : 13.0

I had the same issue, when compiling on My Mac (Designed for iPad). I solved it by changing the bundle identifier to a dummy one, compiling and runing the app, then reverting to the original bundle identifier.

I have this same problem with a project that was running / building fine (Swift MacOS app on M1 Pro Xcode 13.2.1) until I did all the necessary configurations to upload the app to Test Flight. Now I get this message. Have tried the signing and build folder clean options mentioned in this thread. No luck. It's a show stopper for me. If I can't resolve it I'll have to create an entirely new fork of my project that I never use with Test Flight. Don't see any other option at moment.

I run in to this sometimes. launchd seems to get confused every so often if code signing changes on a binary, but the bundle ID remains the same. That could happen when moving between release and a development builds or anything else that might alter code signing without the bundle ID changing.

This is not specific to Xcode launching your binary. If your binary is launched by a job in the LaunchDaemons or LaunchAgents folder, you could run in to the same situation if code signing changes. In this situation I've had to remove the Launchd job plist, reboot, then put it back.

More information on this issue here: https://developer.apple.com/forums/thread/126187

@deep-mac Try changing your Bundle ID, run the app once from Xcode, then change it back. That should force Launchd to update the apps known code signing requirements. Launchd caches code signing requirements and sometimes that cache gets corrupted when code signing changes. Such as what might happen when deploying to Test Flight. Forking your project wouldn't work unless that fork uses a different Bundle ID.

I am currently facing this issue with my project. And I think it's arising because of improper provisioning profile. I have managed to narrow it down to this scenario in my case: I have been using the wrong provisioning profile - one that's "ineligible" for my app. In our dev team, we are juggling through many profiles and it gets confusing. Will be trying to solve this by choosing the right signing certificates and will update ✌🏽

I am running into the same problem with running an iPad app on my M1 MBP. I am seeing the same error message in both Xcode 13.x and Xcode 14 beta 3. I have tried deleting the built product and rerunning the project. I have tried switching from automatic codesigning to manually codesigning the project. I have tried changing the bundle identifier with both automatic and manual codesigning. I have even tried running it after removing the one library it uses (a Swift package). None of these actions has resolved the problem. This is very frustrating because I know the project ran as a Mac app successfully last time I tried a month ago.

Has anybody come up with any further solutions to this problem that haven't yet been mentioned in this thread?

I ran into the same problem after setting up my project on my new MBA M2. After multiple restarts, I went through the System Preferences > Security & Privacy and noticed by accident that I hadn't checked the box under Developer Tools for the Terminal.app. After that, Xcode crashed when opening projects. Short panic and a restart later, the project opened again and it told me that my MBA is not registered as a device in the Provisioning Profile. After repairing, everything works now...

Maybe that helps someone...

I am also hitting this issue, and still see no resolution posted. Did anyone ever get this resolved?

I have tried all the suggestions. I am on macOS Sonoma 14.2.1. Xcode 15.2. My app Signing Certificate settings:

• Auto manage signing
• Team: MyName (Personal Team)
• Bundle Identifier: com.xxxx.myTool
• Provisioning Profile: None Required
• Signing Certificate: Sign to Run Locally

This is also a show stopping for me. I have been combing the web for days trying to resolve this - I am beyond desperate.