The Makings of an Excellent Multiplatform Mobile Development SDK — part 2
The second in a three-part series exploring the challenges and opportunities of a multiplatform mobile development SDK and the ideals it should endeavour to pursue.
Part 1 of this series highlights the rapid change of the mobile industry and the need for SDKs to continually evolve. An SDK must be clear on what it is, what it does and keep the app developer at the forefront.
This post will cover the increased longevity of SDKs compared with apps. An excellent SDK is in it for the long run!
Excellent SDKs are platform tailored but multiplatform cohesive.
Today’s mobile platforms offer a plethora of platform-specific features and programming interfaces to suit the functionality of their own unique devices. They are created with the intention of being primarily accessed by their respective first-class citizen languages such as Swift or Kotlin. App developers expect a near native experience from an SDK for their target platform and yet require familiarity when using the same SDK on another platform. SDKs need to provide a good level of feature parity across all their supported platforms.
Excellent SDKs don’t take shortcuts.
It is quite enticing to attempt to take a ‘single framework to rule them all’ approach that would theoretically allow creation of a multiplatform SDK with only a single codebase. There are plenty of third-party solutions promising this kind of quick fix for apps but, in my experience, SDKs themselves cannot be written using these tools without significant experimentation and cajoling. They are not designed with SDKs in mind.
A third-party platform as an SDK dependency introduces an unknown variable in the turnaround time of supporting new OS version releases; see Excellent SDKs provide day zero support for new OS releases.
Supporting app developers who want to make use of these tools for their apps is a great idea, and I would encourage apps to take advantage of them, but SDKs themselves should not rely upon them.
Here are some of the many multiplatform solutions that app developers might consider making use of:
Excellent SDKs don’t take unnecessary risks.
An SDK developer should seriously consider the risks of depending upon a third party multiplatform language still in beta (Kotlin/Native) as well any solution that could be abruptly shutdown in favour of an alternative in development. Google has created the Dart programming language but is also a member of the Kotlin Foundation supporting the development of Kotlin/Native. Something has got to give and it’s probably going to be Dart that eventually joins the likes of AngularJS in the Google graveyard.
Excellent SDKs play by the rules.
The natural habitat of an SDK is between the OS and the app — a rock and a hard place. A mobile SDK needs to appease both parties when providing functionality and this means abiding by the platform provider’s rules. Use of non-public methods is essentially forbidden on Apple and Google platforms if an app is going to be distributed on their respective public app stores. Be aware that this also applies to all the underlying libraries and frameworks that an SDK itself might rely upon.
Let this be a warning to you:
It’s extremely tempting to use non-public methods that enable new functionality or significantly boost performance. What’s more galling is the high likelihood the platform provider’s own apps freely make use of them. An SDK that uses non-public methods puts apps at risk of rejection which ultimately leads to a loss of income. They might initially slip through the net but the discovery of just one could trigger the rejection of all apps using that SDK. Attempting to hide the use of non-public methods by some coding trickery is likely to cause more issues when finally detected. Don’t do it.
For the Apple App Store be sure to check out the App Store Review Guidelines (search for ‘public APIs’) and for Google Play check out Restriction on non-SDK interfaces.
Excellent SDKs provide day zero support for new OS releases.
Platform providers have well publicised release cycles so annual releases of new OS revisions shouldn’t come as a surprise. SDKs should strive to be tested against the first beta of a platform provider’s latest and greatest OS at the earliest opportunity.
There are three goals to be met when testing an SDK with new platform betas and they should have the following prioritisation:
1 — retain binary compatibility
2 — allow apps to make use of new features
3 — allow SDK to make use of new features
The first goal is to make sure an app relying upon an SDK continues to function as it previously did when a user upgrades their device to the new OS. This begins with validation that the existing app and SDK, created with the old IDE, without making use of any new functionality, continue to work as originally intended. Early communication with app developers about any issues that arise, or the likelihood that they will need to integrate a new version of an SDK when it becomes available, ensures trust in an SDK. It’s even worth communicating when no actual changes need to be made for a new OS release. Addressing all the issues in this category is providing day zero support. It should be the aim of an SDK to meet this goal during the early betas and then continue to test with every subsequent beta as they are released. It has been my experience that platform providers can sometimes make significant changes immediately prior to or when dropping the first Golden Master (GM) / final developer preview. It’s not common but it does and has happened.
The second goal is to allow apps to take advantage of the exciting new features when using the new IDE. This can sometimes be the most challenging goal and often app developers expect this to be met much earlier than feasible. It’s a reality that some of these new features can’t be totally planned for in advance, are a surprise to everyone and can be poorly documented (if at all). These new features and their respective public methods can be dramatically altered during the lifecycle of the beta releases and sometimes removed by the time the GM / final developer preview drops. This goal should be met within the first few weeks following the official release of the new OS version.
The last goal is to continue to push the development of the SDK itself by leveraging new platform features. An excellent SDK never ceases the pursuit of perfection. As I noted at the start of the series:
SDKs that don’t adapt get ditched
Summary
Excellent SDKs:
- Are platform tailored but multiplatform cohesive
- Don’t take shortcuts
- Don’t take unnecessary risks
- Play by the rules
- Provide day zero support for new OS releases
That brings an end to part two of this series which I intended would highlight how an SDK behaves in order to be a longterm success. Part three will focus on the people required to make and maintain an excellent SDK.
