Subscribe
Today we released a new version of InkPaint for iPad. We're very pleased with InkPaint 1.1, and glad to get it to our users, but behind its release is an interesting story — and a cautionary tale for other developers.
A few weeks ago, we became aware of a bug in InkPaint 1.0 which caused it to unexpectedly quit after you used it for a while. It was a bug that didn't show up in the simulator, and was hard to reproduce even on the device. But with some fresh clues and a lot of testing, we finally tracked it down. (For the Cocoa developers among you: there was a place we had inadvertently bypassed a property setter, eventually leading to an object being deallocated before we were done with it.)
So we fixed that, and while we were at it, also changed one text label in the app from "Author" to the more accurate "Artist." That's it — one bug fix in the drawing code, and one minor cosmetic change. We submitted this to the Apple app store, pointing out the two changes, in hopes that it would get a quick turnaround — surely such an update is easier to evaluate than an entire new app?
But alas, no; just as with new apps, they took over a week even to look at it, and then several days to evaluate it. Then they rejected it, with a screen shot of the in-app purchase area showing an error message saying that the server could not be reached: "Please check your network and try again."
The email from the reviewers invited us to reply with our concerns, so I did so, pointing out that we hadn't touched the in-app purchase code, and that it works fine in our testing (and of course we tested it again after the rejection, just to be sure). We got an automated acknowledgement, but a week later, no other reply or action.
So I went to plan B: we filled out an appeal with the App Review Board. This is apparently a body whose sole job it is to listen to developers who feel their app has been inappropriately rejected. Again, we explained that the networking code was exactly the same as what they approved in 1.0, that it worked for us, and that most likely, the reviewers just needed to check their network connection and try again.
This time the response was swift and positive. About two hours after filing the appeal, our application changed state from "Rejected" to "Waiting for Review," and then immediately to "In Review". Less than an hour later it was approved and in the app store!
So, kudos to Apple for having this appeals process. I would encourage developers to not abuse it — but if you really are in a situation like this one, where you know the regular approval process has hit a glitch, it's great to know there is a way to get reconsideration, and fast.
But, unfortunately, there is an Act 2 to our tale. After the update was released, we downloaded it from the app store onto one of our devices which was still running InkPaint 1.0. Then we quickly noticed a new issue: the two built-in lessons ("Retro Hero" and the artist's guide) no longer appeared in the library. Instead, they had blank icons and "" for a title.
A short bit of hair-pulling later, we realized the problem. These books work by making symbolic links in the Documents directory, pointing to files in the application bundle. When you update the app on a developer machine using XCode, this works fine. But when you update it from the App Store, the app gets a new path on disk, and then Documents are copied over — including the old symbolic links, which are now broken. This was a nasty little bug that didn't show up until we'd actually put out an update to the app.
For Cocoa developers, the moral of this part of the story is this: don't put symbolic links in your documents to things in your app bundle; or if you do, don't assume they will still be good between runs of the app.
And now I guess I get to go back to the review board, hat in hand, and ask them to approve an InkPaint version 1.2. Here's hoping they're not sore about the whole appeals thing... and that their network connection is in good working order.