OS X Lion App Sandbox and its implications on applications

Photo credit: livingindryden.org

I’m very excited about the new operating system and the APIs it holds for developers.

One new feature that is going to be very popular amongst users and holds real benefits for them is the App Sandbox.

What is App Sandbox?

Entitlements

Basically, the App Sandbox needs developers to specify what kind of access to user data an application they create needs.

You basically start with no privileges (so called “entitlements”) at all and work your way up for what your app needs. 
Does it have open or save panels? You need an entitlements for that.
Does it need access to the network? More entitlements.
Does it need to access iCal or Address Book? Even more entitlements.

Apple states there are currently 15 entitlements, but the list may change in the future.

Containers

For data saved by applications, like preferences files, Core Data storage, “Shoebox” data, basically everything except Documents the user saves or are autosaved by OS X Lion, each application gets its own Container in /Users/yourname/Library/Containers/, like /Users/matthias/Library/Containers/at.EternalStorms.ScreenFloat/

An application that has no entitlements for file system access can not access anything beyond that folder without the user’s consent (a user can give their consent with selecting files in open or save panels or by drag’n'dropping items onto or out of the sandboxed application).

Deny, deny, deny!

Anything an application requests it doesn’t have the proper entitlement for gets denied by a process called sandboxd, the sandbox daemon. It manages the sandboxed applications and their access to things they are or aren’t entitled to.

This is what your Console looks like when something gets denied:

27.07.11 16:56:14,480 sandboxd: ([2460]) screencapture(2460) deny file-read-data /usr/sbin/screencapture

XPC

XPC helps take the sandbox paradigm even further, making apps even more secure. Instead of having one executable that does it all (access the web, access iCal data, access Address Book data, write stuff to disk, read stuff from disk), a developer splits these tasks up and basically creates for each of these operations a executable with just enough entitlements to do its work.

So if you have an application that can access your Address Book and the web, there’s nothing from stopping the app, had it been compromised, from sending that data to a server.

However, if you have two different executables, one with just the Address Book entitlement and another with just network access, it’s not that easy anymore for intruders to do their dirty business.

XPC lets these two executables talk to one another, inside their shared sandbox.

What is App Sandbox good for?

Something that has been said a thousand times in the WWDC sessions to make abundantly clear what App Sandbox is good for:

It’s a last line of defense against evil-doers.

If an application has been compromised, it can’t do anything beyond its entitlements. That’s a very good thing.

So what does it all mean for users and developers?

Users

For users, it’s a great thing to have in terms of security and privacy of your data and I think every user should be excited about it. I know I am. It’s a great solution to a problem that has been dragging on too long, and Apple stood up and took a shot at it, and I think they did very well. For the most part.

In terms of what app developers will be able to make for those users, well, that’s another story which I’ll explain next.

Developers

In general, for most cases, developers won’t have any trouble with the App Sandbox. Version 1.2 of ScreenFloat – which is currently in Review for the App Store – already is a client of the sandbox and I ran into no trouble with adopting the entitlements, what so ever. It does what it does, just like before, but now, it’s safer, and I’m very excited about that.

What worries me, however, and, judging from what I’ve read on Apple’s developer forums, worries quite a lot of other developers as well, are the so-called temporary entitlements.

Temporary entitlements are for certain cases where it’s not really safe to do something, but Apple hasn’t figured out a safe way to let the app do it yet, so they made an entitlement for it. A temporary one.

Let’s take, for example, iTunes. There are a lot of applications out there that can “remote control” iTunes with global hotkeys.
In the background, the application is sending out an Apple Script, or doing its work over the Scripting Bridge, or are sending Apple Events directly (Apple Scripts and Scripting Bridge work with Apple Events in the end, but it’s at a higher abstraction level API wise for developers like me, who have no idea how to create Apple Events in the first place).

For this case, Apple has created a temporary entitlement. Alright, so it works.

What bothers developers however is the term “temporary”. What _is_ temporary, exactly? Will there be a replacement once the temporary entitlements vanish?

Let’s look at a perfect example for this:

GimmeSomeTune and the App Sandbox

Some of you might have read it on Facebook, others may have on twitter, for those of you who haven’t, here’s what happened:

I’ve halted development on GimmeSomeTune because of the temporary entitlements, more so because of the questions I asked above that have yet to be answered by Apple.

But let’s take it one step at a time:

GimmeSomeTune gets notifications with userInfo payload objects from iTunes. That’s no problem yet, since iTunes is yet to be sandboxed. But once it is, it can only send notifications without userInfo payload objects, and that object contains all the necessary information, like Title of Song, Album, Artist, etc.

So GimmeSomeTune, in its current form, could work for some time, until Apple decides to sandbox iTunes. Boom! Rien ne va plus.

GimmeSomeTune downloads artwork and lyrics and sends them to iTunes through the Scripting Bridge. The Scripting Bridge is essentially sending Apple Events to the app you target, in my case, iTunes.

The sandbox allows for Apple Events to be received by an application (without entitlements), but can not send any, without the temporary entitlement. When the entitlement is no longer valid, the main functionality of GimmeSomeTune breaks. Boom! Rien ne va plus.

So what it comes down to is this:

GimmeSomeTune would work right now in its current state, with temporary entitlements and hoping that Apple will never sandbox iTunes so it will continue to send notifications with userInfo payloads (which is doubtful, since iTunes is your digital hub and all, so they’ll be sure to sandbox it at some point, I guess).

But what happens if iTunes was sandboxed?
GimmeSomeTune would break, it would not know what song is playing in iTunes and hence wouldn’t download information and send it to iTunes, rendering the application useless.

And what if the temporary entitlements go away without a proper replacement API?
Again, GimmeSomeTune would break and it couldn’t send downloaded data to iTunes anymore, again rendering the application useless.

Why not just release it and hope for the best?

Sure, I could release GimmeSomeTune with temporary entitlements and hope they stay around forever or that there’ll be a replacement API for them.

But I have to consider what happens if they don’t (which is, in my opinion, 100% certain) – angry users, having paid for software that doesn’t do its job.

I am not willing to take that chance. I will wait to see what Apple comes up with.
And if there is a replacement for temporary entitlements in the works, and when I’m certain GimmeSomeTune will work with it, without the fear of having the application break at some random point in the future due to functionality that is ripped out from under it, only then can I release GimmeSomeTune with confidence and the knowledge that its users will be able to actually use the app.

And I believe this is the right choice.

Sandbox at its finest

Would you like an example of what kind of apps are completely unsupported in the sandbox environment?

Applications that change developer-signed files inside of app bundles that are a) developer-signed and b) running in the sandbox environment.

May I present the worst case Scenario: PresentYourApps

Some of you may know this little app of mine. PresentYourApps lets you hide the menu bar and / or dock for applications you specify, making more screen real estate available. Or at least, it _let_ you.

On OS X Lion, it works some of the time, but I highly discourage you from using it on that system, and I will take down the download link in the next couple of hours.

I discourage you, because it breaks apps you use it on.

I got an e-Mail from a user who tried it on Preview.app on Lion, and after he restarted Preview.app, it crashed on launch. Luckily, PresentYourApps keeps backups of the file it edits, so the user could make Preview.app work again, but it was scary.

Well, PresentYourApps has been long overdue and begging for an update, but because of these circumstances, I decided to discontinue working on it all together and removing it from my website, since it will do more harm than good on Lion systems.

 

If you have any thoughts regarding all of this, or GimmeSomeTune especially, please be sure to leave a comment or contact me in any other way!

Thank you kindly for reading,
Take care,
Matthias

Follow @eternalstorms Follow @flickeryapp Follow @screenfloatapp Follow @gimmesometune

 

Ready for Lion

As the release of OS X Lion comes closer and closer, you’re maybe wondering if Eternal Storms Software is ready for the new cat.

Yes, all my software available on the Mac App Store will be ready for Lion.

flickery

flickery is, in its current version (1.9.24), not ready for Lion, but the update to make it compatible with it (1.9.25) is in review, so once it’s reviewed, it will be ready for Lion.

ScreenFloat

ScreenFloat is ready for Lion as of version 1.1.1! I’ve tested every aspect of the app and everything seems to work just as expected.

GimmeSomeTune

As you might know, GimmeSomeTune is not yet available, but I wanted to let you know that I’m writing it for Mac OS X Snow Leopard 10.6 and OS X Lion. I’m constantly booting into Lion to test if what I’m working on is running on Lion just as well as on Snow Leopard.

 

A good website to keep track of software that is (or is not) compatible with Lion is roaringapps, it gives you a great overview of lots of software and its status regarding Lion.

Take care,
Matthias

 

Another 180 turn in GimmeSomeTune

One 180 turn plus another 180 turn means – we’re back where we started.

A few months back, I said GimmeSomeTune would make a 180 turn by using Gracenote as its source of information (lyrics, song info, artwork).

Although I really wanted this to happen, for all the reasons I mentioned in that previous blog post, it doesn’t seem like it will happen. I’ve contacted Gracenote numerous times and never heard back. Either they’re very, very busy or they just don’t care and don’t want my business. So be it.

So be it!

I’ll do what lots of other apps (including GimmeSomeTune) do – turn to websites that have the according information available. I’ve done it before, I’ll do it again – only better. I’ll use several sources for lyrics and artwork, many of which you, the users, have suggested – thank you for that. I have several sources for lyrics and artwork, so if one service goes, there’ll be a backup service I can turn to.

Truth be told…

I really was looking forward to using Gracenote, because they do offer a great service.

When it became clear that Gracenote couldn’t be bothered to at least write me a “buzz off” e-Mail, I looked into other options. I still have no clue what Gracenote is charging, but it can’t be more than what the others are. It is really hard for an indie developer to use these services and not go hungry while doing so.

Who knows, maybe I’ll get an e-Mail from Gracenote some time this lifetime, then I may reconsider.

Status right now

So what’s the status of GimmeSomeTune right now?

Well, I lost a little time due to my work on Records (which is currently exclusively available through the MacBuzzer bundle) which had to be done for the bundle, so there’s that.

That being said, artwork, lyrics, last.fm and song recognition are all working right now, and beautifully, might I add. It’s almost magical.

Now you might ask, great, so when’s the release, because what’s there left to do?

Everything else. The interface, the popup window, keyboard shortcuts and testing, testing, testing (especially for song recognition, which is quite tricky).

One more thing on iPod last.fm scrobbling

In the blog post I mentioned before, I promised you last.fm scrobbling for tracks you played on your iPod. Turns out it’s not that easy to do.
I will try to implement it for the 1.0 release, but if it takes too long, I’ll move on to other things and get back to it when I’m working on a later update.
Sooner or later, it’ll be in there. But I don’t think it’s that important for a 1.0 release to spend a lot of time on it if I want a timely release (which I, and I assume most of you, do). I hope you understand.

 

As always, I’m open for suggestions and feedback, so please leave a comment, contact me on twitter (see below) or write me an e-Mail. Whichever you prefer is fine with me

Thank you for your time and interest,
Matthias

 

Follow @eternalstorms
Follow @gimmesometune

 

My applications and the iCloud

Photo credit: geeky-gadgets.com

iCloud is a big deal for me, and, I believe, for lots of other developers out there as well. Syncing data has become a lot easier with this new service and the according APIs. I once took a glimpse at the MobileMe syncing APIs and my head still spins a little.

What does it mean for flickery?

I’m still thinking of the implications for flickery. I got some nice ideas from users of flickery on twitter and I’m already looking into what is possible and makes sense in terms of flickery.

I could see flickery syncing the items yet to be uploaded or loocking into iCloud’s photo queue and offer an option to upload those items or at least present them in some way in flickery’s upload view.

What does it mean for ScreenFloat?

For ScreenFloat, In a nutshell, it will sync your shots between your devices (I don’t know if a iPhone/iPad version of ScreenFloat is useful, but I’m certainly entertaining the idea of having the shots on, say, your iPad, as well).
It will sync which shots are currently open and floating, which are hidden, which are in your shots browser, it will sync your categories in your shots browser, and their contents.

This is something I wanted to do from the beginning and I’ve been looking into services like DropBox to implement it. Now with iCloud (and yes, I realize it’s still a few months away) it’s even easier, faster, more reliable and more secure to implement.

What does it mean for GimmeSomeTune?

I don’t believe GimmeSomeTune could have any advantages of iCloud in terms of sync. If you find one, leave a comment or write me an e-Mail

Upcoming Stuff?

I have an upcoming app where iCloud will be perfect and will replace a server-client environment with tedious networking stuff. Stay tuned on that

[Update (18.06.2011)]

My good friend and honored developer colleague Christian Kienle wrote about the impact that iCloud may have on his applications on his blog.
It’s an interesting read, especially if you’re interested in how you will benefit from iCloud in the near future.

Follow @eternalstorms
Follow @screenfloatapp 
Follow @flickeryapp

 

Keeping up with me and my software

photo credit: search engine journal

I just wanted to let you know of the different ways you can keep up to date with me and my software and how to get in touch with me (besides eMail, of course).

1. This blog

Obviously, I’ll be using this blog to let you know about stuff that’s going on, coming up or has happened some time ago to keep you up to date on new version of my apps, new apps, and some thoughts of mine on different subjects.

2. Twitter

I use twitter quite a bit and have twitter accounts for my different applications:

Follow @eternalstorms
Follow @flickeryapp
Follow @screenfloatapp
Follow @gimmesometune

Feel free to follow us

3. Facebook

I have a Group on Facebook which you can use to tell us about things you’d like to see, or discuss stuff amongst others!

4. Flickr

Though my flickr stream doesn’t primarily have to do with my software (though I do post preview pics of stuff I’m working on occasionally), you might be interested in what I do besides coding.

5. Last.FM

If you’re like me, you’re having music playing day in, day out. On last.fm, you can see what kind of music I’m into (spoiler: oldies!)

Bottom Line

Please get in touch with me I’m looking forward to all your comments, feedback, inquiries and critique! Thank you!

 

Post-WWDC11-Keynote Thoughts

Another WWDC keynote has come to an end, and boy, what a keynote it was. Those guys at Apple surely don’t fool around!

I really hate to have missed this year’s WWDC. There’s lots of new stuff to be discussed there, and while I will download the session videos once they’re available through the Apple Developer Center to developers, it’s still a completely different thing being there, conversing with other people, sharing and exchanging ideas and thoughts and getting to talk to Apple Engineers.

I’ve attended WWDC two times in the past, ’06 and ’08 and I’m so glad I joined in on that experience. I can’t wait to go again, and I’m sad I wasn’t able to this year…

Now let’s get down to some business and talk about some of the new stuff shown at the keynote.

Lion.

We didn’t get to see a whole lot of new stuff on Lion during the keynote. Most of what they showed was discussed earlier already.

In-App Purchases, Delta updates.

A great new thing is in-app purchases (if the thing with lodsys is settled anytime soon) and delta updates.
With delta updates, unlike “usual” updates, where the old application is replaced by the new one which is downloaded completely, only changes in the software bundle will be downloaded and written over the outdated parts. A huge win in bandwidth limits, speed and convenience.

Autosave, Resume.

Things we’ve already seen include autosave and resume. Both huge features in my book because, YES, why would we have to press cmd-s if we have a computer to do it for us automagically and YES, an application should start off where you last left it.
It’s just common sense and if Apple wants to remove the file system, it’s a no-brainer.

Mission Control.

Just one word – awesome It’s a great evolution of Spaces and Exposé, both features I use profusely and couldn’t imagine living without (although I use it slightly less since I’ve hooked up a Cinema Display to my MacBook Pro as a second display).

Launchpad and fullscreen apps.

Launchpad, well, it’s just a logical step if Apple wants to get rid of the file system as we’ve come to know it.

Fullscreen apps sounds like something I wouldn’t use too often, but who knows, Apple has made it very easy to switch between fullscreen and non-fullscreen apps with the swipe of a few fingers, so with time, I might come around. Right now, it feels kind of unnatural to me.
Going fullscreen was something I did for a short period of time in an app (run a slideshow, go through photos in flickery (shameless self-advertisement, I know), etc.), not something I’d work in for hours.

General thoughts on Lion and later releases.

I think it’s painfully clear where Apple is heading with Lion and subsequent iterations of Mac OS X – away from a file system based operating system to an application based operating system.
Documents will no longer be stored in folders inside folders inside folders but inside the applications they belong to, which, if you ask me, makes sense. To open a document, you don’t need to navigate to the document in Finder but just open the according application and choose the document there, as seen on the iPad with the iWork apps.
There might be a way to still access the file system (kind of like how the Terminal is for users who’d like to access the underpinnings of OS X) but for most of the users, they won’t need to.
A friend on twitter (@freeridecoding) said something that struck me as possible – that Lion will be the last Mac OS that is separate from iOS.

iOS 5.

What can I say except “Boom”? iOS 5 will be a great new release. Here’s a few features I’m excited about (since everything not in the keynote is under NDA, I can only talk about end-user features)

Notification Center.

About time. I’m glad they hired that jailbreak-software-guy, since he obviously knows what he’s doing.

iMessage.

Nice idea, but I’d like to know how they handle SMS now. Is it a different app? Will I have to remember what contact of mine has an iOS device with iOS 5 so I can use iMessage or if they have a, say, Nokia and I have to use the SMS app? Does the iMessage app do this for me? Figure out what device at the other end of the line and send either an iMessage or an SMS?

Reading List.

Great new feature, love it. I’ve been using a bookmark folder and MobileMe Bookmarks Sync for that functionality, but now it will be simpler. Very nice.
Not so nice for a certain developer of a certain Instapaper app. To quote him: ”Shit.” (@marcoarment)

Twitter Integration.

I’ll have to see if this will replace any other twitter app for me. I’m guessing no.

Reminders.

This is an idea I had been thinking about for a few weeks (especially the location-aware tasks.) Too bad for me as a developer, I guess. Great for me as a user since this will be the first to-do list I’ll be using.

PC Free.

Finally. There’s nothing I’ve been loathing more than having to physically connect my iPad or iPhone to my Mac just to update the system software.

Sherlocked.

I just wanted to let you in on my thoughts about this. You might have heard this term on twitter or the general web. My understanding is it refers to a search app in OS 8 times called “Watson“, developed by Karelia Software. They wrote that software, released it and some time later, Apple came out with their search software for Mac OS 8.5 called “Sherlock” which was more or less an exact copy of Watson (which put Watson out of business, more or less, but Karelia Software is still doing great). This is where the verb “sherlocked” comes from.

Apple has done this a couple of times before, one of the earliest with the system 7 menu bar clock, where they copied an independent software developer’s idea and app.

Sometimes, Apple has the decency to buy things instead of just stealing them – like CoverFlow, but sadly, that’s not the case very often.

I think this is “below all pig”, as we say in German (which means an effin’ outrage! ).
I don’t like this. Affected developers obviously have no idea that they’re going to get sherlocked and if their application in question is their only source of income, this can put people and families at risk.

So I’d like to see Apple buy things instead of stealing them, but that’s probably quite unrealistic. I guess it’s an occupational hazard – developing for Apple devices more so than for any other’s.

iCloud.

iCloud is the new digital hub. It used to be iTunes, your local machine. Now it’s the cloud, and I do think it’s the way to go. You want your data everywhere, without having to manually copy files over. You want changes instantly populated to your other devices, so you can work on any device whenever and wherever you want. This is great!

For me, personally, Lion and iCloud are what I’m most interested in now. I’d been hoping for an easy way for developers to sync their users’ data amongst devices, and now with iCloud, we have it!

It will be interesting to see how iCloud develops, especially if it would be possible to share sync’ed data with other users of iCloud for, say, collaborative features. That would be a great next step.

Conclusion.

I have yet to install and try out any of this, I’m currently working on an external project with a deadline due very soon and I just haven’t got the time to install all this new software until the deadline has passed (and I hopefully complete the project, hehe), but I’m looking forward to trying all of this!

In summary, this is what your typical user and most developers (including me – this is me, by the way ) looked like while watching the keynote:

Before the keynote:

During the keynote:

After the keynote:

On the other hand, some developers looked like this while getting sherlocked:

Before the keynote:

During the keynote:

After the keynote:

 

Follow @eternalstorms

 

Some things in the movie “Jurassic Park” that bug me enough to write a blog post about them

Before I rant off, I have to say this: Jurassic Park is probably my 4th favorite movie of all times (the first three being the original Indiana Jones movies, hehe)

It’s got a really breathtaking score by John Williams (he’s a genius, by the way), a great cast and the right combination of humor and suspense. I can’t praise that movie high enough.

That being said, here’s a few things that bug me, in no particular order:
(and I know, they can’t really breed dinosaurs, but let’s assume that they can

#1 – “Even the word “Raptor” means: bird of prey”

Dr. Grant explains why he thinks dinosaurs (in this example, Velociraptors) “learned how to fly” (read: turned into birds). His last argument is, and I quote: “And even the word “Raptor” means: bird of prey”.
That’s no argument at all. If my parents had called me Raptor, would I have been born with wings or would my children be? I don’t think so.

#2 – Dr. Grant has to ask Tim for a dinosaur’s name?

Come on, Dr. Grant has been studying and digging up dinosaurs for years and he has to ask Tim (who as far as I know from the movie has read about two books about dinosaurs or has just learned how to read, for all I know) what the name of the Gallimimus dinosaur is?
If he doesn’t know that, how is he qualified to endorse “Jurassic Park”?

#3 – How come these genius scientists don’t know that some frogs can change sex?

Now, you have those absolute genius scientists who figure out how to create dinosaurs from over 65 million year old DNA. Fine.
But they manage to pick a particular South African frog species that can spontaneously change sex in a “single sex environment” to fix the gaps in the DNA sequence to create the dinosaurs? Couldn’t they have gone with some other frog? Isn’t that something you should consider for security reasons?
Actually, they must have had a discussion about that, because Dr. Wu says “Actually, they can’t breed in the wild. That’s one of our security precautions. There’s no unauthorized breeding in Jurassic Park”.
So if they had a discussion, at least one of those brilliant scientists certainly must have known that the frog they were going to use could spontaneously change sex.

I guess this is to underline what Dr. Malcolm says when they first arrive on the island. “You took what others had done and before you knew what you had you patented it and packaged it and now you’re gonna sell it” and “Your scientists were so preoccupied with whether they could that they didn’t stop to think if they should!”

#4 – The case of the suddenly disappearing earth matter

In the scene where the T-Rex first breaks out, there’s a huge “bug”, to speak in a software developer’s terms.
At first, the ground inside the fence is at the same level as the ground outside the fence, where the cars are. But when the T-Rex pushes the car over the fence down into the tree (with Tim inside), there’s at least a 20m difference in the ground level. How could that happen? The car was turned over by the T-Rex, sure, but in the same place, so it hadn’t been moved to somewhere else.

 

I believe that’s all of them. At least the ones I can remember from the top of my head.
How about you – do you agree? Disagree? Have some other moment you weren’t satisfied with in the movie?

Follow @eternalstorms

 

Introducing ProjectX: ScreenFloat

It gives me huge pleasure to announce the immediate availability of ScreenFloat – an app to increase your productivity on your Mac!

What Is ScreenFloat

ScreenFloat lets you create screenshots that float above all other windows. This way, you do not need to resize or move windows around just to keep a piece of information visible on your display.

 

It also lets you store information for later use with the built-in Shots Browser, which lets you categorize and manage shots you’ve taken with the use of tags, smart categories and categories (which are basically smart folders or ordinary folders).

How to use ScreenFloat

ScreenFloat gives you customizable keyboard shortcuts to do its stuff.

 

By default, cmd-shift-2 will let you create a floating shot and cmd-shift-1 opens the Shots Browser. Creating a floating shot works the same way as creating a selective screenshot (which is cmd-shift-4 by Mac OS X’s default).

What else is there to say about ScreenFloat

It comes with a system service. Which means, when you select text in any Cocoa application (like Safari orTextEdit), you can invoke ScreenFloat’s service to create a floating shot from that. This also has a customizable keyboard shortcut for the user’s convenience. ScreenFloat resides either in your Dock (by default) or in your menu bar.

Availability and Pricing

ScreenFloat is available exclusively on the Mac App Store, a demo is available through the website. You can get it for just €5.99/$7.99! For updates on ScreenFloat, you can follow @screenfloatapp or @eternalstorms on twitter!

 

Let me know what you think in the comments or by eMail!

Thank you and take care, Matthias

Follow @eternalstorms

 

A few improvements I’d like to see in iTunes Connect

iTunes Connect is the interface Apple provides for developers to interact with the Mac- and iOS App Store.
It lets you check the review status of your apps, change metadata and screenshots, request promo codes, review your financials, manage your in app purchases and more. It does those things quite well.

However, there are a few improvements I’d like to see:

#1 – Review Summary

Short of going through every country in the App Store and checking for reviews of your apps, there is no way to get an overview over the reviews of your apps.

An overview would be greatly appreciated – not just by me, I’m sure.
Of course, one could argue that some reviews are not in English, but that’s not really a reason not to have at least a star rating statistic. Also, Google Translate can help you make sense of reviews that are not in a language you speak (and that’s enough most of the time to grasp what the reviewer is saying).
On the other hand, it doesn’t even have to be the content of the reviews if that’s what’s holding them back. Being able to see the star ratings alone would be a great improvement.

Being mailed about new reviews would be nice too, maybe not live, but once every _fill in appropriate timeframe here_, although I realize that would be a huge load on Apple’s servers. Now if they only had a larger server farm…

#2 – Charts Overview

It would be kind of nice to be informed about how your apps perform in terms of charts in different countries – Top Grossing, Top Selling, Top Free, etc.
But maybe that’s just me – I’m such a sucker for that kind of data.

#3 – Price History and Sales Performance

Sure, it may be the developer’s responsibility to keep track of how they priced their apps, when and for how long. But since Apple has some sort of statistic anyway, meaning their daily sales and trends module, why not implement a price history? And add sales performance at those prices, while they’re at it.
Something like: On that day, flickery was priced at €xx and sold xxx licenses. On another day, flickery was priced at €x and sold xxxx licenses.
I believe lots of developers would appreciate such a feature. I sure would.

#4 – Getting in touch with customers

If you get a bad review or a user requests a refund for their purchase, it would be great to be able to get in touch with them – sometimes it is unclear as to why the customer is dissatisfied with your product.
Before the Mac App Store, it was easy to contact your users. Now, not so much.
With the Mac App Store, the developer depends on the customer getting in touch with the former. I’m guessing it’s some sort of data privacy issue.
They could, however, do something like this: When the user rates an app badly, they could be asked to tell the developer about it / get in touch with the developer directly.
Part of this issue is that on the App Store App-Specific-Site, there’s no “Contact Developer” button. Although iTunes Connect makes you enter a “Contact eMail Address” for your  app, I don’t see it used anywhere on the page. That’s definitely something they should change.

#5 – An estimate when your App will be Reviewed

When you submit an app to the Mac App Store all it will say is “Waiting for Review” once it is processed. Not very informative, is it?
They could at least provide a rough estimate when your app is likely to get reviewed so you can plan around that a little bit.
Another, maybe better, way would be to show what place you’re at in the review-queue – although I’m guessing Apple does not want anyone to know how many apps have been submitted to the App Store.

It would also be great to get an estimate on how long the review itself will take, based on current review times for other apps. I think they have something like that for the iOS App Store so I guess it will eventually make its way to the Mac App Store, just like the recently added promo codes.

#6 – Notifications for Special Events

flickery is currently featured in the New and Noteworthy section of the Mac App Store (thank you so much, Mac App Store – team ).
I stumbled upon this while checking for reviews – it would have been great to get a notification about that, I think every developer would like to know when they’re featured and where – albeit I assume they do send out notifications if they feature an app in a special way (like the banners on the front page of the Mac App Store).

 

All in all, though, the iTunes Connect team has been doing a great job and I can’t respect them enough for what they’ve accomplished. These are just my six cents. Kudos to those responsible. Kudos.

Follow @eternalstorms

 

No (useful) Plug-Ins in Mac App Store apps

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.

Follow @eternalstorms