entitlement woe!

[J. Baker]

Ok, so I updated Sprite Monkey and sent it to iTunes Connect for approval. I was surprised today to see in my email that it was rejected. I logged in to iTunes to find out why. It appears that even if you follow Apple's sandboxing, you may still get rejected.

My app uses the following entitlement in order to write the coordinates files, com.apple.security.temporary-exception.files.home-relative-path.read-write /. It was noted that this entitlement was not appropriate for my app. But of course, I've done testing with sandboxing with my app and will not work without it.

Here's an example why. When your app writes files to a users Mac, you have to create an entitlement for the SaveFileRequester(). Well, this only lets you export a single file. But my app also creates coordinates files, if the user chooses to. He or she selects one of the OptionGadget's for this but if your app is sandboxed, it will not export since it wasn't listed in the SaveFileRequester() and needs the temporary entitlement.

So it appears that Apple isn't letting anyone just use this temporary entitlement even though I followed their rules on this whole sandboxing method. I'm now left with two apps that I can no longer update on the Mac App Store. The other is because sandboxing doesn't allow keyboard emulation for my other app.

So what should I do? I don't like the thought of not selling my apps on their store as it's good advertisement. And even if I do sell my apps else where, the people who previously purchased them don't get free updates as I have no idea who they are, since Apple controlled this through their store. I may end up with angry customers because they would then have to repurchase the update.

[wilbert]

Maybe you could save a zip archive if you have multiple files ?
It's a bit strange that you can't save files in a normal way.

[J. Baker]

Maybe you could save a zip archive if you have multiple files ?
It's a bit strange that you can't save files in a normal way.

Yeah, I could do that but the way sandboxing works, I believe, it would only let me create a zip file and not the other files to pack into it. At least not from a single requester. Also users may not like that method. The only other thing I can think of is creating two SaveFileRequesters but I'm sure users may not like that either.

[J. Baker]

I changed my entitlement to the following and uploaded a new binary...

<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
<string>/Users/</string>
</array>

Hopefully this will pass as it only reads and writes to the "Users" folder and directories below.

[J. Baker]

Well that didn't work either. The app went back into review and got rejected for the same reason. Their responses are very vague and give you nothing to work with.

[IdeasVacuum]

The problem is that the people who judge these things have no common sense, which is after all par for the course with Apple - beautiful yes, practical? Not always.

You certainly should be entitled to know who your customers are. If a customer has a complaint/suggestion, who handles that, the original developer or Apple? Extremely poor that the SandBox does not apply all the Apple rules.

Is it possible to ask the User to enter an output destination folder once (when the app is installed?), then always save files directly to the folder without requesting - I know, talking gibberish but it might spark another idea that would work.

Do your existing customers not have a license/serial number or something similar that they could use to prove they are paid-up Users of your apps?

[J. Baker]

The problem is that the people who judge these things have no common sense, which is after all par for the course with Apple - beautiful yes, practical? Not always.

You certainly should be entitled to know who your customers are. If a customer has a complaint/suggestion, who handles that, the original developer or Apple? Extremely poor that the SandBox does not apply all the Apple rules.

Is it possible to ask the User to enter an output destination folder once (when the app is installed?), then always save files directly to the folder without requesting - I know, talking gibberish but it might spark another idea that would work.

Do your existing customers not have a license/serial number or something similar that they could use to prove they are paid-up Users of your apps?

Maybe I could try a PathRequester() and see how that works.

No license. I don't think apps on the app store can have these. Which doesn't help piracy at all but again, everything can be cracked eventually. But it would be nice for tracking clients, like you're talking about.

[wilbert]

I read every application gets its own folder it has full access to and also that if the user drags a folder onto your app, the folder is added to the sandbox.
Isn't that enough to work with ?

[J. Baker]

I read every application gets its own folder it has full access to and also that if the user drags a folder onto your app, the folder is added to the sandbox.
Isn't that enough to work with ?

I didn't know about the drag folder option. Will have to try that out. But I did send a response to the "App Review Board". Will see how that goes.

[wilbert]

I didn't know about the drag folder option.

I read about it here
http://developer.apple.com/library/mac/ ... Depth.html

Most likely you would need a file promise
https://developer.apple.com/library/mac ... Files.html
(the Dragging File Promises part)

[J. Baker]

I didn't know about the drag folder option.

I read about it here
http://developer.apple.com/library/mac/ ... Depth.html

Most likely you would need a file promise
https://developer.apple.com/library/mac ... Files.html
(the Dragging File Promises part)

Thanks for the links!

[spacebuddy]

I just got rejected for the same reason

Why allow us to use this entitlement, then reject it?