Mobile teams often don’t reconsider their choice of SDKs. We’ll go over why and when teams should switch SDKs and what to keep in mind when making the decision.

What kinds of tools do mobile teams use?

You want tools to help you measure the user experience and how it impacts business performance. To do that, you need to take into account:

  • What views are users looking at?
  • What buttons are they tapping on?
  • Are users making purchases through your application?
  • Is your application crashing?
  • How are your network calls performing?
  • Are your servers down?

The only way to get answers is to have some kind of SDK in your application reporting that data back to you. Tools like:

  • Firebase Crashlytics for crash reporting
  • Mixpanel or Amplitude for feature analytics
  • AppDynamics or New Relic for mobile application performance monitoring
  • DataDog or Dynatrace for infrastructure monitoring

The list goes on and on. Mobile teams need third-party tools to help them improve application performance and monitor releases effectively.

How often does a VP of mobile change tools?

It’s actually rare that a VP of Mobile changes tooling. Likely, you chose tools within the first few months of onboarding or building the application and never changed them.

The issue is that, as your company grows, you might want to rethink your tooling.
For example, if you want to expand internationally, into countries like India or China, your new users will have entirely different characteristics from those in the United States. In these cases, you might need an outside tool to understand how certain countries work with your application.

It’s also possible that, as your team itself grows—from 5 engineers to 50—you’ll need completely different tools to deal with multiple feature and product owners working on an application simultaneously.

How do you know your mobile teams need a new tool?

Mobile teams need tools that work for them. Say they’re working with React Native: Many tools, like Crashlytics, don’t properly surface stack traces with React Native and will often underreport crashes.

And this lack of completeness in information is not limited to engineering teams. Other teams might use tooling that has significant gaps. For example, product teams will use their analytics SDKs to make decisions. If they are evaluating a purchase funnel for an e-commerce app, they will examine how many users:

  • Add items to their cart
  • Reach the checkout screen
  • Complete a purchase

Their SDK tells them 30% of users are dropping off before the checkout page. They will probably make changes to address this shortcoming.

However, if they had access to the engineering team’s SDKs, they might see that the issue is actually because of a crash or bug in the app. If your analytics system doesn’t have crash reporting, it’ll simply mark them as leaving the funnel instead of crashing!

Your product team is going to spend a lot of time building features and optimizing the product flow, but no one’s ever going to find or even fix that crash. In situations like these, teams learn that they might need a new tool that provides a more holistic view.

What about when tools make changes to their offerings?

Mobile teams used to be able to access Crashlytics as a standalone product. It was a lightweight and very effective crash reporter. However, Google purchased Crashlytics and Fabric and has officially folded them into Firebase. Developers who want to use those individual products must now integrate Firebase Core, Firebase Analytics, etc., even if they only wanted to integrate Crashlytics. (For the full list, you can go to the Firebase docs.)

Your mobile teams might want to still use them, but they also might not want to add such a heavy SDK if the only part they need is crash reporting.

When tools get absorbed into larger platforms, mobile teams must decide if adding unnecessary bloat to their applications is their best option. Larger platforms incur performance slowdowns, so these are great opportunities to reevaluate SDKs.

What should a VP look for in a tool?

The reason you’re integrating these SDKs is to save your company time and money. Your developers are chasing crashes with no stack traces. They’re working blindly, with tooling that doesn’t help them, and they shouldn’t have to. It’s not necessary to be up all night looking at dashboards that point to crashes that didn’t actually happen or surface stack traces with no symbols.

If you start to see this blockage in your debug or build process, it’s time to think about using a new tool. You’re trying to save yourself time and money. If that’s not happening and your tooling isn’t working with your developers, it’s time to make a change.

What features would help improve an app’s performance?

When you’re looking at tools, you want a holistic view of your app. With mobile applications, someone on the other side of the country—possibly even world—is experiencing your application, but you’re not there. Likely, you’re asleep in your bed at home. How do you figure out—the next day, the next week, or even the next month—what the user went through when they reported a bug?

Let’s say a user left you a one-star review because they couldn’t log in. That’s all their review says. All you have is their email address and that message. If the only things your tools provide are crash reports and stack dumps, you won’t be able to solve this user’s problem.

It would help to see all of the networking calls in the order they were made. And, it would be a big help to understand who the user was in terms of the state of their device. It could be that memory was pegged or the device was in low-power mode.

There are all kinds of interesting reasons our mobile applications fail our users, but our users won’t know that. All they’re going to do is leave a one-star review. So, when you’re looking at mobile SDKs, you’re looking for a tool that provides that data.

It’s essential that this data is actionable and easily discovered. It would be perfect if the data was aggregated on a single screen so that you could load that user’s timeline, scroll through it, see what happened, and figure out what went wrong.

How Embrace can help

Embrace is a data driven toolset to help mobile engineers build better experiences. If you’d like to learn more about Embrace, you can try us out free and request a demo.

Or dive right into how we can help your mobile teams: