Best Practices for building a world-class Mobile SDK? How to Build the Perfect SDK?

Best Practices for building a world-class Mobile SDK? How to Build the Perfect SDK?

Rakesh Jha (Product Head/Chief Architect) Rakesh Jha (Product Head/Chief Architect)

Rakesh Jha (Product Head/Chief Architect)

Product Head | Driving Industry Innovation | Architecting Multi-Geography B2B2C Ecommerce Ecosystems | Expert in Business Strategy, Market Analysis, Technical Leadership and Revenue Generation

发布日期: 2020年4月22日
+ 关注

An SDK is a Software Developer Kit that includes all the information and pieces needed to create a specific application, Mobile SDK whether we are talking a .aar file, .framework or otherwise.

 

Ideally, an SDK should include libraries, tools, relevant documentation, samples of code and implementations, process explanations and examples, guides for developer usage, limitation definitions, and any other additional offerings that would facilitate building functions that leverage the system/business.

 

While developing SDK, one should keep in mind about simplicity, transparency, security, frugality, documentation and communicating with your users.

 

Check List for creating/developing SDK

  •  The latest version of the language should be used,
  • All the code should be split in modules, which correspond to a set of features (for example, in the Asset1 module we encapsulate all the functionality regarding the manipulation of assets).
  • Each module functionality will on itself be fully described in a system (product), whatever we have
  • High level of application architecture
  • APIs communication and integration (in-app as a feature)
  • Code - simple code means your consumers find it easy to use ( expose only one interface class; short method signatures, e.g. a small number of input parameters; Hide any class and method consumers don't need to use, i.e. make classes/methods public only if consumers must use them, otherwise use the local or private scope. Some IDEs can help you do it automatically via code inspection and cleanup.etc.)
  • Documentation: Make your documentation as simple as possible.
  • An easy start to using the code
  • As simple as integration effort, make try to reduce the integration effort
  • Parameter of method should be simple and lesser if possible create the polymorphic method
  • Documentation should be clean, short and simple
  • Should be diversity in your SDK, means should support, all set of IDE.
  • Try to solve (Integrate) every feature and function and share it into git individually, let at be 100 of small (Basic) project in git with proper documentation i.e. README.MD file
  • Create a blog for your SDK
  • Should follow the coding guideline standards, and good into naming conventions
  • Communicate new features and deprecate old
  • proper error and exception handling and for every error must be proper status code
  • proper checks memory leak
  • remove all unused class/method from the release
  • especially consider for NFR
  • Backward compatibility
  • Don't drain the battery
  • special consideration for network usage
  • try to minimize the size of SDK, resources used
  • Permissions, security, and others should be called out in a proper way
  • Enable SSL for all networking calls to encrypt HTTP traffic
  • follow proper build process, CI/CD, QA
  • plan for the next version and the feature, stick with the timeline and date

 In terms of iOS, just as sample ref

Do’s

  • Choose language Objective-C or Swift.
  • If you are writing the SDK in Objective-C make sure you create a wrapper for Swift.
  • If you are writing the SDK in Swift make sure you support all versions of Swift.
  • Support both static and dynamic libraries so that users can drag and drop and compile their app.
  • Make your dynamic framework scheme shared and tag your release with semantic versioning on GitHub to support Carthage.
  • Add Podspec to support CocoaPods.
  • Add Package.swift for Swift package manager.
  • Support other platforms such as tvOS, WatchOS.
  • Support at-least one version back. ex. iOS 13,12.
  • Create high level overview and api documentation.
  • Document the expensive api’s if any.
  • Include Tests.
  • Use Continuous Integration.
  • Use GCD with low priority queues.
  • Monitor memory utilization.
  • Use access specifiers accordingly to restrict the access.

 

Don’ts

  • Don’t rely on UIApplication.
  • Don’t use NSLog.
  • Don’t run unnecessary tasks on high priority.
  • Avoid dependencies so that when you upgrade your SDK no need to wait for upgrading the dependencies.

 

Integration

  • CocoaPods

https://guides.cocoapods.org/making/making-a-cocoapod.html

  • Carthage (Carthage only supports dynamic frameworks, which are only available on iOS 8 or later. And any version of OS X.)

https://github.com/Carthage/Carthage

  • Swift Package Manager

https://swift.org/package-manager/

  • Manual drag and drop modules/source code

Publish & Update

  • GitHub

Integrate with a hybrid platform

I couldn’t find any leads.

Installation guide & Documentations

  • In GitHub the Podspec file will autogenerate the basic overview.
  • Create a simple demo app and include/supply it along with the SDK/framework.
  • Provide the Screenshots/Video of the sample/demo app.
  • Provide migration guides.

Ref: https://github.com/Alamofire/Alamofire

 

References

 

Contributor - Hema Murli


 

 

要查看或添加评论，请登录

Rakesh Jha (Product Head/Chief Architect)的更多文章

社区洞察

其他会员也浏览了