If an app bundle is copied from its original location it will not be able to launch on M1

it works for me, there must be something strange going on with your Mac. I created the default macOS app in Xcode 14, dragged it out of the build products folder to my Desktop, and launched it from there. No problem.

You need a machine with Apple Silicon and Monterey 12.6

I updated my Apple silicon ‘victim’ machine to 12.6 (which is why I didn’t respond yesterday :-) and I don’t see this problem. Specifically:

1. I have an Apple silicon MacBook Air running macOS 12.6 and Xcode 13.4.

2. In Xcode, I chose New > Project and selected the macOS > App template.

3. I chose Product > Run; the app runs just fine.

4. I quit the app.

5. Back in Xcode, I chose Product > Show Build Folder in Finder.

6. In the Finder, I navigated to Products > Debug.

7. I moved the built app to the desktop.

8. I double clicked it to launch; it ran just fine.

I initially tried this with the app configured to Sign to Run Locally but I repeated the test with the signing set to a Personal Team and that worked as well.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The problem is there again right now - again only if I copy the application, not if I move it.

I am suspecting that the launch daemon for some reason can't or won't launch the application. I tried to delve into what I presume is the log file for the launch daemon, /var/log/com.apple.xpc.launchd/launchd.log. I would like to hear if the observations here can explain why the application sometimes gets stuck. Thanks again!

First an example of what it looks like when the test application (here called TestApp) actually does get launched (there is a lot more about service stubs being created, but I left that out).

2022-09-29 13:31:07.270877 (gui/739/application.com.ccieurope.TestApp.26282168.26282251) <Notice>: internal event: WILL_SPAWN, code = 0

2022-09-29 13:31:07.270883 (gui/739/application.com.ccieurope.TestApp.26282168.26282251) <Notice>: service state: spawn scheduled

2022-09-29 13:31:07.270884 (gui/739/application.com.ccieurope.TestApp.26282168.26282251) <Notice>: service state: spawning

2022-09-29 13:31:07.270894 <Notice>: Coalition Cache Hit: app<application.com.ccieurope.TestApp.26282168.26282251(739)> [2930]

2022-09-29 13:31:07.270977 (gui/739/application.com.ccieurope.TestApp.26282168.26282251) <Notice>: launching: non-ipc demand

2022-09-29 13:31:07.271506 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: xpcproxy spawned with pid 6799

2022-09-29 13:31:07.271518 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: internal event: SPAWNED, code = 0

2022-09-29 13:31:07.271519 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: service state: xpcproxy

2022-09-29 13:31:07.271539 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: internal event: SOURCE_ATTACH, code = 0

2022-09-29 13:31:07.276701 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: service state: running

2022-09-29 13:31:07.276705 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: internal event: INIT, code = 0

2022-09-29 13:31:07.276706 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: job state = running

2022-09-29 13:31:07.276721 (gui/739/application.com.ccieurope.TestApp.26282168.26282251 [6799]) <Notice>: Successfully spawned TestApp[6799] because non-ipc demand

2022-09-29 13:31:07.282872 (pid/6799 [TestApp]) <Notice>: uncorking exec source upfront

2022-09-29 13:31:07.282895 (pid/6799 [TestApp]) <Notice>: created

2022-09-29 13:31:07.283117 (pid/6799 [TestApp]) <Notice>: uncorking domain

2022-09-29 13:31:07.284771 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.CMValidateMovieDataReferenceService

2022-09-29 13:31:07.284811 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.ColorSyncXPCAgent

2022-09-29 13:31:07.284823 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.CoreDisplay.XPCService

2022-09-29 13:31:07.284831 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.ImageIOXPCService

2022-09-29 13:31:07.284879 (pid/6799/com.apple.MTLCompilerService) <Notice>: created the implicit endpoint upfront

2022-09-29 13:31:07.284893 (pid/6799/com.apple.MTLCompilerService) <Notice>: draining messages from com.apple.MTLCompilerService

2022-09-29 13:31:07.284901 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.PerfPowerTelemetryClientRegistrationService

2022-09-29 13:31:07.284911 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.ColorPickerImageLoader

2022-09-29 13:31:07.284919 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.LegacyExternalColorPickerService.arm64

2022-09-29 13:31:07.284926 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.LegacyExternalColorPickerService.x86_64

2022-09-29 13:31:07.284930 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.VersionsUIHelper

2022-09-29 13:31:07.284935 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.WindowSharingControlViewService

2022-09-29 13:31:07.284939 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.documentPopoverViewService

2022-09-29 13:31:07.284945 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.openAndSavePanelService

2022-09-29 13:31:07.284950 (pid/6799 [TestApp]) <Notice>: Service stub created for com.apple.appkit.xpc.sandboxedServiceRunner

Now, the excerpt below is what I get when the application gets stuck. It seems that it never gets to the part where the service stubs are created:

2022-09-29 13:23:59.437276 (gui/739/application.com.ccieurope.TestApp.26282648.26282653) <Notice>: service state: spawn scheduled

2022-09-29 13:23:59.437277 (gui/739/application.com.ccieurope.TestApp.26282648.26282653) <Notice>: service state: spawning

2022-09-29 13:23:59.437287 <Notice>: Coalition Cache Hit: app<application.com.ccieurope.TestApp.26282648.26282653(739)> [2964]

2022-09-29 13:23:59.437353 (gui/739/application.com.ccieurope.TestApp.26282648.26282653) <Notice>: launching: non-ipc demand

2022-09-29 13:23:59.437785 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: xpcproxy spawned with pid 6685

2022-09-29 13:23:59.437798 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: internal event: SPAWNED, code = 0

2022-09-29 13:23:59.437799 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: service state: xpcproxy

2022-09-29 13:23:59.437812 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: internal event: SOURCE_ATTACH, code = 0

2022-09-29 13:23:59.442645 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: service state: running

2022-09-29 13:23:59.442652 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: internal event: INIT, code = 0

2022-09-29 13:23:59.442654 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: job state = running

2022-09-29 13:23:59.442665 (gui/739/application.com.ccieurope.TestApp.26282648.26282653 [6685]) <Notice>: Successfully spawned TestApp[6685] because non-ipc demand

It is important that you copy the app to the desktop, not just move it

But in the Finder, right?

Another thing is that this does not happen all the time.

So how do you handle the replace? Do you move the original to the trash beforehand? Or let the Finder do the replace? Or build up multiple copies on the desktop?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I don't think it is important exactly how you do it. The main thing is that the application is copied, not moved.

One way to do it is using Finder. You need to hold down the option key while dragging the application to the new location (I usually drag it to the desktop, but I don't think that is important).

You could also do it from a terminal:

cd to the build folder (e.g. ~/Library/Developer/Xcode/DerivedData/TestApp-eyuqkfhehkuyepbxeuyahjjcgmsu/Build)

cp -pr TestApp.app ~/Desktop/

I usually remove the old instance of the application from the desktop first.

I don't think it is important exactly how you do it.

Oh it’s very important. Updating code with cp is a common cause of mysterious code signing problems. See [Updating Mac Software][ref] for the backstory there.

https://developer.apple.com/documentation/security/updating_mac_software

Also, even if you’re not replacing, using cp with the -r flag is a bad idea because it ‘flattens’ symlinks, which breaks any app that contains a framework.

However, the Finder should be safe from such issues.

I had another shot at reproducing this today. I continue with the above process, except I replaced step 7 with:

1. I option-dragged the app to the Desktop.

2. I double clicked it to launch; it ran just fine.

3. In Xcode, I added this to the app’s viewDidLoad() method:

   print("1")
   

4. I rebuilt the app.

5. In the Finder, I option-dragged the app to the Desktop.

6. In the result alert, I clicked Replace.

7. I double clicked the app; it ran just fine.

8. I went back to step 3, adding another digit to the string each time.

Eventually the string looked like this [1]:

print("1________012")

at which point I gave up.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I replaced some digits with underscores because DevForums is feeling grumpy today.

I don't think it is important exactly how you do it.

Oh it’s very important. Updating code with cp is a common cause of mysterious code signing problems. See [Updating Mac Software][ref] for the backstory there.

https://developer.apple.com/documentation/security/updating_mac_software

Also, even if you’re not replacing, using cp with the -r flag is a bad idea because it ‘flattens’ symlinks, which breaks any app that contains a framework.

However, the Finder should be safe from such issues.

I had another shot at reproducing this today. I continue with the above process, except I replaced step 7 with:

1. I option-dragged the app to the Desktop.

2. I double clicked it to launch; it ran just fine.

3. In Xcode, I added this to the app’s viewDidLoad() method:

   print("1")
   

4. I rebuilt the app.

5. In the Finder, I option-dragged the app to the Desktop.

6. In the result alert, I clicked Replace.

7. I double clicked the app; it ran just fine.

8. I went back to step 3, adding another digit to the string each time.

Eventually the string looked like this [1]:

print("1________012")

at which point I gave up.

Whatever is going on, it seems to be hard for other folks to reproduce. I recommend that you retest this in some other environments. Specifically:

• Create a new user on your Mac and see if it happens there.

• Try it on a cleanly installed Mac. I usually use a VM for this sort of thing.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I replaced some digits with underscores because DevForums is feeling grumpy today.

I must admit that I cannot reproduce the behaviour anymore this morning, but I always feel unwell about problems that just go away without any good reason. Similar behaviour was also observed by other developers and testers in our organisation, and I myself did test on at least three different machines, all with Monterey 12.6 and the M1 processor.

But anyway, I will leave it for now. I might return if we are able to reproduce the problem more consistently. Thanks for all of your efforts!