My app refuses to run a print job

Hello

I'm currently upgrading an app because said app age requieres an upgrade and I've started a new empty project, when I get to the printing functionality after som weeks of work to my demise I can't get it to work, in essence my code looks like this:

let vista = NSView()
vista.setFrameSize(NSSize(width: 400, height: 800))
let operacion = NSPrintOperation(view: vista)
operacion.run()

But I just get this system warning, "This application does not support printing." I´ve had checked the printing option in the project sandbox, and even deleted the sandbox itself with the same result. I even created a new empty project with this sole function with the same result but if I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app. I am a lost with this issue and I greatly appreciate any help.

Thanks

Answered by DTS Engineer in 843132022

So, the key detail in you post is actually this:

I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app.

Outside of a few odd edge cases that don't apply here, as far as the system is concerned your bundle ID is what defines YOUR app. That is:

  1. Two app bundles are considered "the same app" if they have the same bundle ID, even if EVERYTHING else is different.

  2. Two app bundles are considered "different apps", even if the ONLY difference between them is their bundle IDs.

That's important because it's why patterns like this:

I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app.

...are almost always caused by data the system is tracking ABOUT your app, NOT your apps own code. The next thing I would do here is perform two simple tests to quickly verify that nothing else might be involved. Starting with the project that's failing, do the following:

  1. Take the app configuration that's failing and change it's bundle ID (and nothing else). This proves that the code itself can work.

  2. Create a new user account and run the bundle ID that fails there. If it works (which I expect it will), this confirms that the issue is specifically tied to the local account data.

  3. (b) In the unlikely event that #2 fails, test again on a new system installation. Ideally that would be and entirely different computer, but a VM will work too. If it works here, then the problem is something in the machine wide data (weird and unlikely, but possible). If it doesn't work, then that's really weird and I'd need to think about it more...

Assuming that tests above show what I'm expecting, it's all but guaranteed that this an account specific issue caused by "something" that happened while you were working on the app. It's likely that you'll never really figure out what that issue actually was, but it also means the the issue will probably never happen again. That means the goal here is really just getting your account working again, not "fixing" any specific bug.

To that end, a few thing you can try:

  • Use the tccutil command line to to reset tcc.

  • The most direct solution is to simply create a new account and move data over by hand (not through any kind of data migration).

  • You might be able to find the underlying issue by digging through the console log from the time of failure. My big suggestion here is to have your app log to the console immediately before and immediately after the print operation fails. With a bit of luck, any failure related logging will then be between those two logs.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

So, the key detail in you post is actually this:

I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app.

Outside of a few odd edge cases that don't apply here, as far as the system is concerned your bundle ID is what defines YOUR app. That is:

  1. Two app bundles are considered "the same app" if they have the same bundle ID, even if EVERYTHING else is different.

  2. Two app bundles are considered "different apps", even if the ONLY difference between them is their bundle IDs.

That's important because it's why patterns like this:

I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app.

...are almost always caused by data the system is tracking ABOUT your app, NOT your apps own code. The next thing I would do here is perform two simple tests to quickly verify that nothing else might be involved. Starting with the project that's failing, do the following:

  1. Take the app configuration that's failing and change it's bundle ID (and nothing else). This proves that the code itself can work.

  2. Create a new user account and run the bundle ID that fails there. If it works (which I expect it will), this confirms that the issue is specifically tied to the local account data.

  3. (b) In the unlikely event that #2 fails, test again on a new system installation. Ideally that would be and entirely different computer, but a VM will work too. If it works here, then the problem is something in the machine wide data (weird and unlikely, but possible). If it doesn't work, then that's really weird and I'd need to think about it more...

Assuming that tests above show what I'm expecting, it's all but guaranteed that this an account specific issue caused by "something" that happened while you were working on the app. It's likely that you'll never really figure out what that issue actually was, but it also means the the issue will probably never happen again. That means the goal here is really just getting your account working again, not "fixing" any specific bug.

To that end, a few thing you can try:

  • Use the tccutil command line to to reset tcc.

  • The most direct solution is to simply create a new account and move data over by hand (not through any kind of data migration).

  • You might be able to find the underlying issue by digging through the console log from the time of failure. My big suggestion here is to have your app log to the console immediately before and immediately after the print operation fails. With a bit of luck, any failure related logging will then be between those two logs.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin

Thank you for your assistance. I was entertaining the idea of the original app existing data interfering with the new project, but not having enough information to know for sure. I still don´t know but I find the error but not the reason, when I made a new test project with the conflicting name such project is created without problem, when I checked the printing capability n the sandbox section I get this message. "This change requires an additional Entitlements file." The result is to entitlement files, the someApp.entitlements and someAppRelease.entitlements after my post of yesterday I decide to dig further and notice than the second file has the com.apple.security.print flag with YES value, but not the original entitlements file, so, if I add manually such flag the app can print while running on Xcode. Like I said this is the bug but I still ignore why Xcode makes the second file and thus provoking this issue.

Greetings Alberto V.

The result is to entitlement files, the someApp.entitlements and someAppRelease.entitlements after my post of yesterday

This happens because the build configuration was at some point "split" so that the debug and release configuration have separate entitlements. That's not Xcode will do on it's own, but it can be configured that way. I suspect that happened by accident at some earlier point.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

My app refuses to run a print job
 
 
Q