Google Maps Crashes Around The World
A few days ago, panic struck apps around the world. In a nightmarish turn for any developer, every app using Google Maps crashed. Not just once, but every time it attempted to load Google Maps. The result being if you launched the Maps SDK on launch, 0% of users could open your app. Not. Good.
Fallout and Recovery:
A little while after the crisis bubbled up Google released a hotfix. But users who had experienced the crash were doomed to continue experiencing it. That is until they either cleared their cache or uninstalled the app. Developers were forced to release their own updates with a suggested bit of solution code. Unfortunately, even with this fix only users who updated their app could be free of the bug.
Apps are still climbing back from this fall, but the experience brings up a couple key components of app development that we’ve talked about here at RootJunky before. These include error handling, dealing with live production changes, and utilizing crash reporting tools like Firebase.
Ignorance Is NOT Bliss:
When it comes to app crashes, it is never a good thing to turn a blind eye. Something like the above may have occurred that isn’t necessarily your app’s fault, but you still need to know when to react. Google has now released a new version of Google Play Services that fixes the issue, but this took days and every hour counts when it comes to things like app ratings and revenue.
Being aware of the crash at hour 1 gives your team time to evaluate the issue and begin investigating possible solutions. And let’s not forget about the pesky fact that ALL developers introduce bugs sometimes. Seeing your new app version start to crash more often than others can be crucial if you need to address something before it is released to all users. Long story short: without crash reporting from a tool like Firebase you’re up a creek without a paddle.
When our apps do experience issues, it’s also important they are able to be handled correctly. Sometimes crashing an app can be the best outcome of a situation, but what about scenarios where the issue isn’t that serious? For example what if our app couldn’t load a user’s info. Would it be better to display a message to the user telling them to try again later? Or would it be better to inexplicably crash the app on them?
This is where error handling comes in. Using things such as try-catch statements can allow us to handle issues in the app’s code without destroying the user’s experience. In the “try” section of your code you attempt to do something. And then in the “catch” section you handle any error that may have taken place. If you’ve ever built an app you’ve undoubtedly used try-catch, but are you using it in all the right places?
Remote Config to the Rescue?
One other option that we’ve discussed before is Remote Config. Using this tool you have the ability to change settings of your app remotely without having to release an update. Let’s relate this to the Maps SDK crash. We could set something up in our code to check if a Remote Config value shouldInitializeMaps is true. If so then we load a map, otherwise don’t even present this option to a user. By setting things up this way we now have the option to shut off Google Maps if it becomes problematic.
Bill Gates captured it quite well when he said “It’s fine to celebrate success but it is more important to heed the lessons of failure”. When things go wrong we should view them as a learning opportunity for how to make our apps even stronger down the road.