Mobile Dev Strategy: Hybrid

As we continue our mobile development strategy section of this blog - this third part of our development section will address hybrid mobile development.  This is a mobile development approach often used synonymously or confused with our previously discussed mobile development approach - cross platform mobile development.  

There is often times a lot of confusion, contradictions, and disagreements what exactly this methodology of mobile development truly is.  And, as has been the case so far - most of these differing points-of-view regarding hybrid mobile development are correct on some level.

Mobile App Running Environment:

In this post, I'd like to start off with a high level diagram outlining a mobile app's running environment.  This isn't specific to any particular platform, but does give us a good baseline to have a much more clearly stated definition regarding "what exactly is hybrid mobile app development?"

For this conversation, this high-level diagram's purpose is simply to provide understanding and talking points:

To begin our dive into understanding hybrid mobile app development, the first point I'd like to bring up are the produced deliverables each development option ultimately produces.

• Native Mobile Development: "binary/executable" mobile app
• Discussed in next post

• Cross-platform Development: "binary/executable" mobile app

• Hybrid Development: "binary/executable" mobile app

NOTE: With mobile delivery, there's more than just a single executable "app."  The specifics aren't important here, but one of your engineers may bring up the point.

Notice in the listed points, there's absolutely no mention of the PWA's deployable deliverable.

PWA Divergence:

Above I mention that three of today's mobile development options produce an actual mobile "app" which can ultimately be deployed via the Apple/Google store.  However, as stated, I did not mention the PWA.  This is because with a PWA:

• You do not compile HTML & JavaScript into an app

• The PWA runs within the browser

• There is no app to deploy to the mobile provider's store
• FYI: There are some up-and-coming PWA stores, but at this time, they're more similar to the Chrome Extensions store and not the Apple or Google store we're mostly talking about for mobile apps.  The PWA stores are hyper cool, just not what we're talking about in this post.

A slight side note looking at the image above.  Since the PWA runs in the browser and the browser is an app - your PWA runs within the Browser's sandbox and the browser is an app pretty much like any other.  In the image, let's say "App B" is a browser app - in this case App B was downloaded from the store and your PWA would run inside App B's sandbox along with all the other PWAs.

So, with the exception of a PWA - all other development methodologies for mobile are going to produce a binary mobile app.

Now that we have an understanding that an app and PWA have different deployment deliverables, if we think about the pairing between your PWA and the Browser app at a very high level:

• You have some web code running within a mobile app

PWA's Convergence:

 Sticking with the PWA just a bit more, if you remember from our discussion about PWAs, we mentioned that one of the most powerful capabilities of PWAs today is access to the device's hardware and that they can persist data offline.   However, we also clarified that the reality was that the PWA really wound up asking the browser to access the hardware and provide that data from the HW back to the PWA.  Thus, a PWA does not actually have access to the O/S level resources because it's not an app.  HTML & JavaScript are not compiled - they're interpreted by the browser.

NOTE: Regarding that last part, though technically developing a cross-platform solution using React-Native for example, you're technically writing HTML and JS.  However, this code is eventually compiled into an actual mobile app using the React-Native framework.  This technically is not considered HTML & JS developed for the web which just runs as a mobile app.  Instead, this is code written using HTML & JS is translated by the React-Native framework into code which is compiled into an actual binary mobile app for deployment via the app store(s). 

Hybrid's Marriage of PWA and App:

 

OK - if we once more take a quick peek back at our diagram, we can see that our apps can in fact access the HW on the device directly using the O/S layer services.  This is unlike our PWA which must go through the browser.  So, if we want to write our HTML & JS to have its own sandbox and have the power and access that a full fledged app can provide, we'll be looking at a hybrid mobile development solution.

Essentially we have a web page (UI) interacting with our app code which can access the HW and device's services just as any other app on the device.  Below is a high level look at a hybrid mobile app's architecture. 

The overview is this:

• Your mobile app UI is the code you used to develop your web UI

• The hybrid-app will use virtually identical HTML & CSS
• NOTE: It is highly likely the JS you used for your site will be different using it in a hybrid environment.  

• Your HTML & JS interacts/services/calls into the underlying mobile code within your app.  
• ie: Read and writes to a local DB contained within your mobile app's sandbox can be initiated from your HTML & JS

• Essentially, you have full access to the O/S services from your HTML via the code which is used to develop the underlying mobile functionality.

This all sounds great - and it can be.  There are some critical points to be aware of however.  These include:

• As with cross-platform solutions, your hybrid code as a single web code base  can still get jammed up with special cased code

• You could - depending on how you organize your team, actually wind up with three or four separate development teams potentially getting out of sync.  This can become a rather complex issue when deployments come up (of course this could be a DevOps issue for your team.  It really just depends).  But you could essentially wind up with the following (all of which have different pressing issues - not necessarily all sync'd):
• Web Dev Team
• Mobile Android
• Mobile iOS 

• You don't really fully leverage the native UI capabilities of the platform and the user experience can be lacking along with the performance of the UI 

• You're likely to get tripped up when it comes to AR and VR solutions trying to use a hybrid solution

Technical Caution When developing Hybrid Apps:

One point I want to expand on a bit involves the technical experience of a mobile team.  It is critical that you as a technical leader understands that mobile is far more than just UI.  Some of the most concerning statements I've heard from technical leader are statements such as: "everything will be great - we already have web developers" or "Let's take our web code and just make it into an app and deploy it." 

There is so much more to mobile, and when you're putting together your mobile team, you need to be certain the developers understand how deep the mobile development environment is.  The ability to develop for the web does not translate to automatically being able to develop on mobile regardless of the framework being used.

Points such as truly understanding how the O/S handles background processes and permissions, DB generations, waking up an app when it's not in use, deep linking, app clips, or fully understanding the lifecycle of components - all differ significantly on each platform.  There are more points than I can bring up in this blog, but you need to be sure your development team is approaching mobile as mobile - not simply web as a mobile app.

This is not a hit on web development.  There are plenty of web developers who can develop fantastic mobile apps.  All I'm saying here is - you as a business leader need to be certain your team fundamentally understands mobile and don't assume, just because someone developed a PWA that they'll automatically be able to take their expertise to mobile.

Hybrid meets Cross-Platform:

 There is a point which I'd like to iterate on just to blur the  distinction between hybrid and cross-platform mobile development a little bit.

We have seen that our hybrid solution is essentially web sitting on top of native code which makes up the entire mobile app.  However, if you remember from earlier, we stated that regardless if you develop using either native development (Swift/Kotlin), hybrid, or one of the cross-platform frameworks, you windup with a mobile application.  So, what's the term for the solution which uses a cross-platform framework to develop the app's underlying functionality and have the web UI component for hybrid?  

Maybe that's "cross-hybrid"  

I like it!  Let's see if it catches on...

Conclusion:

In closing, I'd like to address the question around - "is hybrid the right choice?" Or "Is hybrid a better choice than straight cross-platform or native mobile development?"   The answer as with all things - maybe, maybe not.  It will always boil down to you as a business leader understanding the different development options and if the choice you make fits your organization's mobile needs.

If the answer you come to is "yes" - and you use the knowledge you may have gained from this blog as well as listening to and understanding your engineers - I think whichever choice you make will likely be the right one.

In our next posting we'll take a look at native mobile development.  Until then, would love to hear about your successes or less than stellar outcomes you and your team(s) may have had with hybrid mobile development...