This post is for people who are managing mobile applications in a company that is undergoing a digital transformation. The company already has web apps and has begun investing significantly into mobile. Some titles that will get a lot of value from this post include:
- VP of Mobile
- Director of Mobile
- CIO
- CTO
Embrace works with a wide variety of companies in various stages of their digital transformation. We frequently encounter a desire by decisionmakers for a single tool to serve both the web and mobile teams. This goal makes sense on many levels — reducing costs by having a single vendor, reducing complexity by limiting the number of tools, etc.
But what they eventually discover is that the differences between mobile and web are so vast that they require completely different tooling. Relying on a web tool that added support for mobile is a surefire recipe for having your mobile team struggle to obtain the visibility they need to effectively monitor and improve your mobile applications.
We will shed some light on why mobile and web are so fundamentally different and why your mobile team needs tooling that is built specifically for their needs to grow and scale your company’s mobile presence.
In this post, we’ll cover the following:
- What Makes Mobile and Web Different?
- The Different Needs Between Mobile and Web
- The Problems Mobile Teams Face When Using Web Tools
What Makes Mobile and Web Different?
Mobile has far more variables to contend with than web, and ensuring a good user experience is likewise far more difficult on mobile. Let’s examine some of the key differences between the two platforms, including versioning, network stability, resource contention, application environment, and functionality.
Versioning
Each time a user visits your website, they get the newest, most up-to-date version in their browser. You can push out changes to the website, and those changes are live for all users immediately. Thus, the time between writing new code and having it in front of users can be near instantaneous.
This means there are no “versions” of the website that require maintaining. If there’s a bug or issue with the website, the web team can fix it and push it out to every user with no delay in adoption.
That is not the same experience for mobile teams. When it comes to mobile apps, users cannot be expected to run the same version in production. If there’s a bug in a certain version, it will continue to affect those users until they update the app. Even worse, the mobile team needs to maintain the ecosystem of backend support for that version to work!
And the solution isn’t just “make the users update to the latest version” because the choice to update is theirs. Perhaps they cannot due to storage or data reasons. A good example is if your update is more than 100MB, users will be hesitant to update until they have WiFi. But are you going to deny users the chance to use your app until they update? That opens a new host of problems, such as user churn or lost revenue. In the worst case scenario, they may uninstall your app rather than update it.
Network stability
Web teams can expect network stability when it comes to loading and running their website. Whether it’s at home or utilizing a café’s WiFi, there is reason for the web team to assume that the network is stable and that data or processes won’t be suddenly interrupted, thus ruining the user experience.
This is not the case for mobile. Bad connections, being on low power mode, or even passing through a tunnel can interrupt the network connection for mobile experiences. Even worse, mobile teams cannot plan around these scenarios as they can happen in many ways at any point during the user journey.
Resource contention
Mobile teams must contend with resource issues that web teams rarely need to factor in. For example, browsers are rarely competing with other processes for resources, but mobile apps are jockeying with other mobile processes for resources at all times. Devices may limit processes during low power mode, which will have a performance impact for mobile apps. In addition, mobile devices have reduced CPU and memory compared to desktops and laptops, resulting in the OS sometimes needing to kill apps to free up needed system resources.
Application environment
There are many types of computers out there, but the web experience is through browsers that act as a sandbox for web teams. There are only so many browsers out there that web teams need to develop for and all of them act as a contained environment for the web experience. Web teams only need to design the web experience for the browsers themselves.
On the flip side, mobile environments are numerous and difficult to predict. Here’s a list of variables that mobile teams need to prepare for:
- Device differences (iPhone 6, 7, 8, 10, or is it an Android? What if it’s a tablet?)
- OS differences (iOS vs Android)
- Regional differences (different regions have different network stability)
- And from earlier, version differences
Your mobile team is developing an app that will be working on the user’s device without the sandbox environment of browsers. They are deploying into a wild environment where they have little control over the surroundings in which the app will run.
Functionality
Web teams generally need to present a simplified user experience. It’s a one-way display of the web experience to the users, occasionally taking input from the user through comments, uploaded files, or form fills. There is relatively little functionality in web experiences.
But once again, mobile is different. It’s all about interactivity and engagement. Notifications, photos, location, chatting, and editing are common features in a mobile app. In many cases the mobile app needs to fulfill more functions than the web experience! A good example is if your web experience requires a photo from the user, they can simply upload it to your website. But in the mobile app, maybe you’ll need access to the user’s camera (additional functionality), or after the photo has been uploaded you will need to allow the user to edit the photo (cropping, more additional functionality) before the submission process is complete.
The Different Needs Between Mobile and Web
So now that we know the different products web and mobile teams are delivering, how does this translate into their needs?
When web teams think about monitoring performance, they’re considering these factors: network call duration, page load speed, usability, etc. For them, the user experience revolves around how fast they can deliver data from their servers to the user’s browser and have it load in as little time as possible. All of their tools are designed to enable them to monitor these metrics.
Mobile teams are also trying to deliver a good experience to the users, but the monitoring and analytics process is made convoluted by the varying differences in mobile. In short, the mobile team must not only monitor the same things as web teams, but they must monitor additional performance metrics that web teams don’t: device memory, CPU, battery usage, and more.
Ultimately, it’s easier to monitor websites than mobile apps. Web teams encounter predictable problems that affect their users so the root causes are easier to find and fix. Mobile’s numerous variables create an exponential number of environments in which the app is expected to seamlessly work. What happens in the app on the device is not necessarily communicated to the backend, so merely monitoring the backend input and output does not paint the whole picture. In fact, it rarely does, and this is why tooling that was not purpose-built for mobile is inadequate to serve a mobile team’s needs.
The Problems Mobile Teams Face When Using Web Tools
None of this is to say that the web team’s backend monitoring tools are bad at what they do. Backend monitoring tools are important for teams to capture errors and monitor server-side issues.
The problem is that these tools don’t serve the mobile team because they simply aren’t mobile-first. Error capturing is great, but what about performance issues? Full session replay? Screen freezes? Capturing all data so the team can set alerts for different metrics that they want to know about?
Remember: web tools were created with web teams in mind, and therefore the tools were designed from the ground up to enable web teams to deliver that one-way web experience. Some of these tools added mobile monitoring functionality later on, but they aren’t able to serve the needs of mobile teams because the tooling was not built from the ground up to be mobile-first.
Ultimately, the people who are using the tools can best tell you what their obstacles are. If you are a decisionmaker trying to determine if both your mobile and web teams have their needs met by one tool, the easiest way to know is to ask them.
- Are they able to identify and solve performance and stability issues?
- Are they able to reproduce user complaints easily?
- Can they tell when a user complaint is caused by their code, an SDK, the network connection, the device, etc.?
- Can they identify things like screen freezes, slow startups, and abandoned purchases?
- Do they know the impact of issues in order to prioritize more effectively?
We often find that the needs of mobile teams are drastically underserved by their tooling, often because they don’t have access to mobile-first tooling that is built specifically for their needs.
When a company expands into mobile, they are more likely to decide they would rather continue using their backend monitoring tool (such as New Relic) and make their mobile team use that tool’s mobile monitoring function add-ons. After all, it’s built for mobile, right?
But it isn’t. In many cases, it’s just the backend monitoring tool with a few added mobile features. This works if all your company cares about is whether the servers are doing their job and not whether the app is working as intended for the users.
Ultimately, a company looking to have a mobile presence to delight users and expand their reach should invest in a mobile-first monitoring tool. Because users have an incredibly low tolerance for poor performance, and the competition is only getting tougher.
How Embrace Helps Mobile Teams
Embrace is an observability and debugging platform built for mobile teams. We are a comprehensive solution that fully reproduces every user experience from every single session. Your team gets the data it needs to proactively identify, prioritize, and solve any issue that’s costing you users or revenue.
Want to see how Embrace can help your team grow your non-game app with best-in-class tooling and world-class support? Request a customized demo and see how we help teams set and exceed the KPIs that matter for their business!
