How I almost killed my most successful app
Here’s the story of my fifteen days of shame and frustration that nearly made my most successful app bite the dust.
I developed Nice Weather back in 2013. The concept was simple and I had no expectations. A weather app focused on simplicity with an interactive graph, packaged with a clean UI.
Its launch passed pretty much unnoticed, but nevertheless I kept on improving it little by little. Side projects are fun after all.
Several months later, I decided to redesign the app and — not wanting to force it onto existing users — branched the project as a new app : Nice Weather 2.
I got more traction. Then, out of the blue, an angel smiled upon me. Apple had noticed the app and decided to feature it on the App Store.
The downloads skyrocketed and it became quickly my number 1 selling app.
The next few weeks were pure craziness.
After a while, things gently settled down; Nice Weather 2 had made its place into the Weather section of the App Store, ensuring stable download rates. I kept on improving it and getting feedback from overall delighted users.
After one year of mostly small updates, I decided last April to make a huge upgrade of the app. It involved trashing and recoding some parts from the ground up.
One of the biggest part I wanted to improve was to store data more efficiently and reliably. If you already worked on databases, you know how painful and risky it is to make their structure evolve. To make sure you stay compatible with previous data models, you need to create what we call “migrations”, which essentially take the data from the old structure and process it so it “fits” in the new one.
The main issue with migrations is that you need to think of every form the data may have taken to process it accordingly.
The big update rolled out and I saw almost immediately the crash-free sessions drop from the usual 99.5% to 94%. Something was wrong and I jumped to my computer to solve it.
I took the opportunity to improve some of the data management and submitted a new update with an expedited review request, which was accepted swiftly.
The new-new update was then released, and it did not take long for me to realize that something was askew. Dozens of e-mails either from users reporting crash or from Fabrics, the tool I use to track crashes. The drop was harsh.
From 95% crash-free sessions I dropped to 40%. In my hurry I had forgotten a migration while submitting the fix, and essentially every existing user of the app was crashing on startup after this new update.
I jumped again to my screen and made sure that the migration was this time taken care of, testing heavily on previous versions to ensure that there would be no more mishap. Submission. Expedited review. Release.
Fuck.
Crash-free sessions stopped dropping, but passed a point they stabilized around 60%. What in the hell did I do wrong.
It took me a week to figure it out. I had forgotten the unlucky users who had crashed in the previous version, for which the data was stuck “in-between”, in some kind of limbo state.
So, here we go again. Submission, but no expedited review this time, as after two times in such a short timeframe, there was no point in even trying.
The waiting was excruciating, as while I was lingering for the update to pass, I was witnessing first-hand users tearing the app apart in their reviews and, consequently, all the indicators slowly go red.
It took 10 excruciatingly long days for the app to be reviewed and, at last, released.
As of now, Nice Weather 2 has returned to a more manageable crash-rate, hovering nicely around 1%. If anything, this adventure taught me two things :
- Never submit an update in a hurry, whatever the issue, give it at least a good night’s sleep
- Use a good crash reporting tool. Needless to say, this story would have ended way worse without Fabric allowing me to peek behind the curtain
Let it be a valuable lesson for all iOS developers out there !
