Xcode 13.4 New project "command line tool" cannot run because of missing entitlements

I’m confused by the context here. To start, given that you mention a command-line tool, I presume you’re targeting macOS. Is that right?

Given that, is your ultimate goal to create a command-line tool? Or do you intend to create an app but you’re just doing some initial testing with a command-line tool?

You wrote:

My project uses MusicKit, even if properly authorised with authorisation status equals .authorised app crashes and saying there are missing entitlements and permission denied.

Please post the exact error message you’re getting here.

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

Sorry for the confusion english is not my native language. So to summarize:

1. I am targeting MacOS
2. I am going to create command line tool or if this is necessary to work, an *.app that install command line tool
3. Purpose for tool is to use MusicKit and do command line tool to manipulate and play e.g. radio stations.

Exact error message is:

2022-08-10 19:14:33.815824+0200 ConMusic[1450:15512] [DataRequesting] Failed retrieving MusicKit tokens: Error Domain=ICErrorDomain Code=-7009 "Failed to retrieve bundle identifier of the requesting application. The requesting application is likely missing the "com.apple.application-identifier" entitlement." UserInfo={NSDebugDescription=Failed to retrieve bundle identifier of the requesting application. The requesting application is likely missing the "com.apple.application-identifier" entitlement.}. Throwing .permissionDenied.

2022-08-10 19:14:33.816024+0200 ConMusic[1450:15512] [DataRequesting] Failed retrieving tokens for MusicDataRequest.Context(url: https://api.music.apple.com/v1/catalog/us/artists/1264549322). Error = .permissionDenied.

.permissionDenied

So apparently even if authorised there is problem with fetching music user token because of bundle identifier. But I don't see anywhere in a project place to write entitlements, no info.plist file and no entitlement file. Is that more clear now? :)

Thanks for all the clarifications.

MusicKit isn’t really my thing but, based on that log message, it seems that MusicKit requires that code be signed with the com.apple.application-identifier entitlement. This is not common, but it’s also not super rare. The presence of that entitlement allows Apple to securely identify the code calling the API.

On iOS this isn’t an issue. Third-party code on iOS is always an app [1] and the application-identifier entitlement [2] is required to match your app up with a provisioning profile which authorises its execution. For more background on that process, see TN3125 Inside Code Signing: Provisioning Profiles.

This is more of a challenge on macOS which, for historical reasons, allows you to run third-party code without a profile [3]. The com.apple.application-identifier entitlement is a restricted entitlement (per the definition in TN3125) and must be authorised by a profile. This presents two problems:

1. You have to create the profile and apply the profile to your code.

2. You’re building a command-line tool, which has no place to store a profile.

The standard workaround for problem 2 is to place your command-line tool in an app-like wrapper. For the details, see Signing a Daemon with a Restricted Entitlement. Note that this article is focused on daemons but the some logic applies to command-line tools.

As discussed in that article, a good way to get started with this is to create an app target rather than command-line tool target. If you do that, Xcode’s automatic code signing will take care of problem 1.

Once you’ve set this up, you’ll have a structure like this:

ToolInAppsClothing.app/
  Contents/
    Info.plist
    MacOS/
      ToolInAppsClothing
    PkgInfo
    _CodeSignature/
      CodeResources
    embedded.provisionprofile

In Terminal the user will have to run the tool like so:

% ToolInAppsClothing.app/Contents/MacOS/ToolInAppsClothing

That’s obviously a hassle, so the standard practice is for either you or the user to create a symlink to the executable that the user can run directly.

if this is necessary to work, an *.app that install command line tool

To be clear, if you package this within an app you will need a nested bundle:

Container.app
  Contents/
    Info.plist
    MacOS/
      Container
      ToolInAppsClothing.app/
        Contents/
          Info.plist
          MacOS/
            ToolInAppsClothing
          embedded.provisionprofile
    embedded.provisionprofile [optional]
    Resources/
      … other stuff …

The container app may or may not have a profile, depending on whether it uses any restricted entitlements. The tool app must have a profile, and it must be placed within the tool app’s bundle. The tool app cannot piggyback on top of the container app’s profile. From the trusted execution system’s perspective, these are two separate apps.

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

[1] Or an app-like thing, like an appex.

[2] Note that iOS and its child platforms use application-identifier while macOS uses com.apple.application-identifier

[3] Hell, on Intel you can still run third-party code that’s not signed!

Thank for detailed explanation. It looks that whole security thing really makes creating things on Mac much more difficult, is that not overkill? If writing command-line-tools in Swift is I'm guessing from your post impossible without creating "App" maybe it's better to remove that target from Xcode configuration options? I will try to explore your solution and let you know.

Also if this is as you mentioned not a problem on iOS what is the behaviour if the app is build also as "Mac-Catalyst"?

Big big thank you as you are the only one in whole internet who understood my problem :)

Ad 3) One more reason to like Intel more than M1 :)

If writing command-line-tools in Swift is I'm guessing from your post impossible

That’s not what I was trying to communicate. You can create a command-line tool (using Swift, Objective-C, or any other language you like) and call the vast majority of APIs without any problems. You can even sign such a tool with various entitlements. The issue here is that the specific API you’re calling, MusicKit, seems to require a restricted entitlement, one that must be authorised by a provisioning profile, and that requires an app-like structure.

what is the behaviour if the app is build also as "Mac-Catalyst"?

Mac Catalyst is an app-only technology and thus this issue never comes up in that context. That is, a Catalyst app is already packaged in an app structure and thus including a profile to authorise the use of restricted entitlements is easy.

One more reason to like Intel more than M1 :)

So you like less security?

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

Again, thanks for clarification regarding command-line tools :) 1 .I always prefer convenience over security. The most secure computer is the one that is not connected to network so the line must be put somewhere. If Apple e.g for sake of security force password change to AppStore account once per week, people stop using AppStore at all because it will simply be too much hassle.

Security can be seen in relative terms like in this MusicKit thing. Apple Music API has many flaws and this is definitely one of them. But thanks for trying to help me deal with this issues :)

1. Also from environmental point of view it's not good for Earth when various companies will try to produce their own processors using elements that are less and less found on our planet, so Intel is the way to go, that's why Mac Pro exists :) I was happy when Apple abandoned Motorola for Intel and would be even more happy if Apple hadn't abandoned NVidia as well. M1 on laptops bring macbooks more to iPads and desktop OS should never be sandboxed closed environment that's why for my daily work I still use Mojave :) with Monterey in virtual.

2. I'm professional and I know what I am doing,working on computer for over 30 years. If user must be protected all the time than maybe buying laptop is not for him :)

But that's whole other discussion not for this thread. As Eskimo you could bring some ice to Poland, it's too hot here to work ^^