Ophir Prusak is vice president of marketing at Rollout, which is designed to let mobile developers update live apps instantly.
The rise of Web apps and Software-as-a-Service transformed the development process. Instead of shipping software and development cycles lasting months or years, developers could update software instantly by pushing an update to the server. Users got updates in days or weeks and bug fixes could be pushed out instantly. In order to keep up with the faster pace of software development, engineering teams adopted processes such as Continuous Integration, Continuous Delivery, and Agile development.
With mobile apps, though, the software development process has taken a step backwards in some ways. Software once again has to be “packaged and shipped” to users, albeit electronically, and developers can no longer just push an update to the server whenever they want. This can be especially painful when a bug slips through the QA cracks and users get busy posting one-star reviews and uninstalling the app.
When mobile users have a poor experience using an app, the consequences can be devastating, and it can take a long time to deliver a fix. The life cycle of fixing an issue in a mobile app usually looks something like this:
- Launch a new version of your app.
- Your APM tool alerts you to an issue (hopefully before bad app store reviews roll in).
- Analyze and debug the issue.
- Best-case scenario: you can easily reproduce and find the issue.
- Worst-case scenario: you can’t reproduce the issue and need more data.
- Fix the app in a development environment.
- Submit an updated version that includes the fix version to the app store.
- Wait for it to be approved.
- Wait for users to download the new version.
- Monitor the new version in the wild.
Even in a best-case scenario, it takes at least 24 hours to run through the entire process. More realistically, it typically takes a couple of days to a week. Keep on reading and we’ll show you how to do it in 10 minutes. Really.
With New Relic, you get real user monitoring (RUM) that can alert you if things start to go south. New Relic excels at letting you know there is an issue and helping you figure out what’s going wrong and under what circumstances. For example, you might learn that your latest app release is crashing on iOS 8.0.0 but works fine on 8.0.2 and up.
New Relic covers steps 2, 3, and 8 in the flow above (monitoring, alerting, and analyzing) but you still need to quickly fix the bug and deliver the fix to your users. That’s where Rollout comes into play.
Rollout is a new SDK for iOS that enables you to push code-level changes to live native apps instantly, allowing you to fix bugs or contain issues immediately, and dig deeper into the issue.
New Relic and Rollout in action
Here’s an hypothetical example with a step-by-step breakdown of using New Relic and Rollout to quickly identify and fix a hard-to-find bug.
Let’s say the Intergalactic Organization of Colonized Planets has an iOS chat app that lets users chat in six different languages, with real-time translation. Beloved for more than a terrestrial year by more than a billion users across the galaxy, the app already has the New Relic and Rollout SDKs installed.
The app’s developers just released version 2.2, which added support for two new languages, Saturnese and Plutonian. Shortly after release of the version, however, they started to see new app crashes revealed in New Relic.
Using New Relic’s crash report interface, they were able to learn that the
formatMessage method was causing the crash, but their mobile developers could not reproduce the issue on their own iPhones. They suspected it had to do with one of the new languages they added, Saturnese, but weren’t sure.
Unfortunately, developers were not sending custom attributes to New Relic on which language the user was using or the message being formatted during the crash. This data was needed in order to confirm their hypothesis.
Using Rollout’s ability to modify methods on the fly, the devs added a patch to the
formatMessage method that sends New Relic the message and language the user was using as custom attributes. To help zero in on the issue, the patch sends this information only when the
formatMessage method would have caused a crash.
Here is the Objective-C declaration of the
- (NSString *)formatMessage:(NSString *)message toLanguage:(NSString *)language
Here’s an Objective-C example of the New Relic
setAttribute method we’re using to send data into New Relic:
[NewRelic setAttribute:@"crash_message" value:message];
[NewRelic setAttribute:@"crash_language" value:language];
After applying the update in the Rollout Dashboard, the Intergalactic Organization of Colonized Planets’ DevOps team was able to use New Relic Insights to query the custom attributes for the language and message that were being used when the app crashed. They learned that indeed the crash happens only when formatting messages in the Saturnese language with a specific character (let’s say “Z”).
Next, the team logged into Rollout and created a fix that replaces “Z” with “X” if the language is Saturnese (they sound the same in Saturnese). The patch replaces the “Z” with “X” and then calls the original implementation. It looks like this:After the fix was applied, the team observed in New Relic that new crashes immediately decreased in version 2.2. In parallel, the team fixed the native app code for the next release in two weeks.
From discovery to fixed app in production in a few hours
Rollout has already saved the butts of many developers and we hope to save your butt as well if you need it one day.