The Makings of an Excellent Multiplatform Mobile Development SDK — part 1
The first in a three part series exploring the challenges and opportunities of a multiplatform mobile development SDK and the ideals it should endeavour to pursue.
If you take only one thing from this series, let it be that mobile development changes rapidly and SDKs that don’t adapt get ditched.
I’ve been developing multiplatform mobile applications just shy of a decade now and multiplatform mobile SDKs for nearly as long.
Things have changed!
When I first started mobile development I was fortunate enough to be just in time to witness the arrival of the iPhone. Learning Objective-C with only Apple’s documentation to follow was painful. Back then Eclipse was a necessity to create Android apps, Interface Builder was separate from Xcode and memory management was half the battle for the iOS developer (ARC was just a fledgling in iOS 4.2). A complete multiplatform mobile solution at that time would need to have catered for Symbian (the most popular smart phone platform), BlackBerry OS (the choice for enterprise), and then, as they were beginning to get some interest, iOS and Android.
Panta Rhei — All things are in flux.
Heraclitus circa 500 BC
The mobile landscape of late 2019 is unrecognisable in comparison to those early years. A cacophony of options, tools and platforms fight for the mobile developer’s attention. The lines between mobile, web, embedded and desktop development are blurring due to devices becoming more affordable, ubiquitous and yet more capable. Think of all the new technologies and buzzwords that have popped up over the last 10 years and are now rooted in the industry. It’s never been more difficult to decide upon the actual features an SDK should provide as there are essentially limitless possibilities.
Over the last decade some things have remained constant despite the relentless changes and innovation of the industry. I can’t pretend to have always known what makes excellent SDKs. This series of posts lists what has become apparent over time and I now consider as truths whenever I start a new project or look to invigorate an existing SDK. I am looking at these from a multiplatform mobile perspective, and with a history of making security focused products, but I think these statements will apply to your own SDKs or projects.
The long term benefits of sunscreen have been proved by scientists whereas the rest of my advice has no basis more reliable than my own meandering experience. I will dispense this advice now.
Mary Schmich — ‘Advice, like youth, probably just wasted on the young’ — made popular by Baz Luhrmann in ‘Everybody’s Free (To Wear Sunscreen)’
Here is what I believe makes an excellent SDK.
Excellent SDKs have well defined remits.
Identifying the core purpose of an SDK might be an obvious step but you’d be surprised how easy it is for an SDK to lose its way via feature creep over the long term. It’s extremely tempting to bolt on interesting or requested features here and there but the end result can be an SDK with an identity crisis. Be clear on what an SDK has been created to accomplish, say no to feature requests that don’t meet the raison d’être or, preferably, create other SDKs or modules to fulfil them. A successful SDK will see an increasing number of disparate and bespoke feature requests over time. SDKs are in it for the long haul.
Excellent SDKs provide silent servitude.
One of the hallmarks of an excellent SDK is an app user being entirely oblivious to its presence. If a user doesn’t know their app is making extensive use of an SDK to secure their data or provide them services, then that SDK is doing its job well. Apps advertise to the user; SDKs stay out of sight.
Excellent SDKs meet the needs of application developers.
An app must engage with end users but an SDK must engage with developers. An SDK delicately balances facilitation of app functionality that the end user needs, alongside enforcement of security that the enterprise requires, whilst providing easy integration that the app developer desires.
Excellent SDKs have an excellent programming interface.
The programming interface can make or break an SDK. A developer interacts with an SDK through its programming interface and spends considerable time and effort attempting to understand and leverage it in order to integrate their app with it. If it’s convoluted, clunky, misleading or superfluous, then integration will be that much harder for the developer, and their opinion of the SDK will reflect their experience.
I agree with Kris Wong who suggests a programming interface should be:
- Concise
- Cohesive
- Consistent
- Coupled loosely
Excellent SDKs change with consideration.
On a number of occasions I’ve been able to remove or simplify well established public SDK methods by taking advantage of new OS features, or by spending a little time considering alternative implementations. Adjusting existing public methods requires the app developer to make changes, so the frequency and number of these alterations should be minimised. Deprecating a public method for a couple of releases prior to its eventual removal goes a long way towards preparing app developers. Most modern languages and IDEs have an array of features to support deprecation and do a good job of warning the app developer. A clearly documented deprecation policy with transparent timelines is a welcome addition.
Excellent SDKs have clear and concise documentation.
Documentation should not be an afterthought but something that lives and breathes with the codebase. It should be embedded in the library or header files so that it appears in the IDE. It should be published on the SDK’s website and a copy or link to it should be included in the SDK download. It should include discussions on how features work, how to integrate the SDK for the first time and the whereabouts of any developer resources. Example applications, integration tests and unit tests are all necessary but not a substitute. It can take on many different forms including interactive webpages created by third party tools such as Jazzy, Dokka or Doxygen, ‘ReadMe’ files or even supplementary PDFs. SDKs with an emphasis on security, or those targeting the enterprise, should additionally consider publishing a security white paper. Release notes are essential.
Excellent SDKs maintain distinct data boundaries.
SDKs have their own management data but also handle application data. Keep the two separate. An SDK must treat application and user data with care and attention. It itself doesn’t own the data, should limit its understanding of the content of the data to the bare minimum, and be a conduit for securely communicating that data between the app and the authorised components involved as required.
Summary
Excellent SDKs:
- Have well defined remits
- Provide silent servitude
- Meet the needs of application developers
- Have an excellent programming interface
- Change with consideration
- Have clear and concise documentation
- Maintain distinct data boundaries
That brings an end to part one of this series which I hope has been a good introduction. Be sure to come back to read parts two and three, which will focus more on multiplatform and mobile aspects.
