Adam Rudd

What to do with day1 app crashes

This is a breakdown of a recent bullet we’ve dodged when launching the MorningReport iPhone application onto the store.

MorningReport is an iPhone alarm clock application.. with a twist. It will wake you up with spoken info about the time, and the weather in your location. Ever over-snoozed because you were too bleary-eyed to see the time properly? With MorningReport, this will never happen again.

We submitted to Apple with our Master version on July 15, and received a rejection email on July 22nd. The issue was something we’d not tested – If the user said ‘don’t allow’ to the “MorningReport wants to use your location” query when they first ran the app, it would sit there until the end of time, just loading nothing. It was a quick fix, but here’s where it got interesting:

Because it was a quick fix and deemed relatively low risk, we didn’t test on all platforms. It was fixed within a day and re-submitted. I got an approval message on August 4, and shifted into PR mode, jumping on Facebook, Linkedin, and finalizing press releases. About an hour later, I got an SMS from a friend

“It doesn’t open… It crashes on startup 100% of the time :( “

Oh shit. This is the worst thing to happen on launch. Full of adrenaline, I called friends who bought the app that morning – all users of iOS4 had the app working smoothly. Anyone with 3, had a crash on startup. No time to verify with code testing. Action had to be taken IMMEDIATELY.

We had two options

1. Keep the app going with a note about iOS3, and patch it ASAP. It’d probably get sales, but anyone with OS3 wouldn’t be able to run it. Those iOS3 users would 1star it, which would potentially kill the popularity of the app.
2. Pull the app, suck it up marine, and relaunch with the fixed version. I’d done the social networking push, but, fortunately had not contacted press yet. MorningReport would lose reputation for every hour it was on the store, so I’d have to be QUICK.

Notice I didn’t have “do nothing” there. That’s what I think a lot of people do when faced with a “we’re screwed” issue like this. There was no way to go which didn’t lose face, so it became “how to we mitigate this launch disaster as much as possible?”

Thankfully, the development team were quick to react when told of the issue. The app was pulled within 2 hours, and we broke the news on Facebook and linkedin.

Lessons

1. Do not get overconfident about small fixes. If ANYTHING changes, especially around launch, you MUST test it. Better to release a good app late, than release a crippled app on time.
2. Ratings are god. If a portion of your audience can’t use what you make, restrict them, or have a damn good reason why, because you’ll get 1-starred before you know it.
3. Any issue which impairs the user’s ability to use the app should be classed as Priority 1, and the app should not be released before these issues have been fixed and tested.
4. Apple’s approval process is not a catch-all. Don’t trust them to find your crashbugs.

Next time

1. Create a test plan for your app, regardless of the size
2. Do a comprehensive test with every feature that is added
3. Do daily tests with the test plan when approaching release
4. Ensure everyone can do work within 4 days of release. It’s here that the biggest issues can be mitigated, and apologized for. Do not underestimate the power of apology.

As a way to apologize for this issue, we’ll be releasing one of the first voice packs for free, or at a heavily discounted price. This may take a few months, but I think it’s important to show that you take issues like these seriously.
After all, app dev is about relationships :)