Mobile Dev Strategy: Cross-Platform Part 2

 

In the first part of this two part series, we outlined the cross-platform differences between the commonly understood single app running on a JVM and mobile frameworks producing multiple mobile apps.  Additionally, we covered mobile cross-platform development frameworks and how they differ from a single cross-platform language.

In this post, we'll take that knowledge and dive into various technical details.  This is aimed to help business leaders make solid mobile cross-platform development investment decisions.

The "basic" statement and why they're harmful

The most often stated advantages ill informed business leaders tend to make when discussing the advantages of developing mobile cross-platform solutions are:

• Fast/First to market on multiple platforms

• We only need to maintain a single code base

On its surface, these statements sound great!  However, this thinking by itself without fundamentally understanding what's happening underneath is likely going to lead an organization down a very painful, buggy,  slow to deliver, and expensive mobile path over the long run.

A few of the issues with this overly simplistic thought process are:

• It doesn't take into account the growth of the platform

• Potential 3rd Party integrations

• The lack of evaluating the overall mobile capabilities the organization is looking to leverage

• How customized or standardized is the UI/UX per platform

• What's the impact on the technical team

Let's dive into each of these points.

Platform's Growth & Speed to Market:

To begin, let's explore potential issues regarding the growth of the organization's mobile solution.  

As any software expands its capabilities over time, the list of bugs and their complexities expand.  Additionally, supporting multiple platforms, your team will wind up with different issues on different platforms.  Of course, these are by no means isolated to cross-platform solutions.  However, with these type of issues, what very much does have an increased impact due to the cross-platform's nature is:

• Your single code base will wind up with special cased code to address bugs which are platform specific

• This special casing is likely to grow over time, potentially making your single code base much more difficult to maintain

• Thus, fast initial delivery to market, could mean future upgrades delivery to market slows due to complex platform specific issues and special case pollution too intermingled within a single baseline 

• Your release cycles for various platforms can get badly out of sync

• Scheduled features/offerings on multiple platforms could be delayed because of a single platform

• If too much specialized code is introduced over time, your baseline is going to become extremely fragile.  Meaning, if it were a car and you adjust the A/C and the back left tire falls off.

• Perhaps worst of all - while continuing to develop in the cross-platform framework, your baselines diverge between platforms. (Believe it or not, I have seen this happen)

While this all may sound horrible - a well informed decision process and a vigilant awareness of these issues under a good business and technical leader combination can easily leverage a mobile cross-platform solution with tremendous success.

While much of the above can be mitigated with solid leadership and technical oversight, there are also some technical specifics about your mobile's growth that will prove more challenging for a mobile cross-platform solution.

Platform's Growth & Integrations

As the world turns its attention to the MetaVerse and Web3, there are new areas of mobile coming into play as well as increased expectations from current mobile technologies.  Areas which include: 

• Wearables becoming more prevalent and diverse

• 3rd party integration support

• IoT - Fog - Edge computing
• Connected Home is probably what most home owners are familiar with - but this is just a small example

• Performance increase and capabilities offerings from Mobile Manufactures
• This will vary amongst the mobile O/Ss as well as various devices

Wearables:

Currently, wearable development is provided by today's mobile cross-platform frameworks via a "work-around" solution.  Without diving into too many details, the gist is, developers have to go to the native environment to properly develop the watch portion of the mobile app.  The frameworks provide some internal linking for deployments, but essentially the wearables today are not an intimate part of the cross-platform baseline and will be developed using the mobile O/S specific language and environment.  Thus, your single baseline won't be so singular.

NOTE:  Frameworks like Flutter do support Android wearables without any issues, but for iOS, you'll have this workaround development flow even with Flutter.  How much this support expands with the expansion of coming wearables remains to be seen.

Many organizations may not be looking at wearables (mostly watches today) but with their presence and sales outpacing tablets in some areas, this is likely going to prove to be a costly mobile mistake.  While watches are wearables today, there are glasses coming out from Apple and Google and Meta and it's only a short period of time before they take off and the development environment for them is most likely going to be highly specialized.

So regardless - if wearables are going to play a significant part in your organization's immediate mobile future, you will certainly want to take this into account.

3rd party:

 

With an ever increasingly complex mobile ecosystem, it is likely one or both of the following will impact your mobile solution at some point:

• Your team is going to need/want to integrate a capability provided by a 3rd party SDK

• You have developed a capability that other mobile developers want to integrate into their mobile solutions

Two things you'll likely need to consider here:

1. If your team needs to integrate a 3rd party library - how likely is it that it supports your team's cross-platform framework?  Know that if it does not natively, you're likely going to either have some serious work arounds and/or the stability of your solution may be compromised.
2. If you're going to deliver mobile capability which was developed using a specific cross-platform framework:
• Are you going to rewrite it to support native mobile
• Or are you going to only deliver it from your chosen development framework?
• Or supply perhaps a non-standard integration pattern for your customer's integrations?

One point to be particularly aware of:  Identifying the need to integrate a 3rd party library after you have a mature code base is the most likely scenario.  Thus, it is something which is extremely difficult to always identify before development begins and your baseline grows.  Therefore, if you are using a cross-platform framework, look at its popularity, as that will increase the likelihood of finding 3rd party integrations that are fully supported and cleanly integrate and work for you.

IoT / Fog / Edge computing (5G): 

Often times today when we talk about 3rd party integrations, we normally refer to APIs (REST/GraphQL) back to a cloud hosted environment.  However, as we start to look at smaller sensors integrated into our connected homes, it's likely they are going to rely on our phones to act as a hub allowing the phone to work as the 5G node, but platform specific comms between the phone and sensor could be entirely proprietary.   

Here's where the integration with these sensors is going to become more common place and not every small device is going to have a small web server installed.  Furthermore,  many of these devices are going to use encryption and need to have a significant guard against DoS and other attacks.  Here is where it's likely many of these sensors will supply SDKs over APIs.  So, keep in mind as we progress in today's world, sensor integration in your mobile solution is more likely, and SDK integration is likely to increase as well. 

One point of note here: While MQTT and Matter are great projects for IoT protocols and are going to significantly lighten the load for home and other IoT integrations.  But keep in mind, as sensors increase, proprietary solutions will grow as will integration complexities.  So, it's likely the sensor manufactures will supply SDKs instead of passing off to the 3rd party developers to dive into the HW specs as well. 

Again, look at the growth of your mobile solution and how well your cross-platform framework of choice is going to support it.

New mobile O/S Features and Upgrades

One important point to bring up when evaluating whether or not to pursue your mobile solution via a cross-platform framework is your organization's need to have the latest cutting edge release of up and coming mobile capabilities the moment they're released from WWDC and/or GoogleI/O.  

For example, if your mobile solution is a high end photo app - having all the latest camera features on each platform the moment they're available as well as be able to integrate those most recent camera features and additions with high reliability... then pay close attention as any bugs the mobile cross-platform framework you've chosen has with the latest camera updates - well those just became your bugs too.  Camera here is an example, as the cross-platform frameworks support it just fine, but AR, VR, ML or other technologies, the very latest may not be fully up, or may have strange little bugs at first.

Pay particular attention if your solution requires the following:

• Makes heavy use of very customized background functionality

• Performs high performance cycling of on device hardware (Accelerometers, gyroscope, etc)

• You have a segment on the device you need absolute control over and employ a very unique use case.

• You incorporate native code into your solution for highly configurable optimizations
• ie: Direct C/C++ or assembly

• You're working with custom hardware

Again, remember the mobile cross-platform is a middle man and may not optimize the way you need.  Basically, the more unique, constrained, or performant your mobile solution must be, the more likely you are to need a native solution.  

Remember, this is based on technical mobile needs - not business uniqueness.

Meaning, you may have a custom business solution which predicts the stock market 5 years out and you display this information to your users in charts and graphs.  Highly unique business - extremely standard mobile technical challenge.  Mobile cross-platform great choice here.  Actually, PWA would probably even suffice here. 

Specialized UI/UX:

This one is pretty straight forward, but do not discount it.  Essentially, is the UI/UX your team is providing generic and acceptable to the customers on the major mobile platforms?  Remember, Android users like Android UI/UX and iOS users like iOS UI/UX.

I will say, most graphics teams have this nailed down, but you as the business leader must make sure before jumping into mobile cross-platform just because it's fast to market on both platforms.

Your engineering team:

One last point - when looking at which mobile cross-platform framework to go with, you must consider its "popularity" as well as the likelihood it will remain popular for some time.  There's a few reasons whether it's community support and continuing development, but primarily for your organization's ability to retain and attract mobile talent.  

If you're using a framework nobody wants to work with - your talent will leave and you're not likely to find a lot of enthusiastic talent looking to hop onboard.  

Food for thought...

Conclusion:

To wrap up this mobile cross-platform discussion...

Making the this decision goes far beyond just "first to market" or "write it once and it just works."  Instead, it's an overall evaluation of what are the specifics your mobile solution is going to leverage over the long haul.

So, the question of PWA vs Mobile app is more one of the user experience, where the question between cross-platform vs native app is more of levels of device optimizations, service features integration timeframes, wearables, and background interactions.

Please know, cross-platform frameworks do all of this extremely well.  It's a matter of understanding that very fine edge of requirements which distinguish that line between mobile cross-platform and mobile native.  

For business leaders, hopefully this post gave you the knowledge you'll need to help you better engage with and understand with your engineers when discussing mobile decisions regarding mobile cross-platforms and being able to draw on your understanding to make the best choice for the organization's mobile solution.