Your Mobile Teams Should All Use The Same SDKs
Having teams pick their own tools is inefficient and costs your organization time and money
If you would prefer to watch a video instead, you can check it out below!
This post is for people who are managing multiple mobile applications in their organization:
- VP of Mobile
- Director of Mobile
- CIO
- CTO
We’re going to cover why your organization should have all mobile teams use the same third-party SDKs under one company-approved framework.
How Should You Think About Mobile SDKs?
If you’re a mobile company, you probably have a public application that most people would consider to be your main business. It’s the app that your customers use.
If you’re Tinder, it’s the Tinder app.
If you’re Venmo, it’s the Venmo app.
You get the idea. But you might have a few internal apps as well. You might have a warehouse tracker or some kind of time tracker for your employees. If you think about a company like Uber, they have the app that everyone uses, but they also have a driver app. If you are the CTO of Uber, that driver app is just as important as the consumer-facing app because if the driver app goes down, you’re not making any money.
What’s The Problem?
The problem is that your company has different mobile teams that all use different tools. Some reasons this leads to inefficiencies include:
- Mobile teams spending valuable engineering time debating which tools they should use
- Two teams in your organization using different versions of the same tools
- Your organization paying for tools that are only one team uses
- Engineers transferring to a new team taking longer to onboard due to having to learn new tools
- Different mobile teams having dashboards that only they can use
- Different departments being unable to use the data your mobile teams generate due to the lack of standardization in output
By allowing mobile teams to select their own tools, you create organizational friction that doesn’t need to be there.
What’s The Solution?
You have every team use the same tools. Down to the version. We recommend that you start a team to select the best-of-breed SDKs for everything your organization needs: ads, analytics, crash reporting, logging, etc.
You can call it the Dev Tools team. It’s comprised of engineers, and they pick the SDKs and publish them down to the other teams. That way, the other teams have buy-in. These tools weren’t picked by management. They were picked by the people who are going to be using them every day.
Your other teams don’t need to think about it. They just integrate what your Dev Tools team has chosen.
Some companies aren’t big enough to have a full team dedicated to Dev Tools. In that case, just nominate one engineer to go out and do that research. Have them figure out what the best solution is. Once that’s finalized, you integrate them all into a single framework for your company.
For example, think about the way Apple ships features. They ship the UIKit framework and the WebKit framework. When you integrate those frameworks, you get all the features you need to use either UIKit or WebKit.
Your company can do exactly the same thing. The Dev Tools team can integrate all these best-of-breed SDKs into one framework and call it the Third-Party SDK Framework (or whatever you come up with). Then all your mobile teams can have the exact same integrations with the same versions.
If a bug happens, it’s going to be the same across every framework integration. You won’t have each team going out on their own and trying to pick tools to troubleshoot the issue. That’s not efficient for your organization.
Summing It All Up
We went over two points today:
- How do you think about mobile SDKs as a CTO or Director of Mobile?
- What can you do to help your mobile teams integrate third-party SDKs more easily and keep them all up to date?
By removing the friction of having teams choose their own tools, you create efficiencies for the entire organization.
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!
