The Makings of an Excellent Multiplatform Mobile Development SDK — part 3
The last 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 emphasises the need for an SDK to be clear on what it is and does. An SDK must continually evolve to remain relevant. Part 2 covers the longevity of SDKs compared with apps.
This post in the series highlights further multiplatform and mobile considerations, the people required and the recommended infrastructure to make an SDK a success.
Excellent SDKs are platform agnostic.
An excellent multiplatform SDK runs equally well across all the platforms it supports. There is a high level of feature parity (device functionality permitting) and business logic is consistent. All documentation, programming interfaces, and branding are coherent. It is not necessary to use the same tools to create the documentation but the final presentation of the product should be thematically similar. Someone on the team needs to own the overall programming interface as well as the product look and feel.
The most difficult goal to attain is feature parity as this requires significant and constant collaboration between engineers from different teams. New features can be launched on a particular platform first, perhaps to meet the demands of an important customer, but these should be implemented with the other platforms in mind. Feature parity should be attained within a reasonable time frame. It is far too easy to over accelerate the development of a single platform and create an insurmountable feature gap. The popularity and importance of any given platform can change dramatically at any time. Someone on the team needs to own and steer prioritisation of product features.
Business logic consistency is also a difficult goal to achieve. There are often only subtle differences in platform programming interface behaviours. Be sure to have developers working on different platforms talk with one another throughout the entire development lifecycle of new features; planning, designing, developing and testing. Quality Assurance does a great job of spotting differences so get them involved early! Test suites should be similar across all platforms to validate that consistent business logic has been implemented.
Excellent SDKs understand mobile.
People like to use their mobile devices whilst travelling in cars, trains and planes. The clue is in the name. These devices do not have always-on connectivity nor limitless battery life. An SDK needs to handle offline situations gracefully and should aim to have only lightweight network usage and power consumption. An SDK should cache essential data locally and take an opportunistic approach to updating that data. Modern platforms provide power efficient mechanisms for making updates in the background. Not everyone has an unlimited data contract. Not everyone will have a device or contract capable of using the newest generation of mobile network. Wi-Fi availability on public transport is becoming more prevalent but it’s not always free and sometimes locked to a particular service or contract.
It was once true to say that mobile devices were limited in their computational power and so it was necessary to take that into account. However, modern mobile devices are now highly capable, so this constraint has been somewhat lifted over the last few years. If an SDK is targeting smartwatches or IoT devices then perhaps it may be necessary to offer limited functionality and tailor the SDK to support those platforms. Discussing how to support IoT devices needs a series of blogs all of its own.
Another truth I once learnt, but have subsequently gone to great pains to unlearn, is that mobile application users are highly demanding of a native app experience. Early web applications were greatly inferior to their native counterparts in the areas of UX and performance. Platforms offered only limited functionality to web views. Using your own custom web view to render HTML was restricted by Apple and is still restricted today. HTML5 was still in its infancy. The shunning of Adobe Flash by mobile was the catalyst that drove the accelerated development and eventual adoption of HTML5; perhaps the most successful standard ever. Today, mobile application users are more accepting of web apps as their appearance and behaviour can be indistinguishable from native apps. Mobile has come a long way.
Nemo iudex in causa sua — No-one shall be his own judge
Sir Edward Coke — circa 17th Century
Excellent SDKs are quality assured.
Overlook Quality Assurance at your peril. I’ve lost count how many times QA have uncovered serious issues in an existing or newly developed feature. Get QA engineers involved in the planning stages as well as throughout development. Treating QA engineers as a separate team to handover to at the end of development is a recipe for disaster.
An excellent SDK requires a high level of automated testing. Unit tests and integration tests should be created by QA engineers and SDK engineers in partnership. Developers tend to create unit tests that cover the majority of the expected use cases but QA excel at covering the unforeseen edge cases.
It’s often not practical to automate the testing of every feature that an SDK fulfils, but manual QA should be minimised. Be sure to use the automated testing tools that modern mobile platform IDEs provide.
Excellent SDKs provide excellent aftercare.
Errors in software are a fact of life. Developer support should be well prepared for issues to arise in order to provide excellent aftercare. Customer communication must be exemplary. An SDK should gracefully handle errors. An SDK should report errors via the programming interface so that the application also has the opportunity to react those errors. It may be necessary to provide a version of an SDK with debugging symbols included as well as a release version. Logging should be clear and concise. Open sourcing, where possible, greatly facilitates application developers with correcting issues for themselves.
Excellent SDKs engage with the open source community.
Open sourcing is not the future; it’s the present. Open sourcing parts of an SDK can have many benefits. Code quality is increased with more developers analysing the code. Those using the SDK have the ability to address bugs themselves providing a potentially quicker path to issue resolution. They can patch the SDK on their own schedule without being restricted by the SDK release cycle. They can add custom features to meet their own needs that might not otherwise make it into the SDK. There is also greater transparency in what the SDK is doing ensuring an increased level of trust. Open source the code samples of an SDK at the very least.
An SDK should publicly list all the open source software it uses. Take advantage of the various de facto standards for doing so such as a ‘readme’ file or dedicated ‘license’ file. Online documentation should also include a list. SDK developers should seriously consider contributing back to open source that they use. Excellent companies actively engage with the open source community.
Excellent SDKs are modular by design.
A monolithic SDK is a large singular framework comprised of an eclectic mix of headers and functionality. An SDK doesn’t start off this way but stealthily grows to become such a beast over time. They are a development nightmare being hard to extend, port and a burden to maintain. They are difficult to comprehensively understand, integrate and utilise. A monolithic SDK appeals to no one.
Structuring an SDK as a series of independent modules of well-scoped functionality has a number of significant benefits. It gives an app developer the freedom to integrate only what they need. New functionality and alterations can be more easily made on a per module basis. Testing individual modules is a much less daunting task for QA. Each module can be independently selective of the platforms it supports. Modules can be open sourced separately. Modular design brings clarity to the functionality of an SDK and an unsurpassed level of flexibility.
Excellent SDKs have a delivery pipeline.
There are a number of similar software engineering approaches such as continuous integration & continuous delivery (CI/CD), continuous deployment, and perhaps even DevOps. I won’t endorse a particular approach, or even clarify the difference between them, but it’s clear that an excellent SDK should employ a delivery pipeline.
Use some form of modern source control such as Git. Select a branching method that suits your team. Integrate source repositories with an automated build system such as Gitlab, Jenkins or Bamboo. Automatically run static analysis, unit tests and integration tests on every commit. Don’t ignore code warnings. Maintain a good but achievable level of code coverage. Test on real hardware as well as simulators / emulators where possible. Automate the creation, deployment and testing of final binaries and payloads with modern delivery methods such as Maven, CocoaPods or directly on GitHub.
Choose a standard versioning scheme for your releases such as ‘major.minor.patch.build’. Make use of features such as Git tags or framework plist files to better communicate version numbers. Making the version programmatically available is also very helpful to app developers. Be sure to print it to any logs.
Summary
Excellent SDKs:
- Are platform agnostic
- Understand mobile
- Are quality assured
- Provide excellent aftercare
- Engage with the open source community
- Are modular by design
- Have a delivery pipeline
I hope you found something useful in this series that you can apply to and improve your own SDK. It took me longer than expected to properly collate and disseminate all the points I wanted to make. There’s a lot to bear in mind when designing and implementing a multiplatform SDK but the end result should be an obviously superior end product.
A final thought I’d like to leave you with; regularly test how easy it is for a new app developer to search for, find, acquire, understand and integrate an SDK. If any of it is hard or frustrating they will find and use an alternative solution. True story.
