Hello,
I have an application that accesses the printer to print what the user writes.
Therefore, in App Wrapper I have the “Printer” entitlement checked.
Last night I submitted a new binary, and this morning I got a message from MAS telling me to remove the “com.apple.security.print” entitlement.
I answered saying that removing the “Printer” entitlement the sandboxed app does not print.
The reviewer answered saying:
[quote]Hello,
Thank you for your response and patience. It would be appropriate to remove the following entitlement and resubmit for review:
“com.apple.security.print”[/quote]
Where do I find such com.apple.security.print and how do I disable it? I looked to the plist, but I cannot find such string, and the METAs in itunesconnect do not contain any entitlement.
#1 Submit an appeal; if your application has a print function, as you have stated removing this entitlement will prevent your product from printing.
#2 You can remove the printer entitlement; by unselecting “Printer” from the “Hardware Access” on the “Capabilities” pane in App Wrapper. You may then want to remove any code that is used to “Print”, otherwise you’ll get another rejection complaining that your application can’t actually print.
You can forward this link onto the review team, to show that according to Apple’s App Sandbox own documentation; you NEED this key in order to be able to print.
I would suggest that Apple are not suddenly trying to stop Mac apps from printing. They know what the com.apple.security.print entitlement does, so telling them what it does is just going to be patronising and rude. There’s something else going on here.
How does your app print? Is it via the standard File > Print menu?
Exactly what does your app print? Is it clear what the app is going to print and when it’s going to print?
Is it clear your app prints at all? They will always tell you to remove entitlements that they don’t think your app will use.
Apple have flagged this for a reason, I’m sure that clarifying things will lead to a resolution.
@Gavin Smith
The app prints from the standard File > Print menu.
The app prints the content of a textarea.
The app prints when the user selects File > Print, and clicks the Print command.
The app prints all right the content of the textarea.
The code used is the standard one (LR).
[Edit] By the way: a few days ago an app of mine using the same code for printing and the same enitlement went thru without any problem.
Likewise, and that’s the way it should be for printing. I’m sure this will easily be fixed. Either the reviewer has misunderstood something (they are just human, after all) in which case your appeal will hopefully be successful. Or there’s something unusual here that makes them think that printing in this app is unusual in some manner. I’m sure it will be resolved quickly, either way.
The only thing I see missing from my part, is that in the META > “App Sandbox Information” section of itunesconnect I did not explicitly added a request/description of that entitlement (in the past I never added it for other apps with print capabilities).
Let us hope and see the result of the appeal.
Sometimes these topics may help other developers to avoid unexpected problems and to know “new” requirements from MAS.
Thanks again.
[quote=434836:@Carlo Rubini]The only thing I see missing from my part, is that in the META > “App Sandbox Information” section of itunesconnect I did not explicitly added a request/description of that entitlement (in the past I never added it for other apps with print capabilities).
Let us hope and see the result of the appeal.
Sometimes these topics may help other developers to avoid unexpected problems and to know “new” requirements from MAS.
Thanks again.[/quote]
I started my first submissions without such explanations and got rejections. then i started to always add these explanations and never got a rejection of such type again.
[quote=434834:@Carlo Rubini]@Sam Rowlands
I have sent an appeal. Let us see.[/quote]
Good luck mate, there’s nothing worse than rejections of this type.
You may disagree with my approach to resolving this issue; it’s not done because I want to be rude or stick it to the man, it’s done because I’ve faced many rejections over the years, and in the last couple, my experience has taught me that rejections of this type; where the reviewer is asking Carlo to potentially remove standard functionality, either end with you removing the functionality because of an incompetent individual, or appealing to either be approved or at the very least to provide some reasoning as to why this functionality should be removed. Gone are the days when Reviewers treated developers like human beings.
I would also like to clarify that I do not consider Reviewers as representatives of Apple, they’re individuals who’re contracted by a third party (who’s contract by Apple) to get as many “Reviews” processed as quickly as possible. While it’s great that you often get a result within a couple of days (compared to weeks as before), the level of communication and basic understanding of what a Mac App is, from the current crop of reviewers is down right atrocious. I don’t honestly know what’s worse, lengthy review times, or quick blunt no negotiating review times.
I also find it more helpful to provide Apple’s own documentation when disputing a rejection; as a couple of times, in most difficult cases, I find that providing any appropriate Apple documentation to substantiate why I have done something the way I have, has resulted in an approval.
And so, after making the appeal, they answered that the “com.apple.security.print” entitlement had to be removed. Just that, no explanations.
So I made a new appeal, (a) emphasizing the point that without such entitlement the app would not be able to print, (b) sending a new screenshot showing the system-message telling that the Print function was not allowed; and finally (c) asking them why the users of my app should be denied the chance of printing their texts.
Eventually this morning I got this new message:
The app went back to “in review” and was quickly “ready for sale”.
Thanks to all.
No explanations, just the two lines I quoted. But I noticed the wording: “Apple Review Board has completed their review…”. To me it seems that they reversed the previous one. Whatever! My frustration is over.
But there is a point that struck me. In the METAs of itunesconnect, in the list of entitlements, there is no mention of “com.apple.security.print”; and in the rejection they said something about the no-need of adding entitlements such as USB and printer; unfortunately I cannot be more precise because I cannot anymore access the rejection posts since the app has now passed the review.
Hmm… It seems like they may have made it so that newer versions of the macOS don’t require that entitlement; but I can tell you from experience, that some versions of the macOS will not allow a Sanboxed application to print without it.
Anyway; I am glad that it’s resolved for you know and thanks for providing us with as much information as you can.