What You Should Look For In Your Mobile Developer Tools
When are tools worth keeping and when should you consider finding alternatives
If you would prefer to watch a video instead, you can check it out below!
Mobile developers often don’t reconsider their choice of SDKs. We’ll go over what they should keep in mind when deciding to keep or change their SDKs.
What Kinds Of Tools Do Mobile Developers Use?
You want to know many things about how users experience your app.
- What views are they looking at?
- What buttons are they tapping on?
- Are they buying things with 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. You might use a tool like Apteligent to figure out when your application crashes and to get stack traces. You might use a tool like Fabric to get your analytics data and figure out how long it’s taking for views to load or for button taps to happen.
How Often Does A Mobile Developer Change Their Tools?
Most mobile developers do not change their tools that often. You choose your tools within the first few months of starting your app, and you never change them. The difference is as your company grows you might want to think about that again. For example, if you expand into countries like India or China, they have completely different characteristics than the United States. In those cases, you may need an outside tool to understand how those countries are working with your application. This might prompt changing your tools. Or if your team grows from five engineers to fifty engineers, you might need completely different tools to deal with that many people working on an application at the same time.
What Happens When A Tool Is Deprecated?
In the tech industry, companies are always buying each other, merging, or even going out of business. When those events happen, the ownership of the SDKs that you use can change. For example, around three years ago VMware purchased Apteligent. Nothing changed at that point, but this month Apteligent is being rolled into the Workspace ONE product. When that happens, users of Apteligent will be forced to take on all the features of Workspace ONE in their application, even if all they ever wanted was crash tracking. At these kinds of times, it’s a great opportunity to reevaluate the tools that you use.
What’s Happening With Crashlytics And Firebase?
Crashlytics and Fabric are both built by the same company, Google. At the end of this month, both are being incorporated into Firebase.
Google is making a product decision that impacts Crashlytics users. If you only integrated Crashlytics because you wanted crash reporting, now you must add fifteen different frameworks to use Firebase Crashlytics. You will have to take on Firebase Core, Firebase Analytics, etc. (For the full list, you can go to the Firebase docs.)
You might want to use them, but you also might not want to add such a heavy SDK if the only part you use is crash reporting.
Moments like these are a great time to reevaluate your SDKs.
How Does A Mobile Developer Know They Need A New Tool?
If you have a product team, they look at the data your SDKs give you, and make decisions based on it. For example, you probably have a purchase funnel if you’re any kind of e-commerce app. You’re watching everyone who puts something in their cart, everyone who then goes to the checkout screen, and then everyone who completes a purchase. You’re trying to figure out where people drop off in that flow. If you’re using an analytics SDK, it might tell you that 30% of your users are dropping off when they go to the checkout flow.
But what if some of those users are crashing because of a bug in your app? If your analytics system doesn’t have crash reporting, it simply marks them as leaving the funnel.
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, developers learn that they might need a new tool.
What If A Mobile Developer Is Unhappy With Their Current Tool?
If you’re not happy with your tool, the best thing to do is to start evaluating what else is out there in the market. You can learn about that though Google searches or Stack Overflow, but you can also ask your co-workers or attend a meetup. After all, everyone in this industry is using SDKs in their applications. Chances are they have a great idea of a tool they’ve used in the past that has worked great for them.
But how do you test it out? It’s not a great idea to put that brand new SDK into your production app and see what happens. The right thing to do is to start a new application or a new feature in your app and then use this tool only in that new app or that new feature. That way, the integration of the tools grows with the development of that application or feature. You can keep an eye on whether you like the data it’s giving you and whether it’s saving you time or not. This is what matters.
What Should A Mobile Developer Look For In A Tool?
The reason you’re integrating these SDKs is to save your company time and money. You don’t want to be up all night chasing stack traces with no symbols or crashes that didn’t actually happen. We’ve seen these things appear in dashboards over the years, and we’re sure you have too. If you start to see that happen too much it’s time to think about using a new tool. You’re trying to save yourself time and money. If that’s not happening, it’s time to change tools.
What Features Would Help Improve An App’s Performance?
When you’re looking at tools, you want a holistic view of your app. If you think about what’s happening here, you have someone, maybe on the other side of the country, maybe on the other side of the world, using your application and having an experience, but you’re not there. You’re probably sleeping in your bed at home. How do you figure out the next day, the next week, or the next month what that user did when they report a bug?
Let’s say they couldn’t log in and they leave you a one-star review that says they couldn’t log in. All you have is their email address and that message. If the only things your tools are giving you are crash reports and stack dumps, that’s not going to help you solve this user’s problem.
You need a holistic view.
You need to see all the networking calls that were made.
You need to see the views that were entered and exited, including which buttons were pressed.
You need to see the state of that device. Maybe it was in low-power mode. Maybe the CPU was pegged. Maybe memory was pegged. Maybe there’s no room on the disk. Maybe it’s overheating.
There are all kinds of interesting reasons that our mobile applications fail our users, but our users don’t know and all they’re gonna do is leave that one-star review. So when you’re looking at mobile SDKs, you’re looking for a tool that provides that data, and it’s even better if it’s all aggregated together into a single screen so that you can load that user’s timeline, scroll through it, and see what happened and figure out what went wrong.
Where I Work
Embrace is a mobile monitoring and developer analytics platform. We are a one-stop shop for your mobile app’s performance and error debugging needs. If you’d like to learn more about Embrace, you can check out our website or visit our docs!
