2017 App Attention Index: 80% of Users Delete Apps Due to Poor Performance

Today’s consumers are now accustomed to lightning-fast digital experiences thanks to the high bar set by Amazon, Apple, Facebook, and Google. Every second counts and even minor issues can have a significant impact on the success or failure of a brand interaction.

In fact, 80 percent of users will delete an app due to poor performance, according to the 2017 App Attention Index, which surveyed 1,000 people each from the United States, the United Kingdom, France, Germany, and Australia, for a total of 5,000 surveyed respondents.

Below are some additional findings from the report:

Customer Loyalty is No Match Against Poor App Performance

When the number of choices goes up for consumers, the chances of establishing and keeping brand loyalty becomes more challenging— and that challenge was clearly illustrated in this year’s survey results: 30% of respondents have moved on to an alternative app due to a subpar experience.

Performance Expectations are High—Especially in Banking and Insurance

The survey results show that there is a range in application performance expectations, depending on the service provided. In line with the 2014 study—and with traditional, real-world customer expectations—almost two-thirds (63%) of respondents said that flawless performance is most important to banking and insurance. And this importance should not be tested, as three in ten reported that they would go so far as to change their bank if their mobile app wasn’t up to expectations.

App Performance has an Emotional Impact

It’s easy to measure the impact of poor user experience in numbers: lost customers, lost revenue, and/or poor App Store ratings. But what about the emotional impact on individuals? Since brand loyalty is largely an emotional connection, this metric should be given considerable weight.

When asked how performance problems made them feel, 58% of respondents described themselves as frustrated. Nearly one-third felt stressed—a 21% increase from 2014. Taking the emotional response up another notch, one-third were actually angry—also up from 21% in 2014.

Download the Full Report

This report reveals that many enterprises are failing users in four fundamental user experience building blocks for a digital service: application performance, outcomes, convenience, and emotion. Download the free report for more statistics and insights.

This blog post was originally published on June 26, 2017 and has been updated with new information. 

Preparing for PSD2: Some Critical Considerations

In just three months European banking will undergo a seismic shift brought on by a regulatory event known as the revised Payment Services Directive. Starting in mid-January, banks and other financial institutions will be required to make customer account information available to approved third-party applications via open APIs. The dry technical specifications are not exactly holiday reading, but they describe a game changer so consequential industry pundits are calling it the banking sector’s “iPhone moment.”

For the first time in their long and storied histories, the great European banks are going to find themselves competing on a purely digital playing field. Yet outside a handful of internal development groups, few organizations are prepared to address the far-reaching impacts of what will soon be the new status quo. Regrettably, the consequences for the unprepared are likely be severe.

Most technologists understand PSD2 will fundamentally alter not only payments delivery but also the way their organizations attract and retain customers. They are simply too overwhelmed by the immediate demands of compliance to address longer-term considerations. The European Banking Authority only published the final guidelines for banks and other financial services companies in mid-July. Since then hundreds of development teams have been scrambling to create APIs and applications to access them.

The reality is that APIs and apps alone will not be enough to ward off disruption. According to a research analysis by Accenture, banks in the United Kingdom are poised to lose up to 43% of their payments revenue as a result of the directive and developments like Apple Pay. Accenture says European banks are at a crossroads—either they must resign themselves to a new status as “banking utilities” or they must embed themselves in their customers’ lives like never before.

If they choose the latter path they need to act now to safeguard their relationships with their customers. Not only must they provide innovative services that take care of their customers’ daily needs, but these services must be at least as good as those offered by competitors who are using their data. The good news is banks will have a built-in advantage right off the starting block. Seven out of ten consumers trust their banks to handle their payments over other providers, Accenture found. But the banks’ biggest advantage—their customer data and the relationships it describes—is also their biggest weakness.

Although the effects may not be felt immediately, with time the new services made possible by PSD2 will place an unprecedented load on banking systems as competing payment providers call on the banks’ APIs. Banks risk losing their customers if their digital systems fail to perform. According to the AppDynamics App Attention Span Study, 80% of respondents deleted an app because of poor performance. Scalability will become an even bigger challenge.  At any given moment, any of the more than half dozen PSD2 APIs will be pulling information from tens of internal systems. It should go without saying that an issue within any one of those systems will affect performance. The risk of failure is literally exponential.

My colleague, Andy Skelton, recalled what happened when the bank where he was working exposed an underwriting service as an API a few years ago. The goal of the API was to drive new business, and it succeeded so dramatically that it revealed issues around capacity. Marketing activities by other organizations were generating enough demand to create a slowdown, exacerbating spikes caused by poor internal communication. The DevOps team faced the difficult decision of which requests it should throttle–the bank’s own or those coming in over the API.

The same scenario is likely to play out in the early days of PSD2. At a minimum DevOps teams need to monitor the systems that support the new APIs, and understand how the APIs are being consumed. Tracking data in the aggregate won’t suffice. Banks will need to make sure that API calls are driving business, and they will need to be able to distinguish good partners from bad ones who may be abusing an API or unintentionally performing the equivalent of a denial of service attack.

With development teams stretched to their limits, technical leaders are pushing back on new initiatives. But they cannot postpone thinking beyond PSD2 if they want to establish first-mover advantage. Now is the time to make strategic choices about opening up banking data beyond the requirements of PSD2. For example, banks are in a position to offer far more useful bill-paying portals by establishing relationships with companies outside of the financial sector. Imagine, for example, a service that provides a customer personalized guidance and coaching on achieving his or her financial goals and that also presents approved relevant, real-time and geo-targeted offers from third-parties.

As Field CTO for EMEA at AppDynamics, I work with financial institutions to increase their speed of innovation. These days I feel a bit like Lincoln Steffens, the American journalist who after visiting Soviet Russia at the beginning of the last century famously remarked: “I have seen the future, and it works.” The great changes inspired by PSD2 are happening today. Developers and DevOps teams are getting ready. A few are already poised to take the lead. Their message to the rest of the industry? Catch us if you can.

Learn more about how AppDynamics Business iQ helps businesses compete in the digital playing field.

Firaas is Regional CTO EMEA working with clients to convert performance insights into business outcomes. He is also responsible for setting AppDynamics’ regional product strategy. Before joining AppDynamics he held various positions in IT leadership at Credit Suisse.

iOS developers’ job just got more difficult with iPhone X, iPhone 8, and iPhone 8 Plus

Apple announced their latest phones during their September 12 event at the Steve Jobs theatre. The biggest news was the release of iPhone X and its use of FaceID technology. As expected, consumers, analysts, and Apple fans alike are quite excited.

From a developer perspective, however, these updates mean increased complexity for the iOS native and hybrid apps. The new OS (iOS 11) and the new iPhones now support:

  • Additional Form Factor: While iPhone 8 and 8 plus will continue to have the same form factor as iPhone 7 and 7 plus (4.7 inches and 5.4 inches), the iPhone X will now be 5.8 inches. This means developers will need to care for three form factors now – and possibly more if you are still supporting iPhone 5 and below.
  • New Pixel Densities: iPhones 8, 8+ and X will have different pixel densities which means that the amount of content displayed on each phone will vary. As a result, developers must build and monitor applications to these multiple specifications.
  • New Authentication Mechanisms, including FaceID, TouchID: These new authentication methods may impact the user flow in your application, especially the login and payment experience. To accomodate, you may need to build and display new assets and screens to help users understand how to use the new device-based authentication.

In this complex new world where you are serving customers ranging from iPhone 5 to iPhone X, with varied form factors, processing power, authentication mechanisms and OS versions, it’s critical to have the right tools that will give you real-time visibility into app performance and user flows.

In fact, you should know exactly what users are seeing and experiencing when they use your app – especially when there are UI issues. This will help you understand user behavior on these new devices and enable you to quickly identify the root of the UI issues.

Here are a few data points you should have at your fingertips:

  1. Understand user interaction and touchpoints: Developers need visibility into user interactions and touchpoints with all screens – whether it’s the homepage or checkout screen – including button clicks, text field input, and table cell selection.

  1. Debug issues through screen visualization: Debugging a bug becomes exceptionally  simple when you know exactly what user screens looked like during the point of issue. More often than not, the issue turns out to be a UI bug. For example, when an order is being processed (see the screenshot below) and user tries to swipe, the UI may result into weird state.

  1. Understand application latency: Now, with improved processing speed using the A11 Bionic chip, application responsiveness will improve – and customer expectations will also increase. As result, any app or network slowness will be noticeable, making it even more imperative for developers to know exactly when the application is slow and which line in the code is slowing the app down.

  1. Continue to monitor user segmentation and crash performance: You should continue to monitor app crashes and user segmentation to understand which devices, OS versions or form factors users are using. In addition, segmentation of performance issues based on different app versions will help identify how your code has improved or degraded with new version releases.

As you continue to serve customers on various mobile devices and complex applications, it’s imperative to have a comprehensive Mobile Real-User Monitoring tool you can rely on. Learn more about AppDynamics Application Performance Management solutions now.

Anupam Jindal (AJ) manages Mobile and IoT products at AppDynamics. He has been developing and managing strategic direction of growth products for over 7 years in B2C, B2B and B2B2C markets. AJ is passionate about disruptive technologies and enjoys converting ideas into revenue generating products.

Back to School: Optimized for the Mobile Retailer

In case you hadn’t noticed, it’s that time of year again. My Facebook feed is back from vacation, filled with stories of parents’ struggles with their children to get them ready for the return to school with new clothes and the necessary supplies.

That probably helps to explain one rising trend of consumers increasingly turning to mobile and web applications to complete their shopping tasks. After all, if you can keep one eye on the kids while keeping another on your smartphone, why wouldn’t you just have everything sent straight to your doorstep? This trend represents both an opportunity and a challenge for retailers to capitalize on the shifting habits of consumers. 

The opportunity is clear to engage with consumers through multiple channels both physical and digital, and particularly when the digital channel offers all kinds of occasions for sophisticated targeting and engagement with notifications, deals, and discounts. The challenges, however, are also enormous because of the perils inherent to the digital channel. Consumers are even more fickle today, and they can compare and switch with the ease of a swipe or touch of a screen. In the digital channel, you spend endless resources fine tuning your customer acquisition, engagement, and conversion strategies. But if your apps don’t perform well, then all of those efforts are for naught.

The opportunity costs of a poor performing mobile application can be tremendous. Our research indicates that up to 84% of consumer would delete an app after a crash (insert link to study here). For even more data about the consequences of poor mobile and web application performance, check out this DZone article and infographic including this stunner that 63% of consumers “wouldn’t do business with a company via any channel after having transaction problems on [a] mobile device.”

Given the brutal nature of the competition in the mobile application market, it’s imperative for all enterprises (not just retailers) to provide a flawless, engaging, and delightful digital experience. While UI/UX certainly plays a critical role in that, many companies give short shrift to monitoring the technical performance of a mobile application in production in real-time. Performance is often taken for granted or just assumed or something that developers are responsible for, rather than being considered a key strategic requirement equal in importance to the other elements of the mobile application strategy.

But if the consumer has a poor experience as a result of a crash, and error, or even just a slow response time due to a back-end software problem with a payment, inventory, search, commerce, fulfillment or whatever other corporate business transaction system, then no amount of fancy UI/UX is going to rescue that customer interaction.

Even more importantly, it’s not just about the mobile and web apps, because those apps are just the front end to your core enterprise applications. What if slow performance on your web or mobile app is actually due to a back-end system problem with commerce, reservation, order, fulfillment, scheduling or some other system?

All your customer sees is that there was a problem or they waited until they switched to a competitor app instead. That’s why you need end-to-end visibility for every request that originates from the web or mobile app across the network and through to every line of code, database, message queue, and third party service that gets invoked in order the generate a response to the request that initiated from the web or mobile app.

You need to be able to tag and trace every business transaction as it propagates through your systems and be able to correlate them from beginning to end. Most importantly, you need to understand how the performance of your apps drive the business outcomes and KPIs for your business. If enterprises don’t have a fully thought out digital experience monitoring strategy, especially including mobile application performance monitoring, then they are going to have lower conversion rates, higher bounce rates, and poorer KPIs.

While it’s already too late to implement mobile application performance monitoring (APM) strategy for the back to school rush, retailers, and other enterprises still have time to deploy mobile APM in place for the upcoming holiday seasons if they start now.

Apropos, Gartner has just recently published the 2016 market guide for Mobile Application Performance Monitoring (subscription required). The guide provides an excellent introduction to not only Mobile APM, but also as a component of an overall Digital Experience Monitoring (DEM) strategy.

While retailers are currently in the throws of the back to school season, it’s important to start thinking about the learnings that can be derived and then there’s still time to put a monitoring strategy in place for the upcoming holiday season to address any shortcomings or deficiencies observed now. See how Overstock.com implemented a strategy to monitor their digital presence, reduce their mean time to resolution, and gain code-level context of their transactions with AppDynamics. 

3 Strategies to Building Your Next Mobile App

Options are great – except when there are too many of them. It should be taught on the first day of Mobile App Development 101 that too many options will just paralyze and frustrate the user.

On a macro level, the same is true for all myriad options you face when it comes to building your mobile app. However, a comprehensive blog covering all of your options would be roughly the size of the internet. Instead, this guide will help you categorize your options and see a way forward, but you may still need to do more research to find the exact match for your skills and goals.

If you’re up in the air about how to build your mobile app, it helps to narrow it down to three options:

  1. Developing native, directly for iOS or Android
  2. A mobile-optimized development tool
  3. Some sort of hybrid approach

Here’s an overview of some advantages of the first option over the others.

When to Develop Native

The world of app development involves more than iOS or Android, but those two comprise 97 percent of the smartphone OS market. Developing native makes the most sense in one or both of those worlds.

Optimal Experience

When customer experience is paramount, nothing beats native. Apps built within the official app guidelines and within the proper ecosystem have a distinctive look and feel shared by all native apps. Typically, users will register this as a responsive, high-quality, intuitive app experience. You are also able to directly use any of the peculiar affordances of the device, such as the camera or the GPS, whereas in other approaches you may have indirect access through a variety of plug-ins.

App Store Placement

Some developers say that the biggest benefit is getting placed in the app store of the respective OS. Native apps will automatically be considered for inclusion on the app store. If you are using some other mechanism than native apps, then developers need to ensure that the output will produce an artifact which the app store will consider for approval.

After all, if you can’t be found in the app store, you’re basically wasting your time since it will be much more difficult for your potential audience to find your app if they have to go to some other source to find it, and it will take a lot more time, money, and effort to educate your potential audience about where to find your app. This may not be as much of big issue if your app is intended only for a private audience, such as a company’s internal stakeholders only, for which they may operate a private enterprise app store, vs. the general public.

The counter argument is that the app store is no replacement for marketing. Regardless, you have to get out there and promote it no matter where users go to download it. Unless it’s immediately popular, it could easily get buried amid all the other apps. The whole art of mobile app marketing and user acquisition, engagement, and retention is an entire subject unto itself, usually referred to as Mobile Growth. You can look for meetups in your area or entire conferences which are dedicated to the tools and techniques for acquiring and growing your app user base.

Regardless of your app store or mobile growth strategy, it won’t matter how many people download your app, all of your efforts for engagement, retention, UI/UX design, A/B testing etc. will be completely moot if the app doesn’t perform well. There are innumerable studies showing that consumers will delete or abandon an app/brand due to a single poor mobile experience, and app performance is one of the single largest contributors to the consumer’s experience of the app.

Ultra-Fast Graphics

Another differentiator where native apps excel is if your app depends on ultra-fast graphics. If you are creating a static, information-rich app, it won’t matter. On the other hand, native does better at handling animation and rapid refresh rates. On Android, in particular, you can program directly at the operating system layer using the NDK (native development kit) in conjunction with your Java Android app. You need native if you intend to have fluid access to high-level components like the camera and geolocation.

The biggest costs derive from the development time and the fact that you are tied to the OS. When it’s time to scale up and expand to another OS, you have to start all over again.

Security

Security is the second most quoted reason for going with native. The more moving parts, the more holes there are for cybercriminals to exploit. For the security of your native app, pay attention to the most common attack vectors that seek out weak SSL, unprotected data storage and areas where malware can deliver code injection. Also, make sure that you stay on top of the latest updates from the platform vendors, which frequently include security patches for vulnerabilities that have been identified. In some cases, your app may actually be removed from the store if it hasn’t been updated to include the latest fixes.

If your team has chosen to go native, your next decision is whether to start with iOS or Android. Here are a few considerations:

When to Go iOS Native

Apple continues to come in second in mobile market share, but the iOS app revenues are enormous. Depending on who you talk to, developers chalk it up to better quality or better branding. Strong engagement with loyal Apple users is certainly one of the top reasons to develop an iOS native app. In any case, the truth of the matter is that 94% of US app store revenue goes to the top 1% of monetizing publishers. Many developers say that the biggest benefit of iOS is a lower degree of fragmentation. You’re dealing with one manufacturer, instead of the wide range of different hardware types on Android. But even Apple now has devices in the market which can no longer run the latest versions of iOS, so you will have to make determinations if you will only support the latest devices and cease updating your app for older devices.

When to Go Android Native

Android is where many developers start due to the relative ease of working in Java. More importantly for most companies, Android has the largest user base around the world, not only in developed economies, but especially in developing countries where the much lower cost of Android handsets makes them much more attainable. This is particularly true in the largest growing market of China where there are also many local domestic Android handset OEMs.

If you are looking to expand to new markets and other countries, Android will get you much broader reach. And while each individual Android user may not monetise as highly as iOS, many strategies are linked to having a larger audience at lower ARPU.  If you’re going to go to Chrome OS in the future, Android is the logical place to start since Google is making it possible to run Android apps on Chromebooks. Even Microsoft is getting on the Android bandwagon with its acquisition of Xamarin, which can output Android apps (though not native).

When to Use a Hybrid-Native Mobile-Optimized Development Tool

When mobile was young, development tools that worked across platforms were the way to go. These tools became the preferred platforms for developers when skills were scarce for native programming. There was (and still is) intense pressure to get to market quickly and teams could use these tools to support both platforms from a single code base and development environment. These mobile-optimized tools helped developers collapse the learning curve and incorporate features and functionalities from other popular apps as they only had to learn one IDE but could create native apps for both major mobile OSs.

Today, these platforms are still popular for beginners who may be intimidated by trying to learn native development in Swift or Java and companies using a single dev team to support both iOS and Android or whose developers have existing programming and development skill sets that they are leveraging for mobile development. Here are a few of the most prevalent mobile-optimized tools on the market now:

1. PhoneGap

Adobe acquired this powerful, enterprise-level development tool a few years ago and it has flourished. Adobe also donated the open source project called Cordova to the Apache project where it continues to be developed and maintained with committers and contributors from both Adobe and many other companies. Both beginners and experienced web development professionals tend to love it because you can start from basic HTML and Javascript. Also, if you use the Cordova open source version, it is entirely free, but you also have the option to get advance for fee features with the Adobe version, which will appeal to many enterprises.

This technology essentially allows you to embed HTML5 apps in native containers, and it even includes plug-ins that allow you to access native affordances like cameras, gps etc. from javascript code. The main advantage of this approach is that it allows develops with skills in web applications to become mobile application develops. Many companies have web development teams that can now extend their capabilities to develop mobile applications. For many people, it’s also much simpler to learn HTML5, CSS, and Javascript than it is to learn a native IDE like xCode and Android studio and their respective programming languages.

There are also many projects such as Monaca that have developed entire UI/UX libraries that very closely resemble native design guidelines like Material Design, so that apps built using it look for all intents and purposes indistinguishable from native applications. Even more importantly, the ability to use the styling properties of CSS it makes possible to quickly and easily change the look and feel of these apps.

Of course, one of the disadvantages of this approach is that it relies upon having a web container embedded in a native wrapper. The embedded web container does not have any of the chrome of a stand alone web browser (which is why it can look like a native app), but it also doesn’t support the standard web timing and navigation APIs defined by the W3C, so it becomes much more difficult to monitor the performance of the app. The web container also can add significant overhead and may limit the ability of the app to work off-line without significant effort to use local storage.

2. Appcelerator Titanium

Over the years, Appcelerator has added capabilities like cloud services, mobile back-end as a service, a vast library of extensions, support for Node.js and crash analytics. Developers from all over can come together and work in the most popular languages, including HTML, PHP, JavaScript, Ruby and Python. Developers tend to love it or hate it, to the point where it has broken up application teams.

3. Kony

This is another one that’s been around for nearly a decade and has seen the app market flip from B2C to B2E. Kony is a good rough and ready system that always seems to be one step ahead of technology. Kony seems to be particularly useful to companies that can’t or don’t want to have dedicated native app development teams.

4. Xamarin

Nobody can say Microsoft isn’t trying. They seem to have turned on a dime from advocating for Windows Phone to pushing a cross platform app development IDE. Part of that strategy involved acquiring this independent app development environment which is based on the open source Mono project, though there has always been close collaboration with Microsoft over the years. It’s a good platform to help developers learn C# for native iOS or Android. Microsoft is still the standard in many large corporate environments and those types of companies tend to have internal developers who are skilled in using Visual Studio and .NET to develop both internal corporate apps and external customer facing applications.

Xamarin makes it possible for these types of developers to use their existing skill sets to develop mobile applications for the most common smartphone platforms. This is particular important since in many large enterprises, employees had already adopted these devices for their personal use, so it was not practical to mandate use of Windows Phone devices, which, in the end, Microsoft is now de-emphasizing with its recent write-offs in its phone hardware divisions. Given the tiny market share of Windows Phone devices, these companies were also hard pressed to produce apps iOS and Android, and they needed a way to do that with their existing teams and skill sets.

In the meantime, it gives you a clear cut, interactive dashboard with real-time metrics for the most common app KPIs, though there can still be some bugs, such as the problem with the way Xamarin wraps NSProxy. This can cause an issue if you want to monitor the performance of an iOS app produced using Xamarin, since you need to wrap the NSURLSessionDataDelegate in order to interpose on delegate operations so that its usage can be monitored.

When to Go With a Hybrid

More developers have turned to hybrid options over the past few years just to keep up with customer expectations. B2E moves fast and competition is fierce, so companies feel pressured to generate the user experience of a native app, but with the shorter development times and pre-built components of a mobile-optimized platform.

1. Ionic

Whenever developers mention hybrid, Ionic usually comes up among the top hybrid options. Some teams start out by building a CSS framework with the SASS extension language to contain the native look and feel. It’s built on HTML5, and AnjularJS is emerging as the go-to way to drive app features. The next gen Ionic will have drag-and-drop programming capabilities, so expect a flood of new developers to try it out. The community of Ionic developers is already strong and helpful.

2. React Native

Many developers have said that React Native is the closest thing to working in native, but with the addition of a framework and active support community. It was put together by Facebook developers, so the development itself is done entirely with a combination of React and Javascript. You have to come in with plenty of Javascript experience and know how to solve common app development issues around containers and APIs. On the other hand, if you want to build an app on both iOS and Android at the same time, and want performance that is close to native, this is a very useful tool.

It is somewhat ironic that this approach has come out of Facebook, since Facebook itself very publicly and spectacularly made a complete architecture switch from a hybrid native approach several years ago to fully native apps, and the main justification for making the switch was improved performance which resulted in very significant improvements in key business outcome KPIS such a the time spent in app, number of photos being uploaded etc. which are critical measures for Facebook that have a very direct influence on their bottom line which is dependent on selling ads.

There was much debate and discussion in the technical community at the time about whether or not Facebook’s hybrid implementation was the problem, and not the architecture choice itself. For example, some argued that Facebook had essentially just been cramming it’s website into a native container rather than explicitly programming it as a native/hybrid app from the ground up.

Of course, very, very few companies have the scale of a Facebook both in terms of the number of users (wouldn’t we all love to have the problem of a billion plus MAUs?) and the amount of the content being run through the app, so any performance hit from taking a hybrid approach is much less likely.

3. Mobile AngularUI

This is one of the new advanced hybrids. Mobile AngularUI is ideal for enterprise-level developers who are comfortable with Bootstrap 3 and AngularJS modules. However, it also has built-in mobile components like switches and overlays that aren’t in Bootstrap 3. If you’re not a fan of jQuery, this hybrid bypasses it for libraries like fastclick.js.

Summing Up

Native development in iOS or Android (or both) makes the most sense to take full advantage of the native capabilities and if you have development teams that are experienced in the native IDEs or you have hired a third party development house that can do the same. Mobile-optimized platforms like Appcelerator Titanium and native-hybrid Phonegap are best for single environment development teams and when devs don’t have the skill sets or inclination to learn Java and Swift. However, a hybrid approach using technologies like HTML5 can run the risk of making it harder to monitor the performance of your application, especially once it is in production. It can be a fast way to get a minimum viable product on both Android and iOS especially by leveraging existing skill sets from the web or other programming languages.

Regardless of what approach you take, it is imperative to monitor the performance of your app once it goes into production, so you can then iteratively upgrade and refine the app based on metrics and user feedback. It may be tempting to just rely on app store ratings and reviews to get feedback from your users on problems, bugs, crashes etc., but by that time it may already be too late if the user has deleted the app due to a poor performance experience. More over the poor ratings and reviews are public and may negatively influence other new users from even trying the app.

Consequently, no matter what approach you take, it is absolutely imperative that you have a strategy and plan for monitoring the performance of your app in real time.

We’d love to hear which route your dev team chose in the end and what were the deciding factors. If you used a mobile-optimized platform or a hybrid that wasn’t listed here, let us know in the comments what you found and how it worked out. Similarly, let us know about your experience in monitoring the performance of your application, and if you haven’t started yet, then get in touch so we can help you get going.

 

 

What’s involved in adding Mobile Real-User Monitoring to a mobile application?

At some point, your enterprise is going to realize that it has to get serious about improving the performance/quality of your mobile applications. There’s a lot of confusion/misunderstanding about what’s involved in monitoring performance of mobile applications. In this blog I’m going to describe the overall process of what it takes to get started and how mobile application performance monitoring works in production.

In talking with a lot of companies about their enterprise mobile applications, I’ve noticed a trend for how mobile initiatives frequently get started. In many instances, someone in marketing or on the business side desperately wants a consumer-facing app for some new project or initiative for the company brand, be it for a promotional effort or some other type of campaign.

But the enterprise IT group doesn’t have the internal skills for native mobile application development and mobile apps in general are outside the domain of the traditional IT Ops group and it would take way too long for them to gear up to do it, so the business uses their discretionary, project, or advertising/marketing budget to engage with an agency or a consultancy to build the app in time for the project at hand.

Then, once the app is out in the wild among your customers for its initial purpose, the following process will inevitably happen:

      1. the desired scope of the application will expand as the company decides they want to use it for other purposes with additional features and functionality beyond the original minimally viable product definition,
      2. there will also certainly be problems with the app due to unanticipated issues or as a result of bugs and performance problems introduced by new features that got added later like tying the app into the enterprise IT infrastructure for services needed to support the new features,
      3. users will be upset by the problems/issues and write scathing reviews in the app stores or on social media, which will give the app poor rankings. They may even delete the app entirely,
      4. the company will realize that the poor app experience is hurting the company brand and costing it customers and good will, and
      5. there will be frantic calls that somebody has to DO SOMETHING about it to make it right.

At this point it’s likely that IT will have to get involved because now the app is become a critical part of the company’s business strategy and is tied into the enterprise IT infrastructure. The IT Ops group will already most likely be familiar with Application Performance Management (APM) for the enterprise apps that they are responsible for managing, but since they didn’t develop and manage the mobile app, they are probably not familiar with or know how APM works for mobile applications.

Monitoring the performance of mobile applications is a bit different than traditional IT Ops APM where the server side applications run on server infrastructure managed by IT in a corporate datacenter or private or public cloud environments. The main difference is that tradition IT enterprise apps are directly managed by the IT group itself, where they frequently are responsible for building (developing) the app, and then deploying it and managing it on the server infrastructure where they have direct access to it and control over it.

In the mobile application ecosystem, there is a level of indirection between the application and the process of accessing, controlling, managing and monitoring the application. In the traditional APM world, IT can add monitoring of the application performance via the application infrastructure without having to modify the app itself because they have that direct access to the systems where the application is being hosted and run.

The process for adding monitoring of the performance of mobile application as it is being used by your customers is different due to the level of indirection involved and the lack of direct access to the devices where the application is running.

Since the mobile application is being used directly by your customers on their personal or corporate mobile phones, the mechanism of monitoring the performance of the app “in production” is called Mobile Real-User Monitoring or Mobile RUM. Figure 1 shows the overall process of adding AppDynamics Mobile Real-User Monitoring to your mobile applications so you can monitor their performance.

Screen Shot 2015-08-06 at 11.45.18 AM.png

Developer Process

The first thing you have to do is to incorporate the AppDynamics Mobile RUM SDK into your native mobile application.

            1. Developers download the iOS or Android SDK from the AppDynamics website

            2. Developers use the respective integrated development environment (IDE) which is xCode for iOS apps and Eclipse with Android Developer Tools plug-in or Android Studio for Android apps

            3. Developers compile the appropriate SDK into your application using the corresponding IDE

              1. As part of your testing and QA process you can have a limited number of beta user testing your app and monitoring the performance before you release it to the app store

              2. Distribute the beta using one of the available beta distribution mechanisms

            4. Developer submits the new version of your application to the appropriate app stores

            5. Once the app has been approved, the new version of the app will appear in the app store once it has been approved

            6. App is available in the app store for customers to download the new version

Data Exchange for Mobile Application Performance Monitoring

Once the end-user has updated to the new version of the app and starts using it, then a number of data flows will be triggered.

            1. The first thing that happens is that at some point the app will make some request via the network to some back-end infrastructure. As part of the request, the AppDynamics Mobile RUM agent that was built into the app via the SDK will automatically detect the request and will add an AppDynamics identifier to the header.

            2. When the response is sent back to the mobile application, additional information will be added to the header including GUID (Global Unique Identifier) which uniquely identifies that particular request for later analysis, the time that it took that particular Business Transaction to execute, the average BT execution time, and an identifier for that particular BT

Deployment Flexibility

The next part of the data flow depends on how you have chosen to implement your deployment options. AppDynamics offers flexible deployment options including a pure SaaS option, and pure on-premise option of a mixed hybrid SaaS/on-premise option.

The first option is to choose to use either the Mobile RUM Cloud SaaS data collector or the on-premise Mobile RUM Server. In step 3 of the data flow, the AppDynamics mobile application agent will send information to the Mobile RUM Cloud (3A in the diagram) or the Mobile RUM Server (3B in the diagram) including the object ID, the NSURL (in the case of iOS or the Android equivalent), any crash API data from a previous crash, and any custom data that you may have chosen to collect for your application.

The Mobile RUM Cloud or Mobile RUM Server collect this data from all of the mobile application clients that your customers are using, does some processing/aggregation of the data and then passes it on to the next step. There is no permanent data storage in this step.

The second option is to choose to use either the AppDynamics SaaS Controller or the AppDynamics on-premise Controller. In step 4 of the data flow, the processed/aggregated data is sent from either the Mobile RUM Cloud or Mobile RUM Server to either the SaaS Controller or the on-premise Controller.

The Controller is where all of your application performance data is correlated, baselined, stored, and accessed for monitoring, alerting, analysis, and action by all of the people in your organization that are involved in the running, maintenance, operation, and business of your application.

Your employees access the Controller via the AppDynamics web-based portal where they can have role-specific views of your application performance data and can work to collaborate to resolve issues faster (troubleshooting, problem identification and isolation) via the War Room or monitor the business via custom performance operations and business/executive dashboards.

Interested in trying AppDynamics Mobile RUM? Check out a FREE trial today

Monitor your apps with AppDynamics Mobile Real-User Monitoring (RUM) for free and get mobile crash analytics free forever

Companies are increasingly becoming mobile-first, catering to users constantly on the go. That’s why we’re making it even easier for mobile developers by releasing AppDynamics Mobile Real-User Monitoring (RUM) with a free trial. Plus, we’re making mobile crash analytics capabilities free forever with a data retention plan for an industry-best 365 days.

Mobile Real-User Management is our disruptive, next-generation solution for collecting mobile application behavioral analytics and managing the 24/7 performance of mobile applications in real-time.

AppDynamics Mobile Real-User Management includes:

Mobile Business Transaction Correlation. Mobile developers no longer need to subscribe to the misperception that backend services are a black box full of performance delays. The deep metrics provided by AppDynamics Real-User Monitoring allow mobile developers and IT operations to drill down into individual lines of code across every hop in a business-critical transaction; collaborate to resolve performance issues faster than ever before; and together win customer satisfaction.

Mobile Crash Analytics. Best-in-class AppDynamics crash analytics capabilities allow mobile developers to quickly identify unique and recurring crashes for specific devices, operating systems, or carrier types, and fix them before they become pervasive and do serious damage to their ratings in the app stores. With data retention for a 365-day period, mobile developers can flashback up to a year to learn from historical trends and patterns.

Screen_Shot_2014-08-04_at_4.21.16_PM-960x0 (1)

Enhanced Mobile End-User Experience Management Capabilities. With the new enhancements, mobile developers receive critical insights into the impact of network request latencies on the end-user mobile experience. In addition, they can now collectively time any number of interactions, such as time taken to browse a catalog, or time taken from the first search to a purchasing decision.

prod-meuem_a-960x0 (1)

Mobile Behavioral Analytics. With these brand new capabilities, mobile developers can now measure and benchmark business information, such as the average dollar value of a mobile shopping cart, or behavioral patterns such as the frequency of customers adding items to the shopping cart, all in real time. With these in-depth insights into actual user data, mobile developers can prioritize their mobile app certification across a complex multi-dimensional matrix of device, OS, and network carrier by easily identifying and focusing on the highest-value users.

Usage_stats-960x0 (1)

Available as Software-as-a-Service (SaaS) and On-Premise. AppDynamics Mobile Real-User Monitoring is the only mobile application performance monitoring solution offering SaaS or on-premise deployment flexibility. The SaaS and on-premise products have 100 percent feature parity, with no loss in functionality while moving from one to another.

AppDynamics Mobile Real-User Management is the industry’s most powerful mobile application performance monitoring, with enhanced mobile end-user experience management, mobile behavioral analytics, deep visibility into every business transaction originating from any mobile device and traveling across the most complex, multi-tier backend services and application orchestrations, and mobile crash analytics data.

So if you’re a mobile application owner or developer, we’ve just made it easier for you to stay on top of mobile commerce, mobile app adoption, usage patterns, and performance. In short, we’re taking the guesswork out of delivering superior mobile experiences, whether it’s the latest game or a business enterprise app. And it’s free, so no more waiting for a purchase authorization or trying to get more funding — you can start building better experiences into your mobile apps right now.

Get started with for FREE with Mobile RUM today!