Mac App Store : Entitlements?

I have decided to dip a toe into Mac apps in the App Store.
My main app does a lot of things that I am sure wont be allowed under Sandboxing, such as opening pictures from any location, saving in any location, creating files in any location (all chosen by the user of course), accessing clipboard, printing.
Not enough icons probably. Maybe more

Do we have any guides about what needs to be changed about an app to make it App Store friendly, and the process to get it out there?
What are the gotchas?
I have an account and can codesign.

As long as you use GetOpenFolderItem and GetSaveFolderItem, the user who has access to a resource can open wherever he wants and save wherever he has access to. What IS forbidden is to GetFolderItem outside of SpecialFolder.Temporary and SpecialFolder.ApplicationData.

You may require temporary entitlements for Documents or Pictures to silently open and create there, and that is usually granted.

Accessing Clipboard and Printing are just fine as long as you use the Xojo methods.

I strongly suggest you avail yourself or try App Wrapper from http://ohanaware.com

It will allow you to sandbox your app in no time and without the need of extra Aspirin. Better yet, Sam Rowlands who created it is a living book about the MAS. He has helped me considerably when I started.

For the gotchas and process, as away. There are many people here who can help.

Finally, never fear the reviewers. They can be strange, but overall, their job is to make sure your baby dresses pretty before the curtain call. I tend to consider them like the ultimate beta testers. They have saved my skin from releasing a flawed product on a couple occasions. After all, if they reject, just come back with a corrected version until it passes.

I gather I need to check the sales receipt somehow: did I read that there was an MBS thing for this?

(I have removed the current licencing code that does a call home)

[quote=245543:@Jeff Tullin]I gather I need to check the sales receipt somehow: did I read that there was an MBS thing for this?

(I have removed the current licencing code that does a call home)[/quote]

Don’t tell anybody : quite a few of us did not even bother with it and we are just fine. You need that only if you plan on using in App Purchase, and for that too, MBS has a solution.

Yeah it’s in MBS: https://monkeybreadsoftware.net/storekit-appreceiptverificatormbs-method.shtml

Thanks Michel, but

Doesn’t that mean that people can just hand out copies?

Yes it does.

Aha.
Then I suspect that the addition of

[code]dim a as new AppReceiptVerificatorMBS

if a.verifyAppReceipt then
MsgBox “My receipt is valid”
else
MsgBox “My receipt is invalid.”
end if[/code]

Isn’t going to be too much hassle, (apart from the testing)

It does not hurt adding receipt validation. But before worrying about people handing copies, one should worry about getting goods in the glasswindow.

It is far more important to sell well IMHO.

Sam just recently had an update rejected for not validating the receipt I’m pretty sure.

Yes he did.

But having no receipt at all is different from having one and not validating it.

I am not advocating having no receipt. I just happen to have elected not to bother with it, just like Sascha Schneppmuller.

I do about half of my sales out of the MAS already, and there is no such thing as a receipt there.

Confused… I thought there would always be a receipt from a MAS purchase?

There is no such thing as a validate receipt in the version I sell outside of the MAS. As far as I can tell, in the 20+ years I have been in business, it has not killed it.

Piracy is a fact of life, I learned to live with it. I am convinced people who use and pass pirated software never buy anyway.

That said, it cannot hurt to prevent more than x amount of copies in the MAS.

Nor mine.
It uses my own serialisation, but that wont wash in the MAS

In the MAS, you have to accept the fire and forget logic. You won’t know who bought unless they contact you for support.

My apps don’t need much support and I do not serialize anyway. Well, the first program ever I sold with a license number is RubberViews encrypted :p.

You are correct. If it came from the Mac App Store (even free) there will be a receipt.

I did.

I ended up creating a 64-Bit adaptation of @Thomas Tempelmann’s Receipt validation code, which I then modified to suit my needs. It will have to be completely re-written as all of the API has been depreciated, so we don’t know when it won’t work.

The code is available from the following link.
http://www.ohanaware.com/xojo/ReceiptTester.zip

The main things to worry about when shipping on the Mac App Store
#1 As Michel pointed out; you can only access files in either the “Application Support” or the Temp folder, all other files require a open or save dialog. There are some exceptions, such as access to the pictures folder, movies… Do not be tempted to give your application access the root directory; this will result in rejection.

#2 AppleScript; avoid it if you can. Trying to script Finder, System Events or the Terminal will result in Rejection. Some apps need to use new Entitlements for Apple Script, while others have to use old Entitlements. App Wrapper does it’s best to figure out which one an app should be using.

#3 Ensure your own sales mechanism and update mechanism are disable for the App Store. Apple’s don’t even like you informing customers that there is a new version available (although there are ways around this).

#4 You can’t sell things outside of the app store, in your app store application (unless you’re a big enough company; at which point you can pretty much do what the fuck you like).

#5 Pity the reviewers, I got pretty irate about some of the stupid rejections I’ve had (Couldn’t ship a V2 app because it was too similar in name and function to a v1). Those people have a negative job; which is to find any little reason as to why your app can’t be there.

#6 If you’ve got money, go to WWDC, meet the App Store team. I’ve heard that if you get on their good side, you can become a priority case, which means less rejections and also your apps get reviewed quicker. I’ve heard this twice from two different developers.

#7 This great community we have here; are your biggest allies. Anything you have trouble with or just questions; we collectively the developers of Xojo will know or know where to find out :slight_smile:

#8 Application Restoration; if you want to maintain a Recent items list or auto-reopen documents for the user. You’ll need special code; I have written the “Sandbox Kit” for this purpose. http://www.ohanaware.com/sandboxkit/

Thanks Michel, that certainly explains the smell and leathery skin texture :slight_smile:

:wink:

Could you expand on this? A few days ago I was told on this forum that we can. Thanks.

Hmmm… Looking back at it now, I can see why.
in fact it’s almost impossible to explain using an iPhone… Perhaps I should switch to Android?

If your selling digital items; you must use Apple’s mechanisms and they take their 30%. You can’t create an app to sell digital books and use your own credit card processor (5%), and have that app distributed on the App Store.