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

3rd Party Solution Considerations (Part 2)

Now that we have a good clarity and understanding around the finer nuances and purposes of SDKs, Frameworks, Libraries, API’s, and REST API’s, let’s continue to dive further into the this subject.

In this post we’ll be comparing SDKs and REST APIs for mobile platforms.  I’m doing this because this blog has a mobile focus and in the mobile world, these are the two terms most often used.  One final note, going forward, the term API will be referring to RESTful APIs.

Now that we have our parameters for this discussion, let’s dive into the real question we’re here to address:

Why and when to use one over the other?

The first point I’d like to bring up is that on mobile, and most other platforms, the above question’s answer isn’t always going to be entirely binary.

You may very much have some or more of the following combinations:

• A single mobile SDK
• Multiple mobile SDKs
• A single API
• This may be a user API which may include, add, update, delete, etc
• This is a single interface, not a single end-point
• Multiple APIs
• This may be a user API, a vehicle API, a school registration API, etc
• SDK(s) which wrap API(s)
• SDK(s) which is/are supplemented by API(s)
• API(s) which is/are supplemented by mobile SDK(s)

Regardless of the any of the above combinations, the fundamental question still remains, when and why to use SDKs vs APIs and vice-versa.

SDKs:

When considering delivering your solution as an SDK, you need to first understand where SDKs are going to provide functionality which an API is not going to be able to.  This first point is referencing the hardware (HW) on the device.

While PWAs access hardware via calls through the browser as previously discussed, what we’ll call an SDK solution for PWAs may a series of JavaScript files.

However, this point still remains - if you need to make specific or extensive use of “on device” HW, you’re heading down a road to provide an SDK as part of your 3rd party supplied mobile solution.

Let’s take a look at the image below:

As we look at the above graphic, we see that some of the standard HW is presented such as the camera, gyroscope, GPS, and accelerometer.

The others I want to address with a bit more specificity.

Multimedia

There are a multitude of different scenarios here, especially since you can play music and display images and video via a PWA.  However, there are limitations you may need to overcome.  Limitations which you’ll need to allow the app developers ingesting your SDK to not worry about.

One such example is background processing/playing of music along with real-time notification when the music stops, a favorite song is playing, etc.

The point here is, the more multimedia control you want to give developers integrating your SDK, the more your solution is likely going to be an SDK.

External HW:

This is a less common solution today, but is going to become much more prominent as IoT becomes more common in our everyday lives.  Today, an example may be a blood pressure device you can plug into your phone.

This scenario comes into play when your organization may make a custom HW device.  To have the mobile phone connect/communicate with your device may be any of the following:

• BLE comms
• Socket/Network comms
• http(s) comms
• Directly plugged into the phone
• Etc…

Here, regardless of the communications pipeline, it isn't reasonable to expect developers to have to figure out all the nuances of your device’s communication - even if executed via a standard channel such as BlueTooth.  This isn’t likely going to get you device wide adoption.  Here, a well structured SDK delivered would be the likely expectation of a mobile app developer.

However, in the direct connect scenario, an SDK will be almost mandatory.

Disk:

Here is a piece which dives us right into understanding your customers.  First, yes as discussed in our PWA post, we can store data to disk via a PWA, but with some real restrictions and much less control.  However, with an SDK, we can store significant amounts of data to the device with near complete control.

Now, is this aways the best idea, or even necessary?  Sometimes absolutely and sometimes absolutely not.

As an SDK provider, you’re stating that anyone developing an app can at least compile your SDK in.  You may have some SDK keys to “activate” things, but that aside - if your customer is mostly commercial and you provide solid security, this may work just perfect.  But if you’re looking to support a super-duper secret ninja society - this may not be allowed at all!

This doesn’t mean you don’t deliver an SDK, if just may mean this portion of the argument for or against it, is out.

SDK Considerations:

A point here, as your SDKs tend towards more specialized capabilities, not only do they themselves tend to become rather complex, they also tend to become rather large.

If you remember from our previous post about user adoption - maintaining a small app size matters and if your SDK bloats the final mobile app, you may have some issues getting app developers to adopt your SDK.

Additionally, when offering an SDK to mobile app developers - if your SDK requires permissions to the device's HW such as the microphone or GPS - remember, those permissions will come through the app, not your SDK.  So, if you require hardcore GPS to maintain the functionality your SDK provides - the app can determine if it wants to allow that.  Again, it is the app’s profile/configurations which determine the permissions it will ask for.  Normally not an issue when properly advertised, but certainly a consideration.

And finally, not that you completely get away from this using an API, but when developing an SDK, and that SDK uses a particular cloud provider backend, you need to be careful to avoid clashes with the app’s initialization.

For example: Let’s say you’re deploying an SDK which leverages Google’s Firebase.  Additionally, there’s an app developer which uses Google’s Firebase for their cloud.  Well, in Firebase, there’s a configuration file with a default name that is read when the app initializes the Firebase connection.

So now, if your SDK and the app developer don’t put in a specific configuration name, and both read from the expected default file name - where data goes is anyone’s guess (probably to whoever made the last call to init) - but the data going back and forth…. well, that's up for grabs.

If we take a look at the image below, it gives a high level overview what this may look like (Here the light blue is the SDK’s resources and the dark blue being the app’s):

Essentially, the confusion in the diagram, is the exact confusion which takes place when resource conflicts happen between an SDK and its host app.  What gets initialized and what data goes where is anyone's guess.  The likely scenario is the app will crash, but if this architectural consideration isn't taken into account when your team first starts developing the SDK, this can be a huge pain to fix.  And you'll likely loose your customer in the process.

Now, all this said, these are not insurmountable issues, but it is absolutely something you need to keep a lookout for if you’re deploying mobile SDKs.

Ie: You’re ultimately responsible for the project - bringing this up with your engineers isn’t going to hurt you.

APIs:

When considering delivering your solution as an API, let’s look at the functionality an API is going to provide.  Here, API’s are going to provide direct access to your cloud infrastructure’s functionality, computing capabilities, and data storage.

Let’s take a look at the image below:

As we look at the above we see that the API provides its functionality to its clients via processing which takes place on an external system(s) but doesn’t give us the powerful control of on-device HW.

This is pretty straight forward but leads us into our next talking point which is some of the constraints you’ll want to consider when providing an API beyond just the HW consideration.

API Considerations:

First, taking a look at the image above, we see that there is a high degree of dependency on network connectivity when supplying an API.  While anyone working on their machine in an office is rarely worried about this, the mobile device certainly can be a very different story.

Our mobile devices are mobile and therefore the quality of the connection, which can change quickly must be at the front of a mobile team's mind.  This brings up the concern an app developer may have if they have a highly performant mobile app - even when off-line or in a constrained network environment.

Additionally, as we work from our machines from an office or have a cloud server running, calling APIs which require large volumes of data is normally of mild consequence.  Sure there’s a limit to this, but overall, we don’t typically think how much each packet is costing us when we’re using a web site or making REST API calls.

Again, I understand there are limits to this, but they’re more often pretty high limits.

However, this isn’t the same for mobile.  Your app developers pulling in your API may be extremely worried about their customer’s data plans, they may have a high number of customers in regions with less reliable network infrastructure.  So, if your API uses especially high data volume at high cyclic rates, or takes an enormously long time to send data back to the client - your API may not get the adoption you’re looking for.

The above points bring up why, when developers say “just develop an API, then we don’t care if our client is on a desktop, server, mobile device, etc.”

There are differences, and you should be aware of them.

SDK API Mutual Support:

As we look at some of the issues of both the SDK and APIs, there are some that you’re just not going to get around, but with proper knowledge and planing at higher levels in the organization, they’re very manageable, and much less painful to deal with.

Below are some scenarios to consider when looking at various ways an API can be supported by an SDK:

Have an app that requires high performance even when offline?  Have the SDK store some data that can be used until connection is good.

Have an API that’s data hungry?  Have the SDK perform some preprocessing.

Have an API which is computationally intensive on the backend causing slow responses?  Look to see what you can off-load to the SDK. Ie: Edge computing.

Also, while every API is most likely https - that’s great for encryption in transit, but if the data is sensitive and you don’t want it in plain text when stored in your cloud, the SDK can perform the encryption via the user’s public key on device, alleviating your API from some worries.

This is what we very often see in industry, having SDKs wrap, but also support some APIs.

Below is an image essentially outlining some of the various methodologies seen with SDK and mobile app integrations.

Conclusion:

As we finish up the initial component of this blog dealing with mobile development strategies, this finalization of 3rd party deployment hopefully brought everything full circle.

I hope I’ve provided you the information you need to understand and interpret your mobile engineers a little better.  If there is anything pertaining to mobile that you would like more information or clarity on, please feel free to reach out.

As we progress our conversations with this blog, we will next begin to explore today’s IoT, 5G, Edge, and Fog computing environments.

Read More

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.

Read More

Super Apps Super Charged using App Clips(Part2)

App Clip Supporting Super Apps

Based on the last post, App Clips sound pretty cool - and that’s because they are!

The coolness certainly jumps out when business leaders are looking to onboard new mobile users in an incredibly difficult market. App Clips provide real opportunities to minimize the user’s barrier to entry - which is paramount in mobile.

Of course, our primary concern is having a well rounded mobile strategy which includes developing App Clips to solve the appropriate issue.  This is where we must be diligent to avoid the dreaded “Everything App Clip” architecture attempts.

Avoid this at all cost!!!

While there are several pitfalls waiting for an ill prepared team, it may not always be obvious just why everything an App Clip module is bad.  It seems that simply breaking out an app’s architecture to be modular and then to leverage that modularity to develop each feature as an App Clip is the way to go.  In fact, it sounds like a very well architected Super App to have it designed and developed in this manner.

However, it isn’t…

Don’t get me wrong, of course modular design is the way to design and develop software.  

However, this isn’t just about developing modules.  Instead, this is about incorrectly trying to design modules so that they primarily support an App Clip rather than primarily supporting a Super App.  As stated earlier - Develop App Clips to resolve the appropriate problem - don’t contort your Super App into a bunch of App Clips.

Let’s explore this seemingly contradictory point of view.

We’ll take this post from two perspectives:

• App Architecture
• Mobile O/S Restrictions

Architecture:

From the last post, we had our fictional Super App which was architected to provide several features such as Ride Sharing and Food Delivery.  Further, we saw that each of those features leveraged several services developed to support the functionality of those features.

For example, all features leverage the “Payment Services” - a few leveraged the “Vehicle Availability Services.” Etc…

To recap, the Super App’s architecture drawing is shown below:

Based on our understanding of our fictional Super App’s architecture, let’s take a look at it first from the perspective of slicing our features out into App Clip modules.  

Here, in the ideal, perfectly fitting puzzle - below would seemingly make a nice series of App Clips for our Super App.

Taking a look here, we see our first issue.

Above, notice that in the ideal “Everything App Clip” world, we see that each App Clip would need the “Payment Services.”  Remember, each feature doesn’t necessarily need only “part” of the “Payment Services,” each feature is likely to use a significant portion, if not all the “Payment Services.”

This can lead to the next train of thought that leads to the next set of issues - “We’ll just make the payment service modular as well!”

Is this a good idea?  Absolutely it is. 

However, again - the “Payment Services” should definitely have a modular design which are designed to primarily support your Super App!  Not be primarily modularized to support an App Clip.

In fact, it would be a safe bet that the payment service’s solid modular architecture would look something similar to the below image:

Above, you’ll notice there are several modules which make up the “Payment Services” and modules that make up those modules…

Also, notice that there are necessary interdependencies among these modules which make up the “Payment Services.”  This is fine and is how modules primarily supporting a Super App should be designed - and this is good!

Now take a look again, and notice there really isn’t much of anything you can break out of the “Payment Services” - at least not without some serious reworking.  AND - unnecessary reworking since your “Payment Services” are designed to primarily support your Super App.

App Clip Evaluation

So it may seem we’ve come full circle saying that App Clips aren’t even worth it.

Nothing could be further from the truth!

It’s just that there must be an understanding how to responsibly develop to fully leverage them.

For the sake of the remainder of this post - let’s say the “Payment Services” are big (measured in MB), but not so huge that it limits us from using it inside an App Clip.

OK, so we’ve evaluated each of our Super App’s features and the services those features leverage.  Now, when we look at the features individually along with all the services each feature uses - we see something similar to the image below:

In the image above, I’ve tried to size the blocks representing each service’s appropriate size (in MB) based on the number of features which leverage the service’s functionality.  Ie: the more features which leverage a service, the larger the service is likely to be.

NOTE: We’ll talk more about App Clip restrictions, but here I need to point out the App Clip size limitation - measured in MB

• iOS 16 & Android: 15MB
• iOS 15: 10MB

So, with our Super App’s current architecture - based on size - it appears that Ride-Sharing and Food-Delivery both appear to be good candidates to become App Clips - now we'd need to choose.  This is because both features and all their services, neither overruns the App Clip Size limit.  This is represented by showing all the functionality staying contained within the bounding box in the image.

Let’s take this one step further. Let’s say after evaluating our Super App features and corresponding services, we notice that “Ride-Sharing” and “Food Delivery” have a lot of overlap.  Let’s say we further evaluate and notice that between these two features, we can leverage their overlapping services and still be within the App Clip Size limits.

Now we have the potential for a single App Clip with multiple experiences/entry points as shown below.

Now that we’ve evaluated our Super App, we notice where we can focus some optimizations between the “Ride-Share” and “Food Delivery” features.  This means, we can responsibly fine tune some modules to support these features for both our App Clip and our Super App.

Here, your technical team can absorb some modularization to support App Clips.  But again, having a few well defined modules to support App Clips compared to every module supporting App Clips is a very different thing.

App Clip O/S Layer Restrictions:

So, we have touched on the App Clip size limits - there are others…

In order to understand where the mobile providers were coming from when putting some of these restrictions together, it’s important to remember a few points about App Clips:

• They are meant for quick interactions
• Install seamlessly and instantly (ie: The size limits must be small(er))
• If the user doesn’t use the App Clip for a period of time - the App Clip is automatically removed - along with the data associated with it.  (Ie: Limited keychain access and no registering notifications which may fire after the app clip is removed)
• App Clips are meant to give a user a chance to use some of your app and get inspired to download and install the full app (ie: Features in your App Clip must be entirely available in your full App.  No feature in an App Clip can be something which isn’t also in your full app)

So now that we understand what some of the guiding principles are around App Clips, let’s take a look at what these things look like out in the wild - then we’ll dive into their restrictions a bit more.

Above, what we see is that the App Clip is in-fact, a separate entity/binary which has no interaction with your full app when it’s installed onto the user’s phone.  Thus, it is completely independent of your full app.

In the example above - the App Clip has three experiences/entry points.  This is the same principal to the Ride-Share and Food Delivery concepts we saw earlier.

What’s important to take away from this image is:

• Whatever features are contained within the App Clip, must also reside in the code base of the mobile app on the app store
• The App Clip can have as many experiences/entry points as will fit into the size limit on the deployed platform

To round out the whole picture of an App Clip - though it’s a separate binary, when the user downloads your full app, the App Clip will essentially line up as demonstrated in the image below:

App Clip further considerations:

Earlier we organized our features into App Clips based on size - there will be other considerations which may negate a feature from becoming an App Clip.

For instance: earlier we decided to put the Ride-Share feature into an App Clip because it met the binary’s size requirement.  However, if that feature or any of its services make heavy use of monitoring real-time location tracking - you’re out of luck. You won’t be able to make that feature into an App Clip because App Clips can’t use continuous location monitoring.

Again, this may seem like an unnecessary restriction until you really step back and look at the intended user interactions of App Clips.  The App Clip's use case is to be in the foreground and active on the user's screen for the user to engage with it quickly - not to have App Clips executing long-term background bluetooth, media, and/or network operations.

As we now understand some of the concepts and restrictions regarding App Clips, we can see that the “Everything App Clip” will quickly break down into a likely failure if we were to design a Super app in this way.

However, the right feature design to leverage an appropriate App Clip - that will provide a likely successful mobile deployment and help bring in new users more easily.

Conclusion:

So as we close out our App Clips posts, there’s really just a few of points to take away:

• “Everything App Clip” isn’t likely going to turn out well
• Understanding the App Clip’s use case is paramount to understanding its limitations
• Module design needs to be considered as primarily supporting an App Clip use case or the Super App use case
• App Clips can be a powerful tool in your arsenal but they aren’t a full spectrum solution

Now that we understand App Clip’s limitations - we can design for and fully leverage their incredible benefits in driving more and easier new user engagement and user onboarding.

Below, for reference, is a high-level list of some of the additional limitations of App Clips/Instant Apps:

Some of the high level App Clip Limitations (there are more):

• Size
• iOS 16 or later 15MB - earlier versions 10MB
• 15MB is also the size Android looks for
• Are only supported on mobile devices (Not on wearables or desktop)
• Must use features in your app
• Can’t track user location via continuous location monitoring
• No background networking activity
• Can’t access Wifi or Network State
• Bluetooth only while app clip is in use
• Contacts, files, messages, reminders, photos, fitness/health data

Read More