Lessons from the front page of the App Store: Part 2

My fingers are poised above the mouse, excitedly tapping the left key without actually clicking. I’m mentally running through the launch checklist... Review the app’s description for spelling errors. Check. Upload the app preview screenshots. Check. Open it up on my iPhone to make sure it still works. Check.

The Be - Career Discovery app was ready to submit to the Apple App store. I simply had to click and it would be live to millions of users around the world and become my biggest foray into the world of software.

This is the story of what happened after I pressed that button on May 11, 2016 and what I learned.

Be - Career Discovery is like Tinder for helping students discover and learn about STEAM careers. Free for iPhone & iPad

Part 2: What worked. What didn’t

On Monday June 6, 2016 Be hit the front page of the App store.

The first day was an explosion of users and it hit me by surprise. Even though I knew Be was being considered by the committee I didn't know when or if it would be featured. They only say you are being be reviewed.

I only knew because Google Analytics showed a gigantic rise in traffic. Within minutes of landing on the front page of the App Store, hundreds of people had downloaded Be and where swiping through careers. They came from nearly every state in the USA and from dozens of countries around the globe.

Wisconsin was the only state Be did not get any users from on the first day. That’s OK, there's only like 4 people in the whole state anyway. :)

Wisconsin was the only state Be did not get any users from on the first day. That’s OK, there's only like 4 people in the whole state anyway. :)

Lesson 5: Having analytics in your app is a must. Google Analytics is free but there are plenty of other powerful options.

I watched in amazement as the real-time user tracker jumped up and up with every new user.

The traffic spike started at noon on June 6. It was so high that the previous hour’s traffic barely registers on the graph.

The traffic spike started at noon on June 6. It was so high that the previous hour’s traffic barely registers on the graph.

With the sudden rise in traffic, I wondered to myself how the app was performing out there in the real world. I had done beta testing over the last few weeks plus I  had tried the app several hundred times throughout development but neither of those strategies were large enough to simulate mass-simultaneous activity.

I first got wind of the storm clouds when I started to receive Instabug Feedback messages every few minutes. “My cards aren’t loading”, one person would say. “They keep switching on me!!”, said another.

 
Instabug is an easy way for users to provide feedback. All they have to do is shake their device.

Instabug is an easy way for users to provide feedback. All they have to do is shake their device.

 

I frantically pulled out my iPhone and started up Be to see if I would have the same problems. Sure enough, I did. I immediately climbed down into the trenches and hunkered down to figure out what wayward piece of code was causing these issues.

Here is what I found.

Be uses Google’s Firebase as a real-time database. This backend-as-a-service handles everything from user authentication to the career card data in a JSON file.

When a user signs up, the app is continually listening to the Firebase database to get the information for the career card. Each career card retrieves information like the URL for the image and the text for the description.

Below is a sample of the Swift code. The "observeEventType" method is the continual listener from Firebase. Turns out that's bad mojo.

ref.observeEventType(.Value, withBlock: { (snapshot) in
    let title = snapshot.value?["Title"] as? String
    let description = snapshot.value?["Description"] as? String

    self.cardName.text = title
    self.careerDescription.text = description
    
}) { (error) in
    print(error.localizedDescription)
}

Because of this continual listening when a lot of users accessed the same database location, the user’s device was processing the career card information faster than the database could deliver the career card information.

This created a phenomenon where the user would swipe a few cards and then it would undo their progress and jump all the way back to the first card, Architect. Making the app a ticking time bomb until it would essentially erase everything the user just did. Not exactly a great user experience.

Here is the solution.

Since the error was caused by the continual listening of the device to the database I changed the code to only listen to the database once per card. This is achieved by changing "observeEventOfType" to "observeSingleEventOfType" in the Firebase code.

ref.observeSingleEventOfType(.Value, withBlock: { (snapshot) in
    let title = snapshot.value?["Title"] as? String
    let description = snapshot.value?["Description"] as? String

    self.cardName.text = title
    self.careerDescription.text = description
    
}) { (error) in
    print(error.localizedDescription)
}

This change means that on startup, the device gathers the required data and then temporarily shuts off the Firebase listener until the user swipes the card. After which, the listener starts up again, downloads the next career’s data, and turns off once more.

This eliminated the jumping around and sporadic performance. Because this issue was only discovered with high simultaneous traffic, making lesson 6 pretty obvious.

Lesson 6: Test your app for scalability issues. Services like AWS Device Farm help with this by simulating simultaneous use by a variety of devices.

After discovering the issue and re-writing the code, I submitted an emergency update to the App store just a few hours after being featured on the front page. Nothing like an adventurous first day.

Check back soon to read Part 3 about what happened when Be went from a few downloads to the front page of the App Store.