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