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:

  1. Launch a new version of your app.
  2. Your APM tool alerts you to an issue (hopefully before bad app store reviews roll in).
  3. 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.
  4. Fix the app in a development environment.
  5. Submit an updated version that includes the fix version to the app store.
  6. Wait for it to be approved.
  7. Wait for users to download the new version.
  8. 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.

NR_Blog_formatMessage-cropped_hires

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 formatMessage method:

- (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];

This is what the update looks like in Rollout (see below on why it’s in JavaScript).

NR_Blog_log_error_hires

[click to enlarge]

Here’s how the patch is applied to the app: Rollout’s SDK makes an HTTPS request to check for any new updates when the app is launched and when the app switches from background into foreground. This means that updates are applied almost instantly and there is no need for any user intervention.

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”).

rollout screenshot 3

NR_Blog_Insights_hires

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:

NR_Blog_fix_bug_hires

[click to enlarge]

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.io logoYou might be asking yourself, is Apple OK with this? Isn’t it a no-no to bypass the App Store in order to update your app? Good question. The short answer is that we at Rollout believe we are totally compliant with all of Apple’s guidelines. The guidelines say apps are not allowed to load code other than JavaScript (check) and that you’re not allowed to bypass the store to add new features or functionality (check). You can read a more detailed discussion of Apple’s guidelines for self-updating apps here.

Rollout has already saved the butts of many developers and we hope to save your butt as well if you need it one day.

 

Background image courtesy of Shutterstock.com.

Ophir Prusak is VP of Marketing at Rollout. He has more than 20 years of professional experience in software development and digital marketing. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!