As you might know, I’m currently in the process of getting flickery into the Mac App Store. I know, I’m a little late to the game. I originally had planned to have flickery in the Mac App Store when it first launched, however, time was not on my side.

Anyways, flickery has been rejected from the Mac App Store. For two reasons.

Reason for Rejection #1: Private API.

I’m using a great framework called BWToolkit in flickery. It’s a UI framework with HUD-style buttons, scrollbars, etc – you get the idea.

Apparently, it uses private APIs for its NSTokenField subclass (which I was not aware of at the time of submission and – thank god – am not currently using in flickery).

I get why usage of private APIs is discouraged (or simply, not allowed) – they might not be there in a future release of the OS, there might be something wrong with it in certain cases, etc and I’m happy to comply with Apple on that matter. However, this next point kind of bugs me.

Reason for Rejection #2: Installing of Plug-Ins for iPhoto and Aperture.

The Developer Agreement states:

 

3.3.2 An Application may install or run additional interpreted or executable code (e.g., plug-ins and extensions) for use in conjunction with the Application as long as such code:

– does not change the Application’s submitted binary or would not otherwise be considered an Update (as determined in Apple’s sole discretion); and

– does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the Mac App Store.

 

I guess that is applicable for video conversion-applications which need to download some kind of codecs or frameworks that can not, for legal reasons, ship those codecs with it. Some of these applications do not work without those codecs and demand you download them, otherwise you have to quit. I do understand why Apple does not want that. It’s inconvenient to the user, it’s tedious and it just plain sucks, in my opinion.

However, if you ship a photo sharing application it only makes sense to include plugins for iPhoto and/or Aperture, for example, so users can access their photos right from the source. They are not installed automatically, but at the user’s request (if they were installed automatically, that would be another story).

It does not change the submitted binary and it certainly does not change the primary purpose of the application (by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the Mac App Store). One of the primary purposes of the application is to get stuff on flickr. With a plugin for, say, iPhoto, it makes it very convenient for the user to do so.
The features and functionality are there anyway, uploading works both with plugins not installed or installed.

If this is a violation of the rule, why not just disallow plug-ins altogether? What the flickery exporter plug-in for both iPhoto and Aperture does is the very definition of a plug-in, don’t you think?

A Solution?

It’s no solution, it’s more of a workaround which other applications currently use as well.

I re-submitted flickery with the plug-ins removed, albeit with a button to go to a webpage to download the plugins. flickery will install them for you if you drag them onto it (I hope they’ll allow that).

However, I don’t go down without making some sort of noise. I did write an eMail to the Mac App Store team regarding this, asking for a re-evaluation of this topic.
If they (however unlikely) do change their minds, I will be happy to re-add those plug-ins to flickery.

Fingers crossed.

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]