Archive for June, 2012

The Mac App Store Blues

Monday, June 4th, 2012

We here at Pubblog have a number of products on the Mac App Store. It’s been great. It’s a great idea. Thank you Apple for providing this universal, integrated, easy to use, safe venue for independent software developers.

We also applaud The new Mountain Lion requirements for a developer certificate, which means that everyone, including Apple, knows who you are, and if your app does anything bad, it can be purged from everyone’s computer. This is an excellent idea, and one we are happy to comply with.

However, we have serious problems with the new, as of June 1st, sandboxing rules on the Mac App Store.

One of our products is called FileMyFiles. It has been on the Mac App Store pretty much from the beginning. One of its features is the ability to remove an application along with all of the files related to that application. Of course you must have Administrator privileges in order for it to work. This feature was rejected by the Mac App Store, so the App Store version does not have it. However the slightly more expensive version sold on the FileMyFiles web site still does include this feature.

There is also a feature for making file name and folder name changes to a collection of files and folders. Recently a bug that affected changing spaces to other characters, such as underscores and periods, was reported by a user. The bug was quickly fixed and tested, and a new version was loaded on the Pubblog Store, and submitted to the Mac App Store.

A week later, this bug fix to the App Store version was rejected, because of yet another FileMyFiles feature. The feature from which File My Files derives its name enables a user to organize all of the files in a particular folder, into separate subfolders according to file type. The user chooses the folder to organize, and the program then creates whatever subfolders are needed and moves the files into the appropriate subfolder. You can also unfile your files, which will put them all back where they came from and remove the subfolders that were created.

The bug-fixed app was rejected because the user does not specifically ask, via a standard Save As dialog, to create each of the file type subfolders, or to remove said folders. This, even though the user has already specifically requested that File My Files perform its tasks on a particular folder that the user has chosen.

This is a rule that is part of the new sandboxing requirements. It seems they have been put into effect, not only for new apps, but for existing App Store bug fix releases. However, all previous bug fixes have been accepted, and the current version of FileMyFiles with the unfixed bug has been allowed to remain in the store so far.

If this continues to be the policy, we will be forced to remove FileMyFiles from the App Store rather than have a version out there with a bug we are not allowed to fix.

Another app, MailSteward, uses the SQLite database engine, which creates a journal file as a database is being updated. Since the user has not authorized the creation of this file, even though it is in the same location as the user has chosen for the database file, it violates the sandboxing rules. So that app too cannot exist on the app store.

A new unreleased app downloads thousands of files into a folder chosen by the user. The sandboxing rules dictate that the user must authorize the downloading of each of the thousands of files, which would make the app useless. So this app also cannot be in the app store.

In short it looks like the new sandboxing rules will eliminate the majority of utility type programs which have anything to do with the file system. Or the app must be crippled and/or given a dumbed down user interface, for which the developer, not Apple, will be blamed.

I do not understand how these Mac App Store policies serve the customer, or Apple, or the developer, in any way.