SDKs are on the rise, there’s no denying that. They’re a great way for developers to work out the more common pieces of code often found in mobile applications. These SDKs are the kind that will make their product whole on one hand, but on the other won’t be what sets their solution apart from all the rest.

More and more SDKs are being developed, released and integrated into increasing number of apps. The benefits and services offered to app developers become more versatile and intriguing as time goes by. No matter how much you may dread putting someone else’s code inside your app, it’s getting harder and harder to resist these temptations. Especially when developing them yourself may be too expensive and time consuming.

But much like your own app, SDKs are always trying to better themselves by offering new features, fixing bugs or security risks, etc. Which may sound lovely at first, until you realize a service you’re dependent on has changed. And while change may be a positive thing, it can also break things. So what do you do when an SDK offers a new version? Do you automatically upgrade or do you approach it with much more caution, hoping the current version you use will still be supported in the foreseeable future?

Actually, there are no real guidelines. No easy “do’s and don’ts” list. App developers are left pretty much to rely on their gut reaction and their thorough testing. So let me offer you some food for thought when making these tough decisions.

Harm the Least Amount of Users as Possible

As an app developer, your goal is twofold: maintain your current users and gain new ones. Which means the effects propagating to your users would usually be the top priority in your decision making process.

In an ideal utopian world, all your users would have the same version of your app on their very similar devices, and once you release your new app versions they’ll all upgrade within the blink of an eye. However, reality usually proves to be much more complicated. Different versions of your app exist out in the wild, on different kind of devices and sadly sometimes with different behaviors.

Suppose some SDK you are using isn’t behaving as expected on a particular device and that SDK has released a fix. If a large portion of your users is using that kind of device and experiencing that kind of bug, you’ll surely want to upgrade. But what if only a small number of users use that device? Do you automatically upgrade and take the risk of new bugs for the working majority? And what do you consider to be a “small” or “big” portion of your users? Does a single percent count? How about 5? Is 10% enough for you to upgrade or is it worth it to risk losing them? And what if the upgrade isn’t quick and requires a change in your own code? Your decision should depend on the complexity, time and resources the upgrade requires of you.

Be Aware of SDK Versioning Conventions… And Beware of them

Most SDKs, like apps, have versions. Each new version is usually tagged with a version convention: a dot-separated triple number string that lets you keep track of the changes. The convention is <major>.<minor>.<point>. And as you can gather from it, it lets the SDK developer quickly inform you about how much it considers its’ changes to be earth shattering.

Many development environments and architectures allow you to restrict yourself when it comes to automatic updating. For instance, In Gradle (for Android) you can specify your dependencies and mark the level of which you want to upgrade with a + sign. For example, the following allows your build script to automatically update when small changes occur (the kind dubbed by the SDK as less than minor):

dependencies {
    compile 'com.foo.sdk:SomSDK:1.2.+'
}

But be very aware and cautious. These are just strings generated by humans. What an SDK developer may consider to be a small point or minor fix may prove to be disastrous for you.  Without further manual exploration there’s no real way of knowing what the change to the string really holds and how it affects your app. Moreover, automatic updates such as these might not prompt you to redo extensive testing on this SDK when you test your new version – you may not be aware of the update or might make the mistake of thinking it’s small and unnoticeable (most times I’m sure it will be, but can you really take the chance?)

Be Aware of SDKs Updates

You may not have thought about it at first, but the responsibility of using SDKs isn’t just about how you’re liable for their behavior inside your app. You also need to consider their updates. Once you downloaded an SDK (usually simply a library residing statically within your project), it’s your responsibility to check if newer versions are available, what the changes are and how they affect your app.

The big SDKs would usually inform you of changes (typically via email / newsletter). After all, the same way you’re looking to keep your users, they’re looking to keep you. So you should make sure you read their notices and that they’re not ending up in your spam folder.

Nonetheless, you should create a routine – a periodic check of your SDKs and their status, either on their websites or follow them on the SafeDK marketplace. Are they maintained? Is there an update available? What does it contain? You may be able to forego new features, but if a bug or security risk is reported and/or fixed, that’s something you want to be one of the first to know about (especially if you were aware of the bug / fix in the first place).

If the SDK is publishing a changelog or documentation (which, again, the big SDKs usually do), go over it thoroughly, or at the very least check against the different ways and APIs you use the SDK to make sure nothing’s changed or if it did, that nothing’s broken.

Be the Master of Your Own Permissions

Say an SDK’s new version wants a new permission. For instance, to give you better data the SDK wants to collect information about the user’s Location via GPS. You should note two things here: the first is that your users will be prompted for new permissions and you might end up losing them over it; the second is that some frameworks (Android, for instance) allow the user to check an option that automatically updates their apps, giving no permission has changed. Once you change your permissions, the updates won’t be automatic and your users would have to manually update the app. A lot might not do so and you could potentially lose them – your new features and fixes won’t propagate to them because you obliged to an SDK’s whim.

Ask yourself is it worth it. Does the SDK really need it? Is the SDK asking for that permission to improve your service or its’ own? Never let the SDK be the decision maker. Your users are installing your app, not your SDKs. For all they know, you’re all one entity and all they care about is that no one violates their privacy. The permissions you require should satisfy your needs first and foremost. An SDK upgrade is rarely the right decision to change your own permissions and that change comes at a great risk and cost – be very aware before doing so, if ever.

Remove Deprecated SDKs ASAP

Sometimes SDKs become irrelevant or go out of business or are simply no longer usable for some other reason. When that happens, you should remove them from your app as soon as you can. There’s no use relying on them to work anymore (especially if their code includes accessing some remote server that might not be available someday).

One very distinct example that comes to mind is the popular NineOldAndroids SDK. The SDK allowed you to continue both improving your app, as well as supporting the wide range of devices out there even when Android introduced new graphic animation capabilities way back in Honeycomb. However, now that Google themselves offered a similar solution in their support-v4 library’s new version, the SDK has been declared deprecated. Anyone using it should take the SDK developer’s own advice, and stop using it, making the switch to official support library instead. That way you can still benefit from that SDK’s capabilities as well as from new updates and improvements (and when they come from Google themselves, that should really motivate you to make the switch).

Don’t Put Off Updating SDKs Too Long

Say you’ve decided to wait on updating an SDK. In a pure cost-benefit manner, it just wasn’t worth it. However, you should be aware that circumstances may change. When enough time has gone by, the SDK could simply decide it has given you ample time to upgrade and will no longer support the way you’re using it. The API the old version is using may no longer be supported and you might lose valuable data and features, or worse – cause significant impact and error rate to your users. So just because you decided not to update at one point in time, never let it be a ‘final word’ kind of thing – constantly revisit your decision and check.

Don’t Be Afraid to Switch SDKs

Just because you used an SDK in the past, doesn’t mean you’re obligated to continue using it (unless there’s some contract involved, and that usually applies only to active users on older versions). If you’re unhappy with an SDK or if its newer versions are causing you more problems, you can always look for another SDK that gives you the same services. A new version of your app doesn’t necessarily mean a new version of your SDKs, it could mean new SDKs. If you can afford the time and effort than you should at the very least consider switching to another SDK rather than staying with a buggy version and waiting for an update, or going the long haul with an earlier version (see above for why).

Summary

SDKs are a wonderful thing that enrich our apps and make our developing lives easier (for the most part, at least). However they also present us with a few challenges. One of them comes when an SDK update is available and we must decide if we want to upgrade or not. There’s no right answer. Each SDK should be measured against its’ own strengths and weaknesses, each developer should do what is most right and comfortable for him or her. I hope I was able to give you some pointers as to what should be in the back of your head, and hope you and your SDKs get along great. If you like them or hate them, if you’re looking for new ones or anything SDK related, don’t forget to stop by the SafeDK Marketplace for all your SDK needs.