Developer ID App operates in other app's Container!

Question

Created Sep ’20

Replies 5

Boosts 0

Views 1.3k

Participants 2

I wrote a little macOS troubleshooting utility which I need to send to a few users. I don't want it sandboxed because I it needs NSHomeDirectory() to return the user's real home directory, /Users/me.

In the app target's Signing and Capabilities tab, I removed App Sandbox. When I test the app running in Xcode, NSHomeDirectory() returns /Users/me as required. After the app worked to my satisfaction, I clicked Archive, then Upload for notarizing, then Export.

The spctl tool assesses the exported, notarized app product as Notarized Developer ID, and upon running, in Activity Monitor, the Sandbox column reads No. However, this product does not function correctly because NSHomeDirectory() is returning the following path:

/Users/me/Library/Containers/com.myCompany.MyOtherApp/Data

wherein MyOtherApp is the name of the last sandboxed macOS app I started developing a couple months ago. ARGHHH!! Where in the world did it get that? I definitely started this as a New Project.

In the Build Settings, I have
Code Signing Style = Manual
Code Signing Identity = Developer ID Application

But I have also tried:
Code Signing Style = Automatic
Code Signing Identity = Apple Development

Either way, upon executing Archive-Upload-Export workflow and testing the product, it has this same problem.

Note: I've never used Xcode's built-in workflow for Developer ID before, due to issues when Apple first released it. I wrote and since 2012 have been using my own script instead. But yesterday I thought I would try Xcode's built-in workflow because I read that Apple has fixed the issues over the years. Have they? What have I done wrong?

Answered by Etresoft in 636613022

What have I done wrong?

It's hard to say. This is not something that Xcode normally does. What are you using as the Bundle Identifier for this app? Are you reusing com.myCompany.MyOtherApp? Bundle identifiers have to be unique. On a developer's machine, they never are, so you should always tests in a pristine setup like a virtual machine. Depending on how your app is being launched, the bundle identifier can change the behaviour and cause some other binary to be executed instead.

Boost

Answer 1

Etresoft OP

Sep ’20

Accepted Answer

What have I done wrong?

It's hard to say. This is not something that Xcode normally does. What are you using as the Bundle Identifier for this app? Are you reusing com.myCompany.MyOtherApp? Bundle identifiers have to be unique. On a developer's machine, they never are, so you should always tests in a pristine setup like a virtual machine. Depending on how your app is being launched, the bundle identifier can change the behaviour and cause some other binary to be executed instead.

1

Answer 2

jerrykrinock OP

Sep ’20

Thank you for thinking about this, @Etresoft. I did not set the Bundle Identifier in this project. It must have been generated by Xcode based on the names I entered into the File > New Project sheets.

To find out, I just looked in the Info.plist of the exported notarized .app which exhibits the incorrect behavior. Key CFBundleIdentifier has value com.myCompany.MyApp, as expected. It is not com.myCompany.MyOtherApp. Going further, I searched the project for the string MyOtherApp. As expected, zero occurrences were found.

Thinking about this further, maybe I created some kind of developer signing identity, certificate or profile when creating MyOtherApp which is somehow leaking into this new app because I neglected to create the same for it. My experience is limited to signing and, recently of course, notarizing Developer ID apps using the command-line utilities, overwriting any codesigning by Xcode. I have never submitted an app to the Mac App Store. So you seeI have never been motivated to try and understand developer signing identities, certificate, profiles, etc., and that is likely where my problem is.

Or a bug in Xcode? I forgot to say that I am using Xcode 12 Beta 5.

0

Answer 3

jerrykrinock OP

Sep ’20

There is more @Etresoft. You also stated that this might be due to some mysterious hidden crap on my Mac. I was at first incredulous that Mac developers normally test their apps on a virtual machine to avoid trouble, since I have never done so in all my years of developing nonsandboxed apps. So it was not until today that I dragged the troublesome product to a different Mac and tested. To my amazement, it worked!

There is more. I use the Finder alternative, Path Finder, a third party app. I just noticed that when I execute a menu command in Path Finder which should open a window to my Home folder, Path Finder instead opens a window to the same MyOtherApp container whose path NSHomeFolder() returns to my new app. In other words, Path Finder has the problem as my new app. Interestingly, though, Finder's menu command Go > Home works correctly.

One more test: I tried running the troublesome app in my "test" user account on this Mac, and it works fine in the "test" user account.

Well, all of this raises more questions than answers. But now I where the problem lies. Next stop: A restart?!?!?!

0

Answer 4

Etresoft OP

Sep ’20

My experience is limited to signing and, recently of course, notarizing Developer ID apps using the command-line utilities, overwriting any codesigning by Xcode.

Xcode can notarize apps by itself. Use the "archive" feature and choose "upload". It does it all for you.

I can't comment on any 3rd party apps.

You should assume that using a Mac for developer is simply going to trash many system databases. In most cases, that doesn't cause any problems, especially if your app is a self-contained app that only deals with its own data. But if your app interacts with any system services, such as including a QuickLook plug-in, just as one example, then you can expect problems. The bundle ID is a critical identifier. Never ever use "com.mycompany" for anything.

0

Answer 5

jerrykrinock OP

Sep ’20

Update: Well, after a day or so I realized that other apps on my computer were behaving incorrectly also, so I peeked into that /Users/me/Library/Containers/com.myCompany.MyOtherApp/Data and, sure enough, found that a dozen or so other apps had been putting their data in there too. Presumably any app which had used NSHomeDirectory().

Restarting the computer solved this problem with my new app, and all of the problems with all of the other apps.

I think that macOS is getting too complicated for Apple to handle it :(

0