Shoebox applications and the Mac App Store

tl;dr: If your application automatically saves user data and files to anywhere other than the visible folders in the users area; your application can be rejected.

There are only a handful of folders that we can utilize to create these kind of applications, “Photos”, “Movies”, “Downloads” & “iCloud/Mobile Documents”. For Cardsmith (a greetings card application), none of these are applicable.

There is a temporary entitlement which should allow this function; however it’s usage is for older applications migrating to the App Store, and therefore most likely you’ll be rejected for it.

So what’s the solution?
At this juncture, I don’t know the perfect solution. I have devised a solution for one of my apps that creates a subfolder within the “Photos” folder, I don’t think it’s the correct place, but out of the four listed above, it seems the most appropriate. I have also filed a feature request at Apple for a new entitlement that would solve this problem by granting us access to a specific subfolder within the user area, a subfolder that’s only for our applications, so we don’t have complete unrestricted access.

A terrible solution:
Is to let the user choose the folder, store this in a Security-Scoped Bodgemark. Then when a user browses this folder, you gain access, read everything and close access. There are several issues with a SSB,

  1. You have 90 seconds before it expires, when it expires, you lose access to that folder until the application is restarted. Repeated expirations can crash the computer.
  2. If you need to read or write anything to that folder, even reading something like the file size, requires access and all reading/writing to be completed within that 90 second window.
  3. Apple’s own imaging API’s are not 100% compatible.
  4. They break easily; leaving your application unable to access that folder and forcing the user to reconnect to it, when they break, you can’t even get a file path or file name from it, so you can’t even guide the user to where the folder is (unless you store ancillary meta data yourself).

Remember these are only the issues that I’ve personally experienced with SSBs.

I will let you know if Apple accept my compromise solution of storing the data in the “Photos” folder.

If you are designing a Shoebox style application and intend to sell in the Mac App Store, please consider an alternative application model. If something doesn’t change at Apple and someone else doesn’t come up with a better solution than above, then the prospects for Shoebox applications is pretty bleak on the Mac App Store (Ironically nearly every single iOS application could be considered a Shoebox application).

I hope that this makes sense. In all irony it was the Mac App Store that forced us to move our data to the Application Container in the first place.

Sam. When I google “shoebox application” I get only a reference to a specific application which is a photo-storage app. Are you referring to that specific app, or what do you mean by “shoebox application”?

I think a “shoebox application” is one that is self-contained… the only data is uses, is data it creates …

as in “everything fits in a shoebox”

Thanks, Dave. So my app creates a DB and stores it at SpecialFolder.ApplicationData.Child(“myCompany”).Child(“myDB.sqlite”).
The users then create data which is added to the DB. Is this a shoebox app?

[quote=404642:@Roger Clary]Thanks, Dave. So my app creates a DB and stores it at SpecialFolder.ApplicationData.Child(“myCompany”).Child(“myDB.sqlite”).
The users then create data which is added to the DB. Is this a shoebox app?[/quote]
In my opinion… yes

Then I’m even further confused by Sam’s post. The app I mentioned was just approved for the MAS about 2-3 weeks ago. No mention was made of a wrong storage location. I don’t understand why he feels we cannot still use SpecialFolder.ApplicationData. (or am I misinterpreting what he is saying?)

I am confused as well… but the first line of his post seems to indicate that Apple (or specific reviewers) now deem “ApplicationData” inappropriate … which would be ironic given the name of the location.

For me it say can and not will, so there could be other factors.

For example, Snagit (screen grab/recording), create a folder called Snagit under Documents, under Snagit a directory called ‘Autosaved Captures’, on my mac it’s size is 3GB. For a normal user is easy to go to Documents/Snagit/Autosaved Captures and delete whatever to free space, but is not easy to go to /Users/UserName/Library/Application Support/TechSmith/Snagit/Autosaved Captures, to try to free 3GB of data.

My guess is that they don’t want ‘user generated data/files’ in other places besides those 4. That way a normal user can backup or free space only dealing with those directories, even autosaved files.

I posted this yesterday in a separate thread: https://forum.xojo.com/49835-program-deletes-it-s-own-data-folder/p1#p404485

[quote=404485:@Eduardo Gutierrez de Oliveira]I didn’t remember but this is actually the term Apple uses:

(search for “shoebox”)

From that same (official) document:

So, why require now to manually select the location? (traditionally you were allowed to let the user change the default location if the user wanted, but weren’t required -OR EXPECTED- to ask for it).[/quote]

Could this be to force usage of iCloud or to enforce that only a handful of folders are user at the homedir level?

This could raise some serious legal issues … Apple (or anyone else) cannot force an entity (person or company) to store their data in any particular place. I personally refuse to use the Cloud (regardless of who controls it). The data is mine, I will store it where I want, share it with whom I want and do it in the manner that I desire.

Should Apple (or anyone else) at some point say : The computer you bought from us will no longer allow data to be stored internally, and you must have a “cloud” account, and all data transactions will take place via ethernet/wifi/bluetooth to our servers"

There will be (and should be) a huge revolt.

Not saying that NOBODY should use cloud services, just saying the choice to do so or not must remain viable.

If I understand it correctly, Sam’s opening sentence contradicts everything I’ve been told by Xojo about how to store data. And, as I previously indicated, I recently had an app approved for the MAS which stores data in the ApplicationData location. I would like to hear someone from Xojo, Inc. weigh in.

I didn’t mean we’d be forced. I meant that by making it harder to do, developers would just start using iCloud directories (that seem to be acceptable) and/or users would start preferring applications that don’t bother them with permissions.

Perhaps “pushed” is a better word. Apple won’t ever make it mandatory, but it can make it more attractive by simply making other options less. Like today when you download an app not from the store, it’s a bother for the user to know how to launch it.

Sam’s opening sentence contradicts everything APPLE has told us until now for Shoebox applications. It’s also a recent development, as he’s the first I’ve seen hit by it. It may be a new policy, or it may be a temporary confusion or it may very well be changed back.

No development documentation seems to have been modified for this, even in the betas. Let’s see how it develops (although the advice from Sam, I think, it’s the best bet for the time being: Wait and see, but stop work on this in the meantime)

Okay, so I apologize for any confusion.[quote=404642:@Roger Clary]Thanks, Dave. So my app creates a DB and stores it at SpecialFolder.ApplicationData.Child(“myCompany”).Child(“myDB.sqlite”).
The users then create data which is added to the DB. Is this a shoebox app?[/quote]
I personally would, but it’s also up to the individual App Reviewer, as to what they determine. If they don’t see it this way, you should be fine. If they, then you’ll face the same situation as I have.

It’s the Apple App Store, they can do what they want. The App Store is not the only place in town to sell software.

What this changes is where you store these files, according to this App Store rule, they must be in a user visible folder (a subfolder of their home folder). The trouble is that this App Store rule contradicts with the App Sandbox guidelines and forces us to either try and seek approval for a temporary entitlement, use Security-Scoped Bodgemarks or to avoid the App Store. Mind you, this only applies if an App Reviewer thinks it does.

[quote=404664:@Eduardo Gutierrez de Oliveira]It’s also a recent development, as he’s the first I’ve seen hit by it. It may be a new policy, or it may be a temporary confusion or it may very well be changed back.

No development documentation seems to have been modified for this, even in the betas. Let’s see how it develops (although the advice from Sam, I think, it’s the best bet for the time being: Wait and see, but stop work on this in the meantime)[/quote]
I don’t know when this was introduced, all I know is I got stung by it. And as for documentation, the rejection reason 2.4.5 Hardware compatibility doesn’t say anything about this. Which means that the App Store reviewers are working off different documentation as to what’s publicly published (which quite frankly isn’t surprising).

For this particular application, I’m going to use a subfolder in the “Photos” folder (as it appears to be the most appropriate and there’s a read/write entitlement for the Photos folder), I’ll let you know how I get on.

Does this make a bit more sense now?

p.s. I created a new thread as I didn’t want to keep hijacking that one, sorry.

Is that what it requires to make files be saved to iCloud?

The process is kinda awkward; you have to use API for this, but in reality, there is a folder in the users area where these files are stored.

I’ve often wondered about adding this functionality to my own apps; but for the apps that I’d consider, it’s not really possible without a headache (i.e. a database driven application would be perfect, but again you have to use Apple’s API to access the database, and from what I read online, it’s anything but stable).

Follow-Up.

I submitted a feature request to Apple to a special Shoebox entitlement, one that would allow us uninterpreted read/write access to a specific folder within the user area, specifically for our application.

My request was denied and according to Apple, the official way for 3rd Party Shoebox style applications to work, is to use a Save dialog (allowing the user to choose where the data is stored) and a Security-Scoped Bodgemark. If you know me in any way, you know how much pain and suffering SSBs have caused me and how I can’t tell people enough to avoid these. There are simply far too many limitations, incompatible API, not to mention a lot of work to update an existing application to utilize them (as every single read and write to the folder, must have access granted and be completed within 90 seconds).

How does Apple’s Shoebox style applications work? Photos has unrestricted access to the “Photos” folder, while iMovie has unrestricted access to your entire computer.

I’ve tried to argue my point and will keep you’ll updated.

Addendum: There is one method I’ve thought of that might work, but it’s untested. After you’ve asked the user where they want to create their data folder, store the folderitem into the Apple Recent Items (you don’t need to display the menu), the Sandbox Kit uses the Apple Recent Items. In theory it would mean that the application would have unrestricted access to that folder, however you’d not be able to show the “Open Recent” menu or add any other items to it (incase it knocks out the folder).