Improving the New Relic iOS App with Mobile Monitoring
This post comes from Jeremy Templier at the New Relic Blog.
I’m willing to bet that you have an Android or iOS smartphone. And you probably have more than a few apps you don’t really use anymore. The reasons are infinite: maybe the app didn’t live up to its promises, maybe it had an awful user experience or maybe it was just too darn slow.
As a mobile developer, you want to develop applications that people will enjoy. So, the first questions you have to ask yourself are: What is the user experience like for my app? And what can I do to improve it?
The first things to ban from your application are crashes. Let’s compare crashes on mobile apps to errors on a website. A crash on an app is the equivalent of a 404 / 500 error on a website. Usually on a website, the user just needs to go back later and the problem is solved. In the mobile world, a crash means the application just shuts down. This means that the user will see the application disappear from the screen and may not understand why this is happening. To fix the problem, they’ll have to restart the application and may need to go through different views before being able to retry or finally find the information that they want. Not the experience you want.
Second, be responsive. Do you like to wait 10 seconds before the information you asked for shows up? Or wait 1-2 seconds before you’re able to execute something? No, you don’t and your users don’t like to either. Don’t perform synchronous requests that block the user interface or, while loading, asynchronous requests that display a loading view and block your users. When you’re making an asynchronous request, it should be clear that it’s loading, and make sure the user can go back or do something else while it’s loading.
But enough about what you should or shouldn’t do … let’s talk about the tools we use at New Relic to create a great user experience for the New Relic iOS application.
If you haven’t heard about Crashlytics, it’s an awesome service that collects data on any crash your application has. If you use it in production, you’ll be able to see how many times a crash occurred and get a stack trace to debug the crash as well.
Another great feature in Crashlytics is their custom logs. Instead of using the classic NSLog, you can use
CLS_LOG(format, ...) All custom logs are saved in a file and if your app crashes, you’ll be able to consult those logs. This data can be extremely helpful when you fix your crash.
For the New Relic app, I used custom logs to understand exactly what the user did during a session. This helps me reproduce the exact steps the user made before the application crashed – a really powerful feature.
Unfortunately, understanding how the New Relic iOS app crashes isn’t enough. This is where New Relic for Mobile Apps comes in.
New Relic for Mobile Apps
New Relic for Mobile Apps really helped me improve the performance of the iOS app and make it more responsive. Let me explain how this happened.
New Relic for Mobile Apps provides the following information:
* How many active users you have
* How many requests your application sends
* What is the application response time
* What happens when the response to the request wasn’t what you expected (4xx , 5xx, etc.)
* Hardware information, such as CPU and memory usage
Apps requiring network calls to obtain information aren’t easy to design. You can easily end up with a bad user experience because the information takes a long time to arrive. You may also have unexpected errors, let’s say for 30% of your customers, and not even know it.
With New Relic for Mobile Apps, you’ll know every time your users encounter a bottleneck. You’ll know if you need to split one request into several requests to improve your average response time. You’ll find which requests take the most time, so you can pare non-essential information from the request. All of these changes will highly improve your user experience.
Having access to the response time of each request your application sends gives you a clear vision of how performant they are. When you know the number of requests sent for ‘Request A’, you’ll be able to tell how much time is spent in each request.
Welcome to the Real World
I’d like to show you some improvements we’ve made in our iOS API and to our iOS app thanks to New Relic for Mobile Apps.
Track the HTTP Errors
A few weeks ago, we saw that the number of 403 errors was high. So we started to investigate it with New Relic for Mobile Apps.
What we discovered was unexpected. We requested CPU metrics and other server related metrics even when the user wasn’t in the server view. Weird, right? After some investigation, we found the bug. One observer wasn’t removed when it should have been. This meant that even when the object didn’t have to observe the context, it still did. Each time the context changed, the observer updated the server’s metric. And the URL wasn’t well constructed because the context did change.
One line of code fixed the issue. We released an update and since then, the number of 403 responses decreased by a third.
If we take it one step further and look at all of our transactions, we know exactly what’s going on:
This table shows us what requests are most expensive. If you can modify the backend, it may be a good time to optimize those requests. If not, you might be able to cache the response on mobile to minimize the amount of time you need to execute the request.
And these are just a few examples of what you can optimize with New Relic for Mobile Apps. In the end, you’ll improve the response time of the requests you make and reduce the number of errors. Your users will get a faster app, with fewer errors resulting in an awesome user experience.
Share Your Story
During the development of the New Relic iOS App, our team used Testflight for deployment, Crashlytics for crash reports and New Relic for Mobile Apps for mobile monitoring. We’d like to learn more about the tools you used. Share your feedback in the comments below.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)