These are a few of my least favorite things, and I’m sure your customers share similar sentiments. In our digital-centric world, applications have become the modern storefront for nearly every business. They’re expected to provide convenient services, perfectly and right now. This is especially true for consumers with a mission to accomplish and limited time to get it done — whether “it” is paying bills, ordering fresh groceries or purchasing event tickets. Applications that don’t nail expectations are quickly abandoned.

In fact, consumers take app perfection so seriously, nearly two-thirds of users who responded to our AppDynamics App Attention Index 2017 said they will delete an app or abandon a website altogether due to performance problems after just one attempt due. An overall poor digital experience has led one-third of respondents to take their business elsewhere. And one-quarter of those surveyed said they’d be less likely to use a service in the future.

Clearly, businesses offering digital services have a lot on the line. Poor performance could cost companies billions per year, and a bad UX can forever tarnish relationships with customers.

My time in the trenches of app development for the NFL, Google, Tapjoy and AppDynamics has helped me refine three top strategies to escape the fate of app abandonment and built a product users actually like.

1. Climb the user-first design pyramid.

I’ve been asked one question countless times throughout my career: “I have a great idea for an application. Where do I start?” I always start my answer with a drawing that at first glance looks like the standard food pyramid. Instead of layers of grains and vegetables, though, it contains four building blocks: performance, utility, functionality and delight.

Performance is the base of the pyramid. At the end of the day, no one will use an app that doesn’t work. Performance must be a holistic part of your application so you can measure how well each layer above is operating. Unfortunately, performance often is overlooked or taken for granted. To get it right, you have to deploy the proper tools and infrastructure. Otherwise, you run the risk of crashes, bugs and unhappy end-users.

Utility focuses on how useful your application is and whether it maps back to what your intended audience actually wants. For example, I’m a huge football fan, and I always want to know when the Bears play. Based on utility alone, an app that simply lists all my team’s matchups would meet this need. Delivering value to your customers should be the sole reason your application exists. Concentrate on value, avoid unnecessary clutter and allow your users to find exactly what they’re looking for as quickly as possible.

Functionality encompasses features that make your application easier to use, such as filtering, good UX design or streamlined processes. In my Bears schedule example, consider a default view that shows only upcoming Bears matchups and filters out games already played. Good functionality provides a clear and easy path to fulfill the needs that consumers value most highly.

Delight is the cherry on the top. It’s the small things that make your users smile. That might be the added ability to watch game previews, a slick pull-to-refresh interaction or a Bears-themed loading screen. I’ve seen what happens when developers jump straight to this stage without providing utility first. In the best-case scenario, your user will spend a few seconds trying to find value and then abandon the application (maybe forever).

2. Pay attention to retention rates, not customer complaints.

Once your application is off the ground, start paying close attention to metrics that indicate whether users are sticking around. For many mobile applications, the number of daily active users is a good metric to watch. Specifically, at what rate are daily active users converting to monthly active users? This will help establish a standard number or baseline for how sticky your application is.

People often rely on ratings or customer reviews, but be careful: It’s been shown that 96 percent of unhappy customers don’t complain — they’ll simply leave and never come back. Setting key performance indicators (KPIs) that reflect retention can help you keep a good pulse on how your application is performing with your users. Any deviation from your baseline should be a red flag that causes you to dig deeper into what’s happening. It could be a sign of natural user attrition or a clue to bigger performance issues.

3. Don’t let the tyranny of the urgent take over.

Figure out what defines a great customer experience for your application and use it as a north star to set priorities. Let it guide what you’ll fix or improve first. Floods of bugs or customer complaints might come in on any given day, causing you to play whack-a-mole. Developers need to stay focused on the problems that are most strongly tied to the excellent experience they strive to maintain. In the long run, aligning priorities with customers’ leading values will uncover opportunities to build stronger, lasting relationships.

Consumers’ preferences are dynamic and ever-changing, so getting an application right is a continuous process. Building the next great application involves regularly putting yourself in the mindset of your end-users. Test for yourself whether your product’s evolution parallels what users want and how they expect to experience it. An application built on user-first design and guided by the proper metrics has a good chance of standing the test of time and ensuring you stay hyper-focused on building great products your customers won’t ditch.

For many companies, and up until about just five years ago, the only metrics for how well a mobile app performed were network call errors and whether it crashed or not.

But those times are long behind us, as there’s nothing simple about today’s mobile apps. Issues are harder to find and fix than ever. Your app developers and quality engineers do testing before releasing the app to an app store. They go through all the common paths to find any issues or errors. But even with all this searching, it can still be difficult to find the source of an issue.

Technical complexity isn’t the only thing that’s exploded over the last five years — user expectations have become more complex as well. Mobile app crashes and network issues aren’t the only things that could result in what could be classified as a bad user experience.

An app could be technically operating, but that doesn’t mean it’s operating in a way that’s satisfactory to a user. Expectations have grown exponentially — primarily because the bar has been set so high. Users compare every app experience to some of the top players in the app store, like Facebook, Gmail, or Instagram, amongst others.

These extreme expectations go hand in hand with mobile apps because a good chunk of their business comes from organic user growth. About 30-50% of a mobile app’s users find the app by fiddling around in app stores like Google Play and Apple iTunes, or through advertisements. Unlike websites, mobile apps must be downloaded from app stores, and the app rating is displayed right at the top. This means that your business will lose out in mobile customer acquisition if you don’t have good ratings, regardless of how good your marketing strategy is. And obviously, good ratings come from satisfying user expectations.

To drill down a bit, here’s what a user is expecting from your mobile app, in addition to it being stable and error free.

Highly responsive: Your app should load screens with content in less than 200 milliseconds, otherwise the application can be perceived as slow. Obviously, this number varies according to the geographical location of the user.

Simplest experience to achieve a goal: Mobile apps should be built to achieve a goal in the simplest way possible because mobile devices have limited screen real estate and often suffer from limited attention span from users.

Quick response to customer issues: Companies exchange hundreds of emails and spend multiple days to determine the source of an issue. For each customer, his or her issue is the most urgent one at that moment and should be addressed immediately.

During AppSphere 2016, I presented the following six best practices for mobile app monitoring with the goal of better meeting user expectations.

Can you tell the health of your application in a second? You need to have a holistic view of your KPIs (key performance indicators). These KPIs must include crash rate, error rate, latencies, and a business metric (this could vary for different businesses, e.g., revenue, engagement, conversion, etc). The KPI view should be installed in every visible area of your mobile team section. Everybody should know the health of the application at any given minute.

Whose problem is it anyway? Always know a quick way to tell what’s causing the issue and what tools you should have to help you. If you’re consulting multiple teams to see if they know the root cause of the issue, then you’ve already lost your customer’s trust. Your users and customers see you as one company and not as multiple teams or processes. You should have ways to point out the exact line of code that’s causing the issue.

Are you asking your customers too many questions? Empower the customer voice with technical context. When users or customers have a bad experience with your app and they reach out to you for help, the last thing you want to do is to ask them what flow they went through, the buttons they clicked, or the type of phone they used. You should have tools to tell you the exact flow a user went through and how your code behaved through this flow.

Who’s using your app, and how are they different? Understand your customer environment. You should know the geographies your application is used in and consumer preferences in different regions.

Can you reproduce issues with certainty? This is the funniest one. Often a manager would go to his or her engineer and ask to fix an issue, and the developer would come back to say, “I can’t reproduce this issue.” So, the problem just happens for limited users only and isn’t important? Well, you aren’t going to meet customer expectations with that excuse. You should have a way to tell exactly the way a user got to that problem, so you can follow the steps and reproduce and address the issue.

“Are you creating apps for the fun of it?” You aren’t, so you should have a way to correlate business and application performance. When your application is down on conversion or customer retention, you should know if that was driven by application performance or the business value.

These best practices should lead you to view your application through the right lens and help you keep up with user expectations.

Learn More

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:

Developing native, directly for iOS or Android

A mobile-optimized development tool

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.

Back in the early days of the modern smartphone era (in the ancient times of 2007) the business of building a mobile application was pretty simple and straightforward. A developer (or two or three) got together because they had an idea. They wrote the app (usually starting with a relatively simple first iteration of the basic concept–the minimum viable product, or MVP) published it to an app store, maybe did some promotion to friends and family via email, and hoped for the best. Sometimes it resulted in outstanding success, inspiring generations of mobile app developers in a kind of modern version of the original Gold Rush, this time not just in California (though it still may be the epicenter), but all around the world.

In the interim, of course, the smartphone mobile application business has become a BIG (even HUMONGOUS) business, with millions of apps competing in the marketplace and billions of dollars of revenue at stake worldwide. Entire new categories of business have been spawned, and existing industries are being digitally transformed, in many cases becoming “mobile first.”

Along with the tremendous new opportunities, the business of building mobile apps to capitalize on those opportunities amidst brutal competition has become increasingly complicated and sophisticated. Every stage and aspect of the process–conceiving, building, launching, operating, maintaining, and iterating on the mobile application–is subject to analysis, testing, and optimization. In order to have any hope of being successful, you have to have the data, metrics, and logic to drive the prioritization of the conversion optimization of every facet of your mobile application from user acquisition to monetization.

“You need to get design elements right. You need to get messaging right. You need to get the site’s navigation flow right. You need to establish brand credibility. You need to be able to do multivariate testing to see what works, what doesn’t. You need to understand the psychology of your buyers to address objections. Blah, blah, blah. Indeed, there’s a plethora of issues to understand, experiment with, and optimize.”

And while I certainly agree with my friend and agree with her premise, the description, as good as it is, also missed a fundamental point that is being ignored over and over again by people in the app business at their own peril and tremendously limiting their possibility of success:

Performance!

What I’m talking about here is the actual technical performance of the application: how often does it crash (what versions, OSs and versions, networks, carriers, devices)? What are the response times to network requests or errors with traceability to back-end application code producing the response? How is the user’s journey through the application? Where might they have encountered problems with the functionality of the app or dropped out? And what are the root causes contributing to the performance problem? Regardless of where they arise, within the mobile app itself or in the IT app infrastructure, these are some of the critical factors in determining app performance.

You see this all the time when you go to mobile application focused events. There are endless sessions about app store search optimization (trying to game the app stores to climb the app ranks), social media promotion and advertising for user acquisition, UI/UX design, A/B testing of all sorts, and on and on. Similarly, there are many tools and techniques available to help developers profile their code during development within the IDE they are using.

But there is usually very little, if any focus on understanding the technical performance of the application once it has been released on the app stores and is in “production”. The conversion optimization is left as an exercise considered to be solely the domain of a mobile app developer’s to worry about, rather than being considered by a line of business owner, marketing, sales, and all other stakeholders as an absolutely core part of the strategy, as they are all impacted.

Don’t get me wrong, I’m not saying that these other factors aren’t important. They absolutely are. But without having performance nailed down, all of these other considerations will pale in comparison. A study done by AppDynamics with researchers from the Institute of Management Studies (IMS), showed that up to 86% of users will delete an app after the first try if the have a poor experience with the performance of the app. Just imagine you’ve spent all that time, money, and effort to acquire a user to have them download and install your app, and all of that is wasted due to a poor performance experience. The consequent hit you’ll take to your brand if the user bothers to give you a poor app store rating and posts a negative review of your application, adds to the risks.

During a recent Android developer mobile application conference, a mobile performance engineer from a major social media network intimated that they had approximately sixty engineers dedicated to instrumenting the app and back-end systems for mobile performance monitoring. Today, very few enterprises have the resources or technical skills or scale to be able to monitor performance the way that company does, but that doesn’t mean that performance is any less critical to the success of enterprise mobile application initiatives. That gives all the more reason why enterprise mobile application developers should focus on the core competency of the companies’ products and services and rely instead on a dedicated mobile application performance monitoring and intelligence platform such as AppDynamics Mobile Real-User Monitoring

Let us know how we can help you to ensure the performance and conversion optimization of your mobile applications today.

The official theme of this year’s Mobile World Congress event is, perhaps somewhat obviously, “Mobile is Everything.” While this theme may come across as both reductive and self-congratulatory from an event that is dedicated to everything remotely related to the mobile industry, the fact of the matter is that mobile is indeed changing almost everything: every industry, region, culture, government, politics, environment, public and private sectors ad infinitum.

While the changes in each of these areas are unique to that specific segment, what unites them all is that mobile enables them to digitally transform to adapt to the challenges and take advantage of the opportunities that mobile affords them.

The primary focus of these digital transformation initiatives is the customer experience of how an end user effectively interacts with the software (mobile and web applications on their devices) they invest in. As consumers shift more of their time to mobile phones, the companies that successfully present their businesses through a mobile channel will reap the rewards while those who don’t will fall behind and may even cease to exist.

According to a recent McKinsey study, these types of digitization efforts could affect over $2 trillion in GDP through their effects on labor markets, capital efficiency and multifactor productivity. The report warns that companies must adapt or risk being left behind, and it identifies one of the most pressing issues for companies to keep up with “redefine customer engagement and leverage data generated from digital interactions to fine-tune marketing and customer engagement.”

Consequently, it is increasingly imperative for companies to understand how every line of code contributes to the customer experience on those mobile devices. The challenge for the enterprise is that these mobile websites and applications are not isolated islands. On the contrary, the are just the portal through which a company’s vast array of technical systems and capabilities are exposed to the customer. A single user action on a website or in a mobile application could wind up triggering millions of lines of code to fulfill a request that originated on that mobile device.

As a result, it’s imperative that all of those systems must combine to produce an outcome that creates a reasonable customer experience nearly instantly. A customer’s “laggy” experience may abandon a transaction or even an app entirely to go to a competitor or substitute service that provides a faster or less error prone experience.

So what do companies need to do to spur the digital and mobile transformations?

First, you need a broad, robust, and deep Applications Intelligence Platform that monitors, manages, and optimizes the performance of both front-end browser and mobile applications, and all back-end applications (regardless of the language they are written in and the technologies they run on). You also need it to provide you with the end-to-end traceability of each business transaction as it propagates from the device and through your apps, networks, databases and other infrastructure.

Second, this Application Intelligence Platform needs to provide you with visibility into the entire customer journey with your app from the first page or screen view until the last so you can understand how the performance of your apps contributes to conversions, bounce rates, and your business’ KPIs.

Third, you need advanced application analytics that give you real-time insights into your IT operations, customer experience, and the resulting business outcomes.

Here’s a real world example from a recent customer implementation: A major international financial institution recently implemented AppDynamics in their consumer banking division. They created online banking real-time dashboards monitoring for the senior executives of the consumer banking unit “to:

Proactively monitor system availability

Help identify issues during an incident

Provide real-time performance metrics on customer experience

Trend response time and availability

We can certainly expect all kinds of announcements about new, shiny hardware in mobile devices, IoT, consumer appliances and more at the upcoming Mobile World Congress. In the end, it all comes down to the fact that the mobile device is becoming the center of how an individual interacts with virtually everything in the network around them. And the customer experience of those interactions comes to life through mobile and web applications on those devices. You know there’s a need for that leverage in your market, and in order to provide that superb customer experience, you need a complete solution to:

See everything happening with your applications faster with a unified monitoring strategy

Act sooner with a unified troubleshooting capability

Know more about your customers, experience, and business impact with a unified analytics solution

In her annual report for KPCB back in May, Mary Meeker cited a number of trends, statistics and metrics that show the increasing importance of online activity such as the growth in internet users to 39% of the population globally, the growth of mobile phone users to 73% penetration of the population globally (40% of that being on smartphones), the growth in mobile data traffic up 69% in the past year, the time adult users in the US spend online per day (mobile up 51%), and the implications of all of those various statistics for many businesses.

But in all of her 196 slides, the main thing she failed utterly to report on is how all of those metrics and business are affected by the performance of those online business and apps.

The problem is that it’s easy to take performance for granted, but if you look at all of the business metrics that Meeker cites, whether its messaging/notifications, user generated content (Pinterest Pins, Snapchat/Facebook Video uploads, live gaming streams, audio remixes etc.), just in-time products and services, and every other category of commerce, the amount and velocity of activity is directly affected by the performance of the sites and apps. In fact, performance is so critical to these statistics that Facebook explicitly cited it as the reason for re-architecting their mobile applications from hybrid HTML5 to native iOS and Android and the resulting improvements in their user engagement metrics they achieved due to the better performance.

But if there is one industry where the connection between performance and business results should be abundantly obvious, that has to be in retail. If your website is slow to load, especially on mobile devices, then customers will do less business with you or they may even abandon you completely.

This summer, AppDynamics teamed up with Internet Retailer to measure the homepage mobile performance at 3G and 4G network speeds of the top 500 retailers globally based on their revenue. IR provided AppDynamics with the URLs to measure, and we used our Browser Synthetic Monitoring product (now in beta) to measure the performance of the websites and record the results using our unique Speed Index and Visually Complete metrics in addition to a host of other values including the resources loaded per page, the first render times, and the complete size of the page (or page weight) in MegaBytes.

The results of these measurements are published as part of Internet Retailer’s 2016 Mobile 500 reference guide that was published this month both online and in print. In addition to industry trends and analysis, the database version of this guide provides a summary of key data about each of the 500 retailers, including financial, operational, and corporate summaries, and a snapshot of mobile site performance as measured by AppDynamics. The websites were measured at 30-minute intervals over the course of a week from locations in North America, Europe, and Asia with the Chrome browser and mobile network profiles.

Result Trends

What the measurements show is that there is a very broad spread in retail website performance. As you might expect, the best websites were visually complete in the 2-3 second range on 3G network profiles and 1-2 seconds on on 4G network profiles. At the extreme opposite end of the spectrum were sites that had average visually complete times on the order of 30, 40, and even close to 50 seconds, at both 3G and 4G network profile speeds. Needless to say, the likelihood that customers will be sticking around that long for a page to load starts to drops off dramatically. Studies by companies such as Google have shown that introducing delays of as little as 500 milliseconds into search results can start to have a seriously negative effect on revenue.

Strategies for Improving Website Performance

Among the better performing websites, there are three strategies that website operators can take to try to improve their site’s performance.

The first approach is to try to keep the size of the web page in general as small as possible. In general the data suggest that each megabyte of page size can cost you about six seconds of visually complete time at 3G network profile speeds. The best websites are able to do a bit better than that, but, the less well optimized sites can be way slower. For example, one athletic clothing retailer’s homepage had a page weight of 3.2 MB, yet a visually complete time of more than 34 seconds, or 10 seconds of visually complete time for each MB of page content.

Of course, keeping the page size small is particularly challenging for the retail sector because the natural tendency is to want to fill the page with lots of interesting and compelling product images or a fancy UI/UX experience to appeal to the consumer. But companies need to be very disciplined about understanding the performance impact of their graphics and UXD choices or they can quickly bloat the size of their pages, slowing them down, turning customers off due to the poor performance and thereby wasting all of the time, money, and effort they put into trying to attract customers to their site in the first place.

The second approach is to try to minimize the number the number of resources loaded per page view. The data shows that each resource loaded can carry a “performance” tax of anywhere from .05 seconds to .2 seconds, but should average around 0.1 seconds for the faster websites. website owners to be especially careful when it comes to loading third party resources as these can introduce significant delays. Again, the tradeoff is that third party resources can provide content or services that would be impractical or inefficient for the website itself to own (such as social media content and images) or which are tied to revenue generating strategies of the site such as advertising networks, but if they slow the site down to the point where users are abandoning the page, then it defeats the purpose of incorporating the resource.

Consider for example the 3G data for a popular retailer of video games whose home page had 248 resources, a page weight of 4.13 MB, and took just under 30 seconds to be visually complete due to the time it took to download all the images of games whereas another retailer of sports equipment had a homepage with a similar total page weight of 4.12 MB, but only 140 resources and a visually complete time about one third (10.3 seconds) of the video game retailer.

Most browsers only have eight independent simultaneous threads that they can use to download resources, so when your web page design has lots and lots of resources, the browser can get stuck cycling through its thread pool repeatedly, causing it to bog down and take longer than a site of similar size but with fewer resources to load.

A third approach is to carefully manage and optimize the order in which content is loaded on the site to provide the user with the best perceived experience of the website. This is where the speed index measurement of the site comes in as it provides a relative measure of performance that can differentiate among websites with similar visually complete times to show which site will be perceived by the customer to have better performance. It accomplishes this by measure the ratio of percentage of content delivered over time. For example, consider two website with the same visually complete time, yet website A renders 90% of its content in the first 10% of the visually complete time, while the website B only renders 10% of it’s content in the first 90% of the visually complete time and the last 90% of the content in the last 10% of the visually complete time. Website A will have a much faster speed index score since the user will perceive the website performance to be much better since they can see most of the content very quickly, whereas website B will be perceived to perform much worse and will have a much slower speed index score because the user had to wait so long to see most of the content even though both pages had the same visually complete time.

Looking at the 4G data, for example we see a popular furniture retailer with a visually complete time of 10.6 seconds and a speed index of 2.9 seconds compared to a another furniture retailer with a similar visually complete time of 10.5 seconds yet a speed score of 6.6 seconds. They both have similar visually complete times, but the users will perceive the former retailer’s website to be more than twice as performant than the latter retailer’s website.

Summary

Retailers face a host of contradictory requirements in designing and developing their sites to optimize their revenues and other business KPIs. To achieve the best results, retailers need to carefully consider how their design decisions affect the performance of their websites. Poor design decisions or ill-conceived trade-offs can result in web pages that can be very slow to load, causing today’s impatient consumers to abandon them.

To optimize their design process, retailers should consider using a Browser Synthetic Monitoring solution to see how their decisions and trade-offs are affecting their site performance and availability independently of all of the vagaries that can be associated with real-user performance monitoring.

By using Browser Synthetic Monitoring, companies can get a consistent baseline measure of their sites actual and end-user perceived performance to more accurately assess the impact of different design and implementation approaches.

Furthermore, by combining both Browser Synthetic and Browser Real-User Monitoring, companies can get a comprehensive view of their customers real and perceived experience to optimize their business goals, KPIs, and objectives.

Image showing a snapshot of some measurements from the IR Mobile 500 report.

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:

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,

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,

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,

the company will realize that the poor app experience is hurting the company brand and costing it customers and good will, and

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 isdifferent 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.

Developer Process

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

Developers download the iOS or Android SDK from the AppDynamics website

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

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

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

Distribute the beta using one of the available beta distribution mechanisms

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

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

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.

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.

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.

One of the most prominent current trends among enterprise companies is the nearly insatiable demand for enterprise mobile applications. By some reports, 85% of companies have a mobile backlog of between one and 20 applications, with a majority (50%) having a backlog of between 10 and 20 apps.

The reasons for this backlog are myriad, but the demand is there because mobile applications are the way that companies are interacting with all of their stakeholders. The most visible mobile applications for the enterprise are the ones that are directly customer facing, but enterprises are also increasingly mobile applications for their employees and other stakeholders.

As more and more of the interaction with the company, it’s products, services, and operations are transacted through its mobile applications, these same applications are increasingly becoming the face of the company to all its constituents. As a result, the enterprises’ mobile applications are becoming critical to the company’s brand identity, both directly and indirectly.

In research published by OpenMobileMedia.com, companies are using the mobile channel to increase brand identity (44%), increase engagement (58.9%), drive sales in general ( 37.8%), support specific promotions (20%), customer relationship marketing (26.7%), and other (10%).

Companies are very protective of their brand identity because the brand acts as the lens through which customers build a relationship with the company. According to Yuliya Suleymanova, Founder of SULÉY Group, “consumers build a solid emotional association on what a brand means to them, how it makes them feel, what other people may think of them wearing, eating, driving a brand. These emotional associations build brand loyalty and human connection to a brand so consumers begin to treat a brand as an extension of themselves, a friend that they can always rely on.”

Needless to say, companies spend a lot of money and put a lot of effort into building and protecting their brands. For a list of some of the world’s top brands and their brand value check out Forbes rankings. There are, of course, many factors that contribute the company’s brand value. It’s not just your logo or your website, it’s about everything that contributes to how a person builds their identification with the brand, and people are very passionate about that brand identification. Some of the most successful projects I’ve worked on over the years have involved apps that helped companies to build that brand experience by, for example, making it easy to personalize and customize phones with brand imagery. If you doubt people identify with certain brands, just do a Google image search for “brand tattoos.”

As more and more of a person’s interaction with a company happens through a mobile application or as a result of the use of a mobile application by a company’s employees, the mobile applications will have an increasingly profound affect on the company’s brand value, positively or negatively.

Case in point, there had been some high-profile incidents recently when an issue with an enterprise mobile application created some serious public problems for a company. Back in June, United Airlines had eight percent (150) of its morning flights grounded due to what was initially called a problem “with proper dispatching information” and ultimately was found to be a bug in a mobile application used by pilots to download their digital flight plans.

Similarly, back in April, American Airlines had significant flight delays throughout its network when a problem with an iPad application used by pilots to load airport maps caused the app to crash or be unable to load new maps, caused many flights to return to the gate or even prevented them from departing the gate.

It’s quite sobering to think about the tremendous impact of these fairly obscure mobile applications on both the economical level and the brand level. In the first case, there are the immediate costs to the airlines of delayed flights and re-routing or reschedule passengers, but then there are all the rippling waves of indirect costs to the airline, it’s passengers, and multitudinous other business due to missed connections, meetings, hotel reservations, car reservations, meals, entertainment, vacations and on and on and on spreading outward through the economy originating for a problem with one little mobile application. In the second case, there is the brand value problem of all the disgruntled passengers unloading on the airlines through social media and the news damaging all the effort these companies have made to build their brand by providing customers with a good experience severely tarnished by a mobile application that was completely invisible to the customers themselves.

Can it be any clearer that just having mobile applications to help run your business is not enough? As shown by the data cited earlier, companies are spending incredible amounts of time, money, and effort to build their brands. You also have to make sure that those mobile applications perform flawlessly or at least that you can quickly identify and resolve issues quickly before they become big problems for your customers, your employees, and your partners or else you will could have big costs and negative brand effects as a result of poorly performing applications. Otherwise, all of that investment in the brand can be wasted as a result of one bad incident.

Swift: A new approach for iOS and OSX applications

If you have been paying attention to Apple this year you will have noticed they released a new programming language at WWDC called Swift. Swift is an innovative new programming language for building iOS and OSX applications. Apple says it makes writing code interactive and fun, and the syntax is concise yet expressive, and that apps will run lightning-fast.

Any Objective-C developer will tell you that developing applications on the iOS stack is not as easy as it could be. Swift aims to solve that with a more modern and powerful language. Swift supports all the features you would expect for a modern programming language. Building Swift apps is pretty easy and Apple does a great job explaining how to get started with Swift development in the iOS developer library.

Sign up for AppDynamics Mobile EUM

AppDynamics supports any Swift based application and this blog is a crash course in how to monitor Swift applications with the AppDynamics iOS agent. AppDynamics Mobile End User Experience Management provides everything you need to understand the end users experience on iOS and Android mobile applications in production. If you haven’t already, you will need to sign up for a free trial of AppDynamics Mobile End User Experience Management to get a key.

Download the AppDynamics iOS agent

The AppDynamics iOS agent is extremely easy to integrate into any existing Objective-C or Swift based application. The first thing you will need is to download the iOS agent and get an EUM key from the getting started wizard in the controller. See our detailed information in the iOS agent documentation in the AppSphere Community.

Expose AppDynamics iOS agent with an objective-c bridging header

In order to expose the AppDynamics SDK to a Swift based application you simply need to configure an Objective-C bridging header. The easiest way to do that for an existing Swift app is to simply create a new Objective-C file in the project.

Update the build settings for the swift compiler to reference the objective-c bridging header:

Next, just add the import for the AppDynamics iOS Agent (ADEUMInstrumentation) to the objective-c bridging header which will expose the public methods to the Swift application:

#import < ADEUMInstrumentation/ADEUMInstrumentation.h >

Finally initialize the AppDynamics iOS Agent with your application key in the AppDelegate.swift with a call to the exposed library ADEumInstrumentation.initWithKey( “XX-XXX-XXX-XXX” ).

Make sure to link the libraries the AppDynamics iOS Agent depends on (libsqlite3, libz, SystemConfiguration, CoreTelephony):

Now that we have a completely instrumented application we can click run in Xcode and see our application Swift Weather application running live in iOS Simulator.

The power of monitoring

Now that our application is fully instrumented with the best mobile performance management solution available in the market you can start to explore the full power of AppDynamics. Through the AppDynamics Mobile End User Experience dashboard you can fully understand how your application is performing for your real users around the world.

With visibility into network requests from mobile apps to the server-side with snapshots that correlated the server-side interaction to make sure the backend is never a black box.

With Crash Analytics that feature crash trends and snapshot you can get a clear understanding of what are the most impactful crashes and all the code details (symbolicated stack traces) to resolve issues as fast as possible.

AppDynamics makes it easier to gather intelligence about your users and better understand your demographics with mobile analytics that include custom timers and metrics to understand your users and business better than you thought possible.

Typically, mobile app developers accept some things they feel they can’t change — ratings, end-to-end visibility, user experience, and so on. However, these can all be avoided and under your control with the right mAPM solution to give you the proper insights to give your users a seamless experience.

Now, on to the myth busting…

Myth #3: Users are an enigma that I can never really understand

You cannot nail down the mobile end-user experience unless you know your audience. You need to understand where the end user is spending time while using your application. Are they spending time scrolling down search results to find what they want? In other words, are you presenting the most relevant information at the top? Are they abandoning the shopping cart at any specific points in the checkout process? Is there funnel friction that you need to optimize your app against?

The modern mobile APM tools have some great capabilities to understand your end user and their behavior. You can inject timers across any two arbitrary points and measure times taken for a collection of any number of steps. For example, you can measure how long it takes your user from conducting the first search to purchasing a product or a service. This can be done at an individual user or at aggregate levels. You can measure how much time users spend on which screen. This will give you great insights into who your typical user is and what interactions do they indulge in with your application. You can then optimize the app experience for those common patterns.

Myth #4: I’m going to spend the rest of my life certifying my mobile app on the infinite permutations and combinations of device types, OS types, and network carriers/types

This is where you need concrete data to understand your user demographics. A good mAPM solution will give you detailed breakdown of who your core audience is. What device types they prefer, what OS’s (iOS vs Android) they run, and which networks they mostly originate from. A good APM solution will also allow you to correlate this information with revenue or engagement information to determine your highest-value audience.

With all this valuable information, you can prioritize development, testing, and certification of your mobile app. You can even optimize your app experience and test for performance bottlenecks for the high-value audience. And lastly, you can focus on retaining them by delivering on their roadmap demands over the lesser engaging ones.

Myth #5: There’s no way to know the business impact of the performance issues of my mobile app

Most mAPM tools in the market today are too developer-centric. They deliver crash analytics and performance delays caused by delayed response from backend services but little else. Often times, the mobile channel is an enabler of some business goals such as better customer engagement, additional revenue streams, cost savings from productivity or efficiency gains. Plus, it’s the broader context that feeds investments into the mobile channel. Ignoring the business context is like missing out on half the picture.

The right tool needs to deliver full context on the mobile application. The full context should include what impact the app has on business metrics such as revenues, cost savings, customer engagement KPIs, etc. A comparative chart that shows performance impact of mobile app on these business metrics can be incredibly powerful to raise awareness among the organization.
With these myths dispelled, I hope you have gotten a different perspective on your mobile app initiatives and are rethinking your approach to mobile APM. Feel free to leave comments and share your thoughts.