3rd Party SDK/Framework Solution Considerations (Part 1)

3rd Party Solution Considerations

The mobile strategy of an organization may revolve around an amazing mobile or edge device technology, capability, implementation, or idea.  However, does that mean that same organization should invest its mobile strategy, development, and time into a single mobile app/PWA or edge device for that capability?

If the capability is that incredible - why limit it to a single edge device or mobile app/PWA or any single ecosystem?  Instead, why not get it into as many devices as possible?

We’ll be exploring this very question in the next two posts.

For this initial post, we will guide our discussion towards refining an understanding of terminology often used when discussing 3rd party distribution solutions.

We’ll start here since the various platforms, mobile apps, edge devices, and web often use the same terms interchangeably but often have very different true meanings.  Getting this clarity now will allows us to have a full and rich featured discussion in the second post of this two part series.

NOTE: Going forward - I’ll be referring to edge devices, PWAs, and mobile apps simply as mobile apps.

The area’s we’ll be exploring in this initial post are mobile distinctions for various 3rd party solution deployments.  We'll clarify the differences between:

• SDK Clarifications
• Frameworks
• Libraries
• SDK/API Distinctions
• SDK/REST Partnership

SDK Clarification: SDK - Frameworks - Libraries:

Before we begin, let's first look at an image which outlines how SDKs, Frameworks, and Libraries "tend to be" differentiated.  I use the term "tend to be" because this isn't a hard and fast rule.  ie: Ferrari's tend to be faster than Hondas - until they put a sported out Honda engine designed for Formula-1 into a car.  Again - when referring to SDK/Framework/Library differences, those differences "tends towards" the image below. 

In the image above, when we mention Easy, Pretty Easy, Difficult, and Very Difficult - it's referring to most mobile app development teams and their more common tolerances to use and incorporate your organization's solution into their mobile app.  The image above, is meant as a reference as our discussion proceeds.  Remember, it represents an outline - not a hard & fast rule.

With our visual reference, let’s now dive in to clarify some terms which often get intermingled, jumbled, and often times misunderstood.

Ultimately, as a mobile development shop, deploying your capabilities for mobile app developers to integrate into their mobile solutions, you’ll mostly be talking about SDKs and REST APIs.

• SDK: Software Developer/Development Kit
• API: Application Programming Interface
• Often simply referred to as “The Interface”

(More on the REST part in a bit)

SDK & Frameworks:

First, let’s address the SDK in better terms and clarify its distinction with another term often times more specifically confused with SDK - The Framework:

• SDKs can include Frameworks
• SDKs and Frameworks are included in the development environment as a dependency
• Meaning, mobile app developers compile the entire mobile app with the SDK’s and/or Framework’s code along with their own code to build the complete mobile app
• The image below gives a visual regarding what this looks like for mobile app developers (it also outlines why you need to keep your SDKs and/or Frameworks as small as possible):

• Though SDKs and Frameworks perform specific tasks - Frameworks tend to be more specific. Ie:
• Bluetooth Framework
• WiFi Framework
• Telephony Framework
• Example: A “Data Transfer” SDK may leverage all three of the above frameworks

A bit more clarity on a point which can lead to confusion - there may be platform and/or partner requirements which drive specific naming conventions.  For example, on Apple you may deploy a “Framework” by naming convention, or a “Package” on Android, again by naming convention - or again by naming convention, a “library” in another mobile development ecosystem.

It can be argued that there is no, or many differences between SDKs and Frameworks, but these mostly come down to packaging and subjective definition regarding the scope of capability.

For technical business leaders - it will normally suffice, and is worth a 2 minute conversation with your engineering team(s) for clarity’s sake to determine what your 3rd party distribution is going to be referred to as going forward.

SDKs & Libraries

Here, there are real technical considerations in-spite of the fact that the term “library” is often used both synonymously and interchangeably with SDK in non-technical discussions.  The issue here is that something which has deep technical nuances can lead to a lot of confusion along with the “well, not exactly” technical term, getting brought up more and more by your engineers in conversations which use the term “library” when “SDK” would be more appropriate.

Libraries can be thought of as:

• Lower layer components used to build larger software components
• Not dissimilar from Frameworks, but here, our Bluetooth framework may call into the O/S layer BLE driver library which actually interacts with the hardware.  Again, this is a high level distinction for clarity’s sake.
• Components your code calls into at lower layers
• For example: I may write a spell checker SDK that has really cool word highlighting and a spell ratings capabilities.  However, in my SDK, I would call into the lower layer libraries for the actual spell checking functionality.
• Know that this could be a Framework as well
• The distinction could come down the compilation settings and rules how an app developer ingests the functionality your organization is supplying.
• Know that an organization can directly deliver a library and call it a Framework or SDK - and plenty do - but in the mobile world, we tend towards SDK or frameworks over library because of the reasons outlined below.

The below is here to highlight that the technical nuances of libraries really can hinder technical to business discussions and vice-versa.

Libraries, in more technical terms can be:

• Static libraries:
• .a and .lib are some of the common extensions
• Means the entire library is compiled into the app at compilation time
• The library’s code is loaded into memory as part of the app
• Dynamic libraries:
• .so and .dll are some familiar extensions
• Means the library’s interface is resolved at compile time and the functionality is resolved at link time
• Components of the library are loaded into memory at some point after the app starts running
• Could be loaded as soon as the app starts running
• Could be loaded only when a user selects a specific option or taps a certain UI component

Know that there are very real specific technical considerations when deploying libraries directly, and more than just the considerations pointed out above.

When engineers discuss libraries, the above points are considerations normally at the front of your engineer’s minds.  Therefore, talking about deploying libraries vs SDKs is a very different conversation in technical terms.  This can lead to difficult conversations with your engineering team when you use the terms “library” and “SDK” interchangeably without clarification between you and your technical team.

To wrap up the library discussion, it should be of interest here because on mobile platforms, you have very little control over these library specific aspects, since on mobile, you rarely develop and deploy actual libraries directly - instead they’re part of the packaging the IDE puts together when compiling your mobile archive/app, framework, package, or SDK.

Know that it is not impossible to directly deploy an actual library file/files for mobile solutions - it’s just a bit more rare in the mobile world, but likely will be much more prominent in the edge device world.

Now that you understand some of the differences between SDKs, Frameworks, and Libraries, your engineering team’s explanation when referring to specifics for your 3rd party solutions will make a bit more sense.

SDK - API - Rest API Clarifications:

Up to this point, we’ve gained enough understanding to know that an SDK or Framework is a component of software an organization distributes to mobile app developers.  Those mobile app shops then compile your mobile SDK and/or Framework into their mobile app and both your mobile SDK/Framework and the mobile app’s code are deployed as part of the mobile app’s code base.

So, where does an API come into play?  Well, in two places actually…

First, in today’s world, when teams mention an API, they’re often referring to REST APIs.  Let’s put a pin in this point for a moment.

However, there’s another use of API from a developer’s perspective that could just as easily refer back to the interface of an object or component which is part of an SDK.  This is a bit more the technical basis where the term API originates.

“The API is the interface the application uses to communicate with the "programming." Here, the "programming" could be your SDK, framework, or library.

For example, if one of the pieces of functionality your SDK provides is “Get the User’s ID,” - the “interface” in your SDK to get the user’s ID may be the following function:

function number getUserID(first:string, last:string)

Here, we’d say the interface to get the user’s ID is a function which takes two strings - the user’s first and last name and returns a number representing the user’s ID.  That’s the interface/API of your SDK to get the user’s ID.

So what we’ve seen is that essentially, all that an API is, is a description/contract regarding the required parameters to pass into a function, the function’s naming convention, and the format and rules the returned results will follow.

Ie: You follow the rules, you get a user ID back.  If you don’t follow the rules, you get a well defined error back. Perhaps in this case, a negative number of the user’s ID.  More about SDK documentation in the next/part-2 of this  post.

So now, we can clearly understand terms such as:

• What’s the SDK’s interface look like?
• We know “interface” formally means API
• The API to get the user’s ID requires two strings - one for first name and one for last name and returns a number that is the user’s ID.

So, is the term API anything technical? I’d argue no.  I’d say it’s just a synonym for the term "description."

REST APIs

So SDK or REST APIs, what’s the “technical” part?  The “technical” part is the SDK and REST part - not the “API” part.

The API only describes either how to communicate with the SDK or REST components.

So the real question boils down to simply - what’s the difference between an SDK and REST? (REST is sometimes formally referred to as a RESTful - it’s the same thing.)

Let’s take an example scenario.  For this scenario, we’ll say that we have a “Registration” capability we’d like to have mobile app and PWA/web and edge device developers incorporate into their mobile, edge, and web solutions.

For this example, let’s take a look at the image below:

In the example, our "Interface" is identical regardless if it’s an SDK or REST solution.  If a “caller” wants to get the “UserID”- that caller must provide the user’s first name, last name, and SSN.  Once they do that, they’ll receive the UserID as the return value.

Here, if they use the REST API, they’ll call the “registeruser" URL directly.  If they use your SDK, they’ll call the SDK’s “RegisterUser” function directly.

Note that these two APIs are identical - the mobile app’s medium to retrieve the data between the two - ie: the application layer to your SDK’s layer or the application’s layer to the REST layer is what is different.

SDK - Rest Combination:

From the last two paragraphs above, two question may have arisen:

• If the SDK needs to make a network call, wouldn’t it just be a wrapper to the REST call?
• So why use one over the other?

If we take a look at the image below - that’s exactly what often times happens:

So why even bother with an SDK at all?  There are many reasons which may not be apparent using such straight forward examples.  However, imagine to register a user with your server, you needed to supply 15 separate pieces of data which were themselves each difficult to retrieve.  Here, a simpler SDK interface wrapper to a complex REST interface could be one reason to use this pairing in this way.

However, there are several other reasons which should be evaluated in order for an organization to provide a widely adopted 3rd party integration solution - either SDK or REST - and in part 2 of this series, that's exactly what we'll be discussing.

Conclusion:

Here, we have described some of the fundamental differences between both terminology and functionality between various 3rd party terms which are often confused with one another.  This has given us the foundations needed to be able to dive into mobile and edge considerations which will be needed for an organization to provide a successful and largely adopted 3rd party mobile solution for app and edge developers.

In the 2nd part of this post we will dive into specifics which go into the decision making when it comes to determining when and why to invest your resources into developing mobile SDKs, web REST APIs, or libraries as your organization's mobile solution.