When your iOS and Android Application should be separate from SDK

It’s very popular requirement for modern mobile applications these days, to have separation into two modules: Application and SDK. But it’s can be crucial for you to understand when you actually need it and when you can save resources by making monolith application as a single module.

And I’m talking about native application development using Swift or Objective-C, Kotlin or Java — it doesn’t matter. These principles can be applied to both platforms.

In my previous experience I had a lot of different type of applications, and only some of them deserved this complex structure with two or more modules. So what actually determines need of it?

First one and the most obvious sign is that you need this separation is in initial requirements, to share core functionality with 3rd party developers, other teams and departments, or just company partners.

Second sign is a complex structure with multiple logically independent modules and multiple use-flows like: Session Management, Entity Management (get, list, create, delete, edit and other actions), Time-based Location Tracking, Advanced Logging and Reporting, Web-Socket Connection Management and other components.

And finally you can choose to do it yourself initially because you think it can be future-proof and if such requirement suddenly appear — you will be ready. But you should be aware that you will need much more resources to actually do that, to define clear interfaces with parameters and callbacks as well as implement them.

Anyways, if you choose to do it — just be aware of additional resources loses, like:

  • Additional time to implement clear independent interfaces, even if you need to use it only once or twice :)
  • Additional time to avoid libraries- or approach- dependencies restrictions. For example you want to use Reactive Programming principles in your SDK module, that will greatly decrease amount of work/code in your application module — you first need to decide: or you force users of your SDK to match your approach or you need to remove such structure-dependency and allow your users to decide for themselves.
  • Additional time to avoid API (OS version) restrictions. To support more applications your SDK can integrate into — you need to minimize API level, therefore instead of using new cool SDK features — you will need to hack’n’support old features to be consistent across apps.

Thanks for reading! I hope you find it useful or at least it gives you some fresh ideas. I tried to keep it short, but if you want some more particular examples and/or have suggestions — Please let me know in comments below!