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

Super Apps Super Charged using App Clips(Part1)

App Clip Supporting Super Apps

In the last post we dove into the mobile Super App.  We looked into where they're penetrating certain markets and some of their pros and cons from an app and usability perspective.

In this post, we'll take a closer technical look at the Super App and some alternative architectural and user onboarding considerations.  

Don't worry, as always this is not a blog to teach coding - as promised, we will keep it at the appropriate technical level for business leaders.

To start off this post - there are four points about Super Apps I'd like to recap:

• They offer a lot of features
• They have large code bases
• Their binary sizes are large and can take up a lot of resources on the device
• They can take a long time to download

Keeping the points above as our guiding principles - there are two primary issues we'll be diving into in this post:

• Breaking down what some of these Super App features potential drawbacks are and how we can mitigate those drawbacks
• And perhaps most importantly, take a look at newer mobile paradigms which may help ease the onboarding of users into your Super App's ecosystem.

Some of the good and bad of Super Apps:

So, we know Super Apps offer a vast array of features.  However, what happens when the user only wants to: 

• Use a single feature of your Super App
• Use a feature rarely or just simply "some" of the time

As we consider the above points along with the four points we recapped, let us revisit the dreaded typical app uninstall scenarios:

• Users uninstall apps they don't use often enough
• Users uninstall resource intensive apps much more quickly
• Once an app is uninstalled, it's very unlikely to ever get re-installed

So what does this mean for your Super App mobile strategy?  Clearly it's not to expect users to install your huge app for a single feature and maybe get hooked on other features, or expect that users will keep a huge app around they don't use very often.  This obviously is not the desired mobile strategy.

However, we must address the issue that our Super App is huge and bringing on new users means there must be a way for users to try/use a single portion of our app.  This, in the hopes of bringing them fully onboard. 

This is where App Clips (Apple) / Instant Apps (Android) can help.

NOTE: for the remainder of this post, I'll refer to both simply as App clips - only because it's easier to type.

The case for App Clips:

What exactly is an app clip?  Essentially it's a small, focused feature set of your full app's functionality.  You'll hear it stated that they provide an "in-the-moment" experience and run instantly.

A little more context...

Your Super App many have N number of major features. Examples:

• Ride Sharing
• Food Delivery
• In-Store Payment
• Loans (Perhaps for customers needing help with transportation cost)
• Loans move you into banking
• You start to provide a crypto wallet and full exchange as more users start wanting to pay with crypto
• etc...

As these type of features expand within your Super App, that Super App's architecture may begin to look something like the very high level hypothetical software architecture diagram below:

Super App Architecture Sample

Again, this is a simplistic high level example for discussion purposes.

Here, we can see this fictional Super App's features that are offered to users.  These include:

• Ride-Share
• Food Delivery
• Credit cards
• etc...

Also, each of the features uses various internal libraries and services which provide critical functionality used by each feature.  ie: The Transportation loan and credit card features both rely on the "banking services" library.

Two points which become apparent are:

• This Super App is big and it would be a lot to expect a mobile user to download this whole app without first knowing if they even want to use it.  
• The features are not strictly isolated, but instead multiple features use overlapping services (This point will be properly addressed in part 2 of this post)

To address the first point, App Clips give you the opportunity to provide a "sampling."  An opportunity for a user to painlessly use specific features of your app with minimal impact.

We'll dive into this more, but before we do, let's take a look at why this matters for user beyond simply concerns of large app binaries.

Super Apps User behavior:

As we look at all these features contained within a Super App, we begin to understand that it's likely some users are only going to want a single, or just a few of these features, and likely only some of the time.

For instance, your Super App users may only want to use your ride-share feature(s), and each has a different user case for even that specific feature.  For example, variation of use cases for ride-sharing:

• Only on the weekends
• When on occasional travel
• Get rides to and from the airport
• Get multiple rides per day Monday - Friday
• Used as their sole mode of daily transportation

However, if all these groups have absolutely no interests at all in your crypto exchange, food delivery, or banking services...  Well, you could find your costly Super App investment getting called into question as a single purpose ride-share focused app could take away all the above customers, regardless of their use case.

This brings us full-circle back to the choice - Super App vs Single focused app.

And why would a mobile user prefer a single app over a Super App? 

Single focused apps:

• Don't take as many resources on the device
• Download and install faster
• Offer the focused use case at the instant the user needs it
• Use less personal data

And why would a mobile user prefer a Super App over a singularly focused app? The Super App provides:

• All the needed services in a single ecosystem
• More access to multiple businesses due to larger influence
• Additional resources to help. ie: In app loans to help pay for transportation
• Provides a hyper personalized experience based on the data the user provides

So, what's the primary point between the two above options for users? 

• Resource tolerances
• An app often used has a high user tolerance

• Feature accessibility 
• An app that offers a feature rich experiences has a high user tolerance 

The challenge we're starting to look at is perhaps one of the most critical in today's mobile environment: onboarding new users.

How do new users know the worth of your Super App's feature set enough so they install it, then for you to begin to understand your user's tolerance levels of your app's size and feature set?

A bit of a chicken and egg problem...

Super Apps especially need a gentle way to bring new users into the Super Apps ecosystem - to provide that single, small, and fast experience when needed.  

We can provide a good portion of that experience and onboarding first step reassurance via an App Clip.

App Clips:

What an App Clip gives you is the opportunity for you to provide a singularly focused feature, much like a single purpose app, for your user's to use when they want or need it.  This, without the massive download or commitment to the whole app's installation.

Often times technical leaders, when they first hear this, they start to think - "Awesome, we'll make EVERY feature an App Clip!"

They may envision this:

However, reality can quickly become something more like this:

As usual, the two major players are taking different approaches to help alleviate this potential "everything App Clip" pitfall.

• Apple will only allow a single App Clip per app, with an App Clip able to have multiple experiences
• Google allows multiple Instant Apps via separate stand-alone modules which constitute entry points. (Remember, the stand-alone part.  It will become very important in part 2 when we discuss architecture and the pile of puzzle pieces.)

NOTE:  App Clips have experiences and Instant Apps have entry points.  Essentially, these are the equivalent of "exposed functionality."

So again, thoughts may jump to "well, we'll just have 50 experiences/entry points in our App Clip - problem solved!  Again, not exactly...

There are some primary purposes around App Clips' use cases which, by design means you'll want to very carefully evaluate this thinking.

Primarily, App Clips should:

• Download & run "instantly"
• Provide a single focused experience
• Allow users to quickly use the App Clip's functionality
• The experience can start and end quickly.  ie: Find the nearest steak house with a 5 star rating.  Or, order a ride share or food delivery
• You can offer to have the user download the entire app once the user finishes with the App Clip

One point here, you'll notice in the first bullet point above, I did not use the term "install."  While in the background, yes, there is something installed onto the user's device - from a user's perspective of installing an app downloaded from the app store isn't the case with App Clips.

From the user's perspective - the user taps a URL or scans a QR, or QR like code and are prompted to run the app clip.  Once they agree, that app clip is running instantly.  No middle man, no observable download or delay - it's an Instant App experience!

Now that we have a high level understanding that App Clips give us an opportunity to expose some focused features of our mobile apps - we will leverage that understanding in part 2 of this post to fully understand how to properly leverage App Clips.

Conclusion:

We have covered quite a bit about the risks regarding user's tolerance to install and keep a Super App installed.  

As we looked at possible solutions to these issues, we saw that, while it isn't quit "App Clips to the rescue!" we can see that "App Clips can help" in breaking down some of the major onboarding barriers mobile apps face today.

While it is tempting to look at App Clips and think to make every component of your app, App Clip ready - it doesn't quite work this way.

And with that, in the second part of the post, we will be diving into more of the technical nuances of App Clips.  We will dive into details which will give business leaders the technical knowledge they need to optimize their Super Apps to properly leverage App Clips for success. 

Read More

Mobile Dev Strategy: Architecture Trends (Super Apps)

 Your Mobile Strategy and Super Apps

At this point, we've covered the development aspects and the organizational considerations which go into evaluating what mobile development strategy is likely to best fit your organization's needs and why.

In this post, we'll move away from development strategies and look at mobile app architecture.

This is the first of a two part series where we're going to take a look at some of the mobile app trends we're seeing in the industry today.  Primarily, in this first part we'll talk about 3 points:

• Current Mobile Apps

•  Super Apps
• Partnerships

• App adoption

Current Mobile Apps:

There has been, and continues to be the design philosophy that a mobile app should "Do one thing, and do it well!"  Admittedly, this is a very wise mobile app philosophy.

Typically, mobile apps have been purpose focused. ie: It solves a particular problem, or very specific and focused related problem set - email, health & fitness, password protection, etc...

Also, mobile apps must always be extremely aware of their performance and resource management.  This is enforced with some very tight consumer acceptance constraints which app developers must always be aware of.  Simply put, the mobile app needs to download fast and take up as little room on the device as the user is going to accept.

That last point just means: the more useful the app is for the user - the higher the tolerance the user has for it taking up resources.

There's nothing too new or Earth shattering about the information above.  However, it will tie directly into our discussion about an emerging, and what's sometimes considered an absolute contradicting mobile app architecture regarding what constitutes a mobile app user's will adopt.  

Let's first take a look at what a mobile app's capabilities should be.  The figure below lays out an outline for this:

While there are always exceptions, almost all mobile apps should be following these general guidelines on some level.  This is regardless if it's a focused single purpose mobile app or a Super App.

Super Apps:

And so we come to the Super App!  A typically huge mobile app that is almost anything but singularly focused.

OK, so if both a Super App and a single purpose mobile app should follow these exact same rules, what's the difference between the two?  What exactly is a "Super App?"

First, both type of mobile apps must try to be good stewards of the user's device and data resources.

Second, while there's no one specific definition, essentially a Super App is a single mobile app which offers a multitude of services to its users.  One point which as emerged within the Super App eco system is that all the services aren't necessarily "directly" related, but instead tend to fall under a very wide umbrella of functionality.

Let's give a simple example to use as a springboard into the rest of our conversation.

Imagine PayPal integrated all the following services (some of which they already offer):

• Credit cards

• Provide Loan through their app

• InStore payment - rather than piggybacking off Apple or Google pay - they took on the giants to offer their own pay

• Now imagine they bring in their own ride-share and give credit for using their drivers

• Add in travel and payment all in one fell-swoop

• Add in some massive spending behavior of their demographics spending to give restaurant reviews based on return purchases

• Throw in reservations accompanied with a financial deposit to ensure your table will be available

• etc...

You start to get the idea. Within this partially fictitious example, as PayPal does offer some of these services already, but taken as a whole, you start to see how a provider of a single service could expand.

Essentially, we're seeing organizations leverage the capabilities of an initial dataset to expand in unique ways - ie: Super Apps...

Depending on where you're reading this from may determine your level of familiarity with Super Apps. Why?

Because Super Apps such as China's WeChat or Alipay, India's PayTm or TataNeu, Singapores's Grab App (Which has the slogan: The Everyday Everything App),  or Indonesia's Gojek are some of the biggest Super Apps in Asia.  However, you don't hear near as much about Super Apps in either the EU or US markets.

Speculation as to why this is the case - a couple of reasons:

• More saturation from a large tech competitive market

• Stricter data regulations

Competitive Market:

Regarding the competitive market - is this to say countries such as China don't have a competitive mobile market?  Absolutely not!  To the contrary as a matter-of-fact.

What this is to say is that in markets such as China, there are restrictions on large global organizations' toolsets.  This includes large tech such as Google, Twitter, Facebook, etc...

This is important because as those large companies aren't able to penetrate the geo-political boundaries,  it leaves open internal markets.  Here, players like WeChat can more easily become the prominent chat app and expand from there into a Super App.

However, with Apple, Google, Facebook, and others providing a massive offering to their customers - seeing a single one of these players, or a new player becoming the prominent consumer option over all the others, in a much tighter environment - isn't likely.  At least it hasn't happened yet.

Additionally, Indonesia is another country with a huge Super App success story - Gojek / GoTo.  This started out as a ride share app and has exploded into food delivery, payment methods, banking, and is moving into health care. 

One of the methods they used to penetrate the ride share market was to provide loans to their drivers who couldn't afford a phone.  I'll give you two guesses who drivers wanted to work for...  

Of course, this gave them the leverage to not only have loyal drivers for ride sharing, but that same base was now delivering food, medicine, etc.  Thus, Gojek "knew their market" and this gave them a huge advantage to expand.  Would this have given them the same advantages in the US or EU markets?  Maybe - maybe not.

Regardless, Gojek is the prominent Super App in Indonesia and is contributing significantly to the country's GDP - it's huge! 

Regulations:

Regarding strict regulations - this isn't about Super App regulations where the US or EU don't allow Super Apps.  No, this is referring to personal data regulations.

Why should this matter more for a Super App than any other mobile app?  Simply put, Super Apps typically have an enormous reliance on user data - and a lot of it!

Of course this isn't to say the countries where Super Apps are currently popular don't have regulations on personal data.  Of course they do.  However, many of the countries where Super Apps are exploding may have data regulations that allow a bit fewer restrictions which lead to company's moving quickly with the development of their Super Apps and collecting user data to feed that Super App.

The Super Apps:

All this being said - Super Apps are coming to the US and EU markets.  Uber is likely the closest we have right now, but others such as Spotify, with its move from music to including podcast makes Spotify a real potential Super App as well.  

Of course, Google with all its services and data - I could easily see that Super App succeeding in the US and EU markets.

Again, Super Apps normally moving from a single service with a large user base  to building in additional services - I think it's safe to say Google and Uber both fall into this category.

The good and the bad:

As with all things - Super Apps have both unique advantages and disadvantages.  The level of impact each carries is going to be dependent on your organization's business and mobile strategy and your customer base.

Here are some of the advantages and disadvantages to consider when determining how a Super App may or may not serve your organization's mobile strategy:

Some Advantages:

• Users don't need to swipe through multiple apps to get what they need

• Users don't leave your ecosystem so readily

• Business partnership opportunities potentially explode!
• ie: Companies coming to you to have their services integrated into an app almost everyone is using

• User onboarding for new features & services becomes almost trivial with virtually no additional advertising or cost since you already have the user in your ecosystem

Some Disadvantages:

• Large amounts of user data in one place

• Become a huge target for attackers

• Enormous code bases

• May need several teams - each with different sets of expertise to make certain each feature provides the appropriate functionality, security, and user experience. 

• Users may only want to use a very small portion of your larger app and not have the tolerance of your Super App's large mobile resource consumption

A word of caution: Avoid the trap of going out and finding a bunch of 3rd party SDKs which provide services you want in your super app and throwing them all in like pieces of a puzzle.  This is a recipe for disaster!  Again, just a word of caution. 

Conclusion:

In closing out this first part of our discussion about today's trending mobile architectures, I want to elaborate a bit on each of the final points from the two lists above.

From the first list about onboarding - when diving into your mobile strategy, you will need to take into account just how incredibly difficult app adoption is today.  

The mobile app market is extremely, if not outright overly saturated with an average user app download per-month hovering around zero.  So, if you already have a user-base using your app,  making it into something like a Super App may server you well. 

However, for users not wanting all 5,000+ features of your Super App - this too is a real problem.  Though you may get some users because they want one of your services - you may hook them onto more of your services.  But if not - they will uninstall your huge app when someone else provides that one service in a single purpose app.

Like all things in business, there's a balancing act.  

So what's the balance between so Super App or Single focused?  Obviously it's different for every organization.  However, there is something that can help...

In the second part of this discussion, we'll address that point in a discussion around App Clips and Instant Apps.  

Read More

Mobile Dev Strategy: Wearable Development & Strategy

Wearable App. Development and Design Strategies

Continuing our mobile development strategies section of this blog, I'd like to move into wearables.  

However, in this post, we'll only initially address wearables development.  We'll keep it brief for two reasons:

• Wearables today are pretty much developed natively on Apple and cross-platform frameworks have various levels of support for Android WearOS

 

• As the first point demonstrates, we've already covered most of the technologies involved in wearables development 

Once we've covered the necessary development issues - we will then discuss the following areas of wearables: 

• Functionality Design

• Usability 

• Future considerations

Though there is a lot more to wearables today than simply watches, since most of today's discussions revolve around watches, I'll start there.

Wearable Development Decisions:

When addressing wearable/watch development, it is important to revisit our previous cross-platform discussion.  

The impact that decision can have on your wearable development could be significant.  At the time of this writing - the support of cross-platform frameworks for wearable development is inconsistent across frameworks.

There are add-on plugins to help with wearable development that are available for some of the frameworks which have less built in support, and these plugins have had some success.  However, as your wearable demands expand, it's likely you'll get mixed levels of success as the development community for these wearable assistant plugins is somewhat disjointed.

The need for these plugins is that in order to develop an Apple Watch application, that development effort is completely reliant on the Apple development ecosystems.  Essentially, what this means is:

• Using a cross-platform framework for an Apple Watch app - you will have a separate baseline for that watch app.  

• But your Android WearOS can easily be integrated in frameworks such as Flutter, but there are other cross-platform frameworks that don't have the support Flutter has for Android WearOS

• Because of these differences, some developers have developed various plugins to help with this difference between wearable platforms. Regardless of which plugin you use, you will remain reliant on a Native Apple development baseline for Apple wearables for the foreseeable future.

To provide a direct quote from Flutter's official documentation (https://docs.flutter.dev/development/platform-integration/apple-watch): "While you cannot build an Apple Watch app with Flutter, it is possible to add a native Apple Watch extension to a Flutter app."

This means, if you're using platforms such as Flutter, you can still have an Apple Watch app and build your iOS app using Flutter, but you will have a separate baseline for Apple's wearable development.

You will notice that I have mentioned Flutter by name in several statements above.  This is because it is new and had wearables in mind when it was developed, other older cross-platform frameworks are not as good at supporting wearables - including Android WearOS.

For wearable development - keep in mind that there are other up-and-coming wearables hitting the market.  These include:  

• AR glasses coming from Apple and Google
• Various levels of smart Glasses from other companies.

• Smart jewelry

• Smart Shoes

• Contact lenses

• Medical Wearables

If wearables are on your radar, and hopefully they are or soon will be, know that developing for many of the above devices - certainly for Apple's Glasses - will likely be native.  Some may require an SDK integration which may or may-not support the cross-platform framework your team is using.

The point is, as new devices come into the market, if you choose a cross-platform approach, you may find yourself frustrated meeting a rapid deployment schedule if you already have a mature cross-platform baseline.  

Again, Flutter being a Google project you'll probably be just fine on the Android platform, but be aware of other cross-platform frameworks and know that as new wearables devices come to market, this very well may  pose unique challenges for you.

Wearable UI/UX & Functional design:

As we now move our discussion away from wearables development, let's take a step back and consider the fast paced change wearables are proving to have.

Previously, we often times looked at the wearable app as a "smaller" version of the phone app with a smaller display.  Of course, the smaller screen is still true, but engaging with wearables today is not the same as even a few years ago!

Once upon a time, there may have been ten screens to swipe though in a wearable app, but there's very little good that comes with this design thinking on wearables today.  There may be 10 screens, but 8 of them should be completely optional with only 1 or 2 being primary - and those 1 or 2 screens need to do a Lot & Do it Easily & Do it Fast!

A few years ago, the simple wearable mentality was somewhat differentiated by the user's duration of interactions:

• Watch - (Seconds)

• Phone - (Minutes)

• Laptop - (Hours)

However, there is so much more to wearables today. Wearables can not simply be thought of as the bare minimum capabilities with a bare minimum UI.  Instead, their expected interactions are to provide an easier, quick engagement with minimal user interaction but provide enormous usability and engagement from each interaction.   

Done properly with considerable design and thought, well beyond a mobile app's little companion or simple extension, and wearables can prove to be a significantly beneficial component of your modern mobile strategy.

Wearables aren't simple extensions of your mobile app - they're the expansion of your modern mobile strategy.  

Wearables strategy:

• UI: Big and fewer UI components for interactions (Still, only seconds of interactions with your App UI)

• UI/UX: Voice commands and single swipes for minimal interactions but maximum task performance. 

• A single swipe should accomplish a ton! For example:
• Single swipe might confirm your reservations, schedule a ride share, and sends SMS messages to those waiting.

• Single tap starts your workout, music player, timer, and turns on do-not-disturb and monitors pace

So today, big gestures and voice instead of a bunch of little buttons and a lot of watch screens.

When considering wearables - instead of trying to think how a user would want your wearable solution after using your phone app - today, with watches being more often on the user, remember that the watch can drive engagement to your app. It isn't always the other way around these days. 

Wrapping up this section; some good considerations for your wearable strategy are that they should be:

• Pin-Point & customizable monitoring devices which provide long term data usability satisfying the user's wants

• Strategically engaging

• Consider wearables as a long duration device with minimal user interaction - it's not seconds, it's continuous

We have discussed both wearable development considerations from a cross-platform perspective as well as some of today's wearable design and usability considerations.  

Taking these into consideration today, will strongly position your organization for the next generation of wearables already hitting the market.

Future Expansion of our "Wearables" definition:

As with most new technologies - they tend to see prominence in a particular market and small wearables are no different.  As the sports and health industry has been a primary talking point when it comes to:

• BlueTooth devices in shoes

• Beacons used to monitor athlete's movements

• Pace and calorie monitoring for fitness

However, now as we look at these wearables coming into our day-to-day lives, we are seeing these devices allowing interactions with our existing devices and our environment in completely new ways.

Interfacing with our devices is becoming:

• A tap on our watch makes a phone call regardless if our phone is with us, or even turned on or not

• Scrolling on a smart ring brings up a menu we can scroll through

• Glasses or contacts as our AR and digital screens   

• Displays and sensors built into our clothing's fabric

• And connected homes monitoring and securing many aspects of our lives 

While granted, some of these devices are a few years off, some of them are already here.   

Also, as connected cities, 5G, fog and edge computing, and IoT in general become more the norm, our constant connection and interaction with our digital environment will drive a fast pace of wearable innovations and ways to interact with them.

User interaction with our wearables is just one example of a pathway for new business opportunities to emerge.  

For example - walking around with AR glasses, which look as normal as any today, constantly brining your hands up to your head 10,000 times a day to tap for an interaction, isn't practical - it's annoying.  

Here is where embedded sensors in our clothing or smart rings can come into play.  A thumb swipe to scroll through your displays becomes very practical.

So why all this "future" talk?  

For 2 reasons:

• As these devices come to market - you're likely going to want to develop mobile solutions with them

• If Apple and/or Google releases solid AR Glasses and a Smart ring that fully integrate with your phone, watch, house, etc...   
• It's going to take about 5 minutes before everyone is jumping at being the next Apple or Google walking technology node wearing every single one of their devices.

However, before the major players release all these devices - this ecosystem is likely going to be quite wide ranging for some time to come. 

Thus, if this integration is on your mind, just realize that it will become increasingly unlikely you'll be able to maintain a single baseline of code to develop against a wider range of wearables. 

Conclusion:

Regardless how wearables look over the next decade, one thing is for certain - they're here and their market penetration is happening fast!  So much so, that Apple's first quarter earnings for 2021 & 2022 had wearables and home accessories outpacing the iPad. (Ref. Apple's Q2 financial statement: https://www.apple.com/newsroom/pdfs/FY22_Q2_Consolidated_Financial_Statements.pdf)

Read More