Evaluating Developer Experience for Mobile SDK integrations

I’ve integrated at least a dozen different SDKs into iOS and Android in the past year: analytics tools, ad publishing libraries, push messaging services, data storage services, location and beacon partners. Some of these tools are free, some my company paid for, and others were a revenue source for my app. Every integration is different, but there are definitely tiers to how satisfied I was with each integration. I have developed a five-star scale for SDK integration experiences:

This is a delightful experience!
There were maybe a few bumps, but it all works in the end and I’m happy. Support was good.
OK. It was rough going, maybe the documentation was confusing or incomplete, but in the end I *think* it is going to work.
It was rough and I’m not confident it is going to work in production. If there’s an alternative I’m going to seek it out.
I hate this tool. I’d actively lobby to get it out of my app and to never use it again in my life.

Most of the tools that I use are 2 or 3 star experiences, not good. I think it is useful to talk about what makes an SDK integration a pleasure and leads to successful integrations.

Why does the developer’s experience matter?

It’s all to easy to lose a customer due to poor developer experience. Developers are often involved in vetting potential tools before a purchasing decision is made, and even after a deal is made developers are critical for delivering a successful integration.

Even for free tools, you are putting it out in the world for a reason, most likely you want people to use it. Maximize your impact by providing developers with a frictionless path to success.

What do I mean by delightful developer experience?

For me as an app developer, a delightful experience means…

  1. I understand what the tool does — a lot of times all the product explaining is in a sales pitch to the business, and when something was handed to development we get a link to the documentation and that’s it. I need to understand what this thing does if I’m going to integrate it successfully for the business.
  • Part of that is my responsibility as the developer— to ask my business team what we are hoping to get out of this tool. At the same time the SDK/tool dev docs can help a little by referring to clear and simple product or even domain explanations. Remember, we developers aren’t necessarily experts in whatever the tool is for (advertising, analytics or user engagement). The people providing the SDK probably are. Educate your customer’s developers!

2. Getting started is frictionless — It’s clear what the first step is, and when that’s done it’s clear what’s next, and so on

3. There are copy and paste code snippets — ideally with my keys and whatever already in place. Similarly, for some cases it’s helpful to have sample apps. Sample apps don’t replace the need for code snippets, but it is really nice to see a working example, and this can help an app developer quickly build out a proof of concept for internal use.

4. I get immediate confirmation that the integration is working after integrating.

5. If I need support, it should be great support. This means:

  • There’s an obvious place to ask a human for help
  • I get a response in a timely manner (within 24 hours?)
  • The person responding clearly understands my question or hands me of to a tech person if not
  • Everyone I talk too is nice and eager to help

6. The SDK is open source — I appreciate being able to see what’s really going on and even submit PRs if I find a missing feature or bug.

  • This isn’t required, but I appreciate tools that do offer this.

7. Stability and predictability over time— delightful experiences don’t end with the integration. That means:

  • There are never ever ever crashes. At least NEVER IN PRODUCTION. But, it happens, I get it. This is when the great support makes all the difference.
  • I am notified of critical changes to the platform or when I urgently need to do an SDK update. There are update instructions if I need to change API calls with an upgrade.
  • I am not sent critical notifications on the same channel that I get marketing/general product messages. Don’t assume that I think about or log into your platform all the time. I probably don’t. Someone at my company probably does and you can ask them to bug me, but I might not log in to see your big red banner.
  • Where needed, I have a productive working relationship with the support or SDK development team. Some of my favorite mobile SDKs are from companies where I’ve gotten to know and respect the development and support teams. I trust them.
  • Newly added features work great and are well documented — as well documented as any of the older features. This means not only “getting started” with this new feature, but also all the detailed advanced options for this new feature. Here’s a great doc on writing helpful developer documentation. I am not impressed if you are the first to market if I can barely figure out how to use it and it doesn’t actually work

Why do so many mobile tech companies fail to provide a five-star experience integrating and using their SDKs? We can do better!