APIs are all very well; you can start coding quickly, and you can get your app up and running. But then the service you're working with changes the back-end code it's using, and you have to update your app. And that's when you realize: you didn't document everything you did, and it's probably as easy to rewrite everything from scratch than to change your existing code.
A well written SDK makes developers' lives easier, giving you tools and libraries that can be used in your applications, as well as documentation that shows how to perform common tasks. Companies will make SDKs available for commonly used platforms, and for platforms where they want to encourage development, like Windows, iOS and the web. If something changes you won't need new code; just a download of an updated SDK.
We recently spoke to Box's VP of Platform, Chris Yeh, about the company's new $REV developer program, and its launch of its own SDKs. While $REV is a revenue-sharing program designed for existing software companies wanting to partner with Box, the SDKs are for anyone building any app, and are based on Box's existing APIs. Yeh notes that while the initial release of SDKs targets Android and iOS, there are plans for more, "We're platform agnostic at Box, and this is an effort to create a unified framework for multiple languages".
As Box has grown, its app focus has changed, moving away from productivity tools and focusing on verticals. Delivering SDKs like these should make it easier for developers to build these focused apps as they won't need to spend time re-inventing the wheel on common functions. Yeh points to some of the SDK's features as part of this process, "We're seamlessly handling enterprise identity, and providing our own Box file pickers, in just a few lines of code."
Part of that is providing ways to quickly implement single-sign on in Box-connected applications. Yeh notes that most implementations of SSO are different, "Many companies implement SSO through browser and expect it to be running behind the firewall, and if it's outside the firewall like it has to be for Box, it doesn't work." By providing tooling in an SDK, Box can help prevent developers from building apps that don't work, as Yeh says, "It's not standard-based, so our engineers have just written code and we've put that in the SDK so our developers can take advantage of it." Getting rid of common bug bears with code like this that can be supported makes sense for a company like Box, which is relying on third-party developers - both external, internal, and user - to extend its platform.
Box's new SDKs don't replace its APIs by any means. If you're working with another language, or trying to build your own tooling, then by all means stick with APIs. Getting to grips with lower level tooling can help you solve a complex problem, or can make it easier to bring two parts of an application together. You just need to be aware that if something changes in an API, you're going to need to write new code; while with an SDK all you're likely to need is a new version of a library.
With SDKs for iOS, Android and Java (you need both the Android and Java SDKs to build Android apps, as one builds on the other), you're able to work with most common enterprise and mobile platforms. Box's next SDK will be for Python, and Microsoft developers can use a third-party C# SDK that Box links to from its web site. You won't get all the features of the full, raw RESTful API, but you will get the code you need to build your app.
There's a very good reason why a company like Box makes SDKs and APIs freely available. As Yeh points out, "An app developer integrates with Box on iOS or Android through our new SDK, exposing their code to our user base." Those users' relationships with their apps affects their relationship with Box, "We're very interested in the way end users interact through the app with Box, especially the paid users. […] If they are using a third party app on box they are usually way more engaged on box than other users, they are more loyal they are way less likely to churn out." And if they're not paid users, there's still an opportunity for Box, "Correspondingly in enterprises because users are using [Box] we have more opportunity to up-sell."
Getting you to get your apps right may well make it easier for Box to sell accounts, but it's also important in making your apps sticky, and well used (and adopted and supported by in-house IT). Users don't want to spend time learning new ways to do the same old things, and by taking advantage of Box's telemetry and experience, you'll be making your users' lives simpler, as well as yours. Building apps using an SDK doesn't always mean better code that is faster, but here Box is putting its business model on the line for you. That's important, as it means that there's an incentive on both sides to deliver the best code possible.
It also means that it doesn't matter to Box whether developers are professionals, or users bringing their own skills to fill a need for a project or a department. All that matters is that the apps they build are the best possible. That's why there's plenty of sample code on Github alongside the SDKs. The documentation shows you how to call out to browsers to use OAuth2, to authenticate with the service. There's also information that shows how to work with asynchronous calls to the Box cloud service, and video tutorials to help you get started.
Yeh was talking about the $REV program when he said, "Let's incentivize developers to make users' experiences better", but the same is true of Box's new SDKs. By providing code to deliver common experiences for common operations, the SDKs make it easier to build apps - as well as making them easier to learn and use. Better experiences like that are a win for everyone.