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