Mobile Dev Strategy: Native Development

Welcome to the native mobile app development discussion of this blog.

Before proceeding, I would like to point out, now that you have a ton of knowledge about cross-platform and hybrid mobile development - in this post I will be committing a mobile sin and using the term "cross-platform" as an all inclusive term to include hybrid.  I accept all blasts for my decision. 

As we approach the native development paradigm, it is the one which usually has a lot of financial and business oriented questions revolving around the specific question - "what's the benefit?"  Though there's normally a more complete S.W.O.T analysis, the primary concerns normally revolve around cost.

Often times the initial concerns when an organization is deciding on the native mobile development effort normally revolves around 3 points (which stem from the cost concerns):

• The need for additional developer and infrastructure resources

• Maintaining multiple code bases

• Getting locked into a single platform eco-system

I'd like to address the three points above, then dive deeper into the technical considerations of native mobile app development.

First: yes, you'll most likely need to have an Android and iOS specific team(s).  There are many mobile developers who know both platforms, but tend to be more proficient with one over another.  Therefore, not only in the interest of development time, but also having the skillset to fully leverage the capabilities of a particular platform - you will save yourself time and money having separate, dedicated or cross-pollinated iOS and Android development teams.

The reasoning around the above will become clear as you continue reading.

Further elaborating on the first bullet point above - regarding the infrastructure resources, typically I hear this is in reference to "build server" or "development machines."  To be perfectly certain - no matter if you use Flutter, React-Native, Cordova, or Xamarin, you will only be able to build, test, and deploy an iOS mobile app from a Mac/Apple machine using the Xcode developer tools.  

Remember that the cross-platforms frameworks leverage these exact tools, they just kind'a hide or wrap them as they're an intermediary. 

Next: when talking about maintaining multiple code bases - yes, you'll have multiple code bases.  However, what I consider a more important issue is maintaining the same implementation logic within those various code bases without platform specific special casing.  This is a huge benefit I don't normally hear getting addressed and given its due attention.

Regarding multiple vs platform specific code bases - you will have a baseline for Kotlin and one for Swift.  What's important to consider here is to know that having a single codebase - fixing an issues for Android won't affect your iOS implementation in any way.  Therefore, the mobile platform specific special cased polluted code base isn't going to be an issue.

The important high-level take away is, you'll likely either support multiple platforms with a potentially risky single code base with expensive bug fixes, or two potentially more expensive initially, but more maintainable code bases.

Essentially, cross-platform solutions' deployments turn-around times tend to slow and bug fixes tend to become more expensive over time as the single codebase and features expand.  Again, this depends on how specialized your mobile solution is.  If your solution just used the camera for example, you won't have much issue.  but if your solution is highly performant and specialized - that's potentially a very different story.

Multiple Mobile Teams Warnings:  

There is one glaring issue which often gets overlooked when you have separate native mobile development teams - "the nuances!"

To use an example from NASA failure and loss of spacecraft.  There was a subtle issue regarding logical inconsistencies no one picked up on - not because of incompetence, but because of a highly complex and fast moving program.  

If you recall the Martian Orbiter that broke apart in the late 90's.  The reason for the failure was that the European Space Agency Team used the metric system for their portion of the software and the NASA Team used the imperial system.  Sounds simple, but in a hyper complex system - these are the little things that get missed by even the most skilled teams.

Why do I bring this up?  For three reasons:

• There was no way some "intermediary/cross-platform" component was going to be used for that project - for the guidance of this craft, only native code (ie: Assembly, maybe C/C++, probably some ADA - no Java)

• The requirements for this demanded multiple teams to work very closely on multiple baselines

• The talking vs communications between the teams was constant.  These were HIGHLY competent development teams that not only knew what they were doing - but loved what they were doing and strongly believed in it.  You don't just accidentally wind up on those kind of teams.

So what's the warning from the above specifically for native mobile?  If there is anything to be said about mobile developers is they love what they do and know what they're doing - and we LOVE to talk about it!  Mobile - mobile - mobile - mobile...

However, what is often surprising is how little an Android and iOS team will communicate.  They'll talk constantly - but communicate?  Well...

They have a passion for mobile and they are talking mobile constantly!  So where, or how could these implementation issues come up?

• First, because you'll find your Android and iOS teams talking engineering and architecture bigger picture and very small specifics will not be fully communicate

• Little things get missed and over time those nuances get more and more hidden away and become the building blocks as the complexity of the separate baselines mature.

• Often engineers will assume or consider something so obvious and move forward without even realizing the other platform may require a completely different work flow.

• This logical inconsistency normally happens because, after all these great talks, with a bunch of hyper excited mobile developers talking about what they love, the motivated teams are sprinting back to their desk to jump in and develop an awesome solution!

Now, if you're running an Agile show, you may be thinking - not without tickets they don't!  Yep, all the Jira tickets in the world don't fully avoid this - they mitigate it for sure - tickets don't eliminate the issue.  Why? - because the tickets state something high-level.  They state the "what" and perhaps the "why" - not the "how."  This is what you often see in tickets even when the engineers are the ones putting the tickets together, and let's face it, that's what tickets are supposed to be used for.

These implementation discrepancies will present themselves usually somewhere much deeper and further down the road.  Since it normally starts off as a subtle little thing, it gets built on top of and soon becomes a huge thing to fix/change, because changing that little thing has a cascading effect.

An example:  (and I'm hyper simplifying here) - the feature states:

• Store the user info in a local DB on the mobile device for later retrieval
• This eventually grows to need to offload the local DB on each mobile device to the cloud once a week
• Now your cloud/API developers go to develop the REST API for the mobile clients
• The cloud developers ask your mobile teams - "OK, so we'll have a single API endpoint for Age and Name and another for Address
• Next thing you know:
• Your iOS teams says WHOA!  I have to get the age and the name in the same call???
• And your Android teams says WHOA!  I have to have the Address call completely separately?

Again, I trivialize here, but is shows the little differences that occur.  No one failed to create the DB on the mobile device.  But for example, the DB behavior on each platform is different depending on the threading model and the table relationships and DB generations are different on each platform.  No one missed anything - they each developed to spec on their platform.  All the Jira, white-boarding, talking in the world isn't going to fix this without good technical leadership to guide the communications.

Specifically, due to mobile's nature of multiple platforms deploying near identical UX, this issue is far more prevalent on mobile and modern desktop app development over server-side and web development. 

It should be noted that this can also happen in a cross-platform environment, I just haven't seen it happen as much.

Finally:  Regarding the last of the 3 points from the beginning of the article - about getting locked into specific platforms.

If you've chosen to develop your mobile solution using a cross-platform framework, you are not going to automatically "just" pick up and be able to reliably support a new platform that comes on the market.  This I can promise you.  I understand the statement when I hear it, but you are still going to develop for your supported platforms even in a cross-platform environment.  So, if you're a business leader who has this as a point against native mobile development, you may want to reconsider.

Just know that you're locking yourself into the chosen platform(s) when you start development, regardless if you choose cross-platform or native mobile development.

Technical Considerations:

Now that we've covered some of the points regarding business impacts on team sizes, separate baselines, and financial considerations - let's move to some of the finer technical points that you'll want to consider when choosing to, or not to implement a native mobile solution.

I think there are two 800 pound gorillas in the room on this and they are - performance and timely feature access.  You're almost certain to hear the first as the primary point to use native development for your mobile solution, but this, often overlooked second point is almost just as important.

Yes, native development is what you use to give yourself the best potential for a highly optimized and performant mobile solution.  Three things to consider regarding performance:

1. Does your solution require that level of performance?
2. Are you certain that performance level is not attainable from a cross-platform framework?
3. Are the behaviors/requirements significantly different between the platforms that you'll need highly specialized code for one or both platforms to get the functionality and performance you want?

One additional comment about the native performance - if you find yourself needing that level of performance, it only becomes that much more critical that you have very knowledgeable platform specific mobile development teams in place.

Regarding the "timely feature access" point for considering native mobile development - here are some of the points to consider:

• The amount of leverage you need of a specific aspect of the mobile O/S's capabilities

• Does your solution require some of the latest features of the mobile platform(s) or needs the latest capabilities normally as soon as the new capabilities are released by the mobile providers themselves?

• Is your solution making full and extensive use of a specialized feature?  This may be on one one platform or be the development may be significantly different between the platforms in order to fully utilize the feature in your solution

• Are wearables a significant part of your mobile presence?

• Do you have a particularly unique experience on one platform over the other?

One critical point - and I only bring this up because I've head it come up in meetings, or in case anyone was wondering - it's a pretty bad idea to start to try and intermingle native code within your cross-platform solution's code.  This is not referring to special case, this is different and rarely good.

Other Considerations:

As  we begin to close out this discussion, I want to bring up a couple of point you don't often hear come up in business meetings regarding mobile investments and impacts.

Bandwidth Tolerance:

I want to visit your user's initial impressions and tolerance of your app having a prolonged presence on their device.  Know that app adoption is extremely difficult, so if you get your app on their phone - you want to keep it there!  

So, first impressions - the first impression the user has of your app is the download speed and how long it took to install followed, or perhaps preceded by, your app's update frequency and how well maintained it is.

These are hyper important considerations in 2022 as users' tolerance for these points have significantly decreased over the years.  Thus, your app had better download quick!  And it needs to have a sufficiently frequent update and bug fix cycle.  Further more, if your user only sporadically interacts with your app and your app takes up a bunch of disk-space, you can be pretty certain it will be deleted.

How does all this matter with regards to native vs cross-platform mobile development?  Because your cross-platform app binary will be larger than your native app.  How much larger depends on the cross-platform framework you use.  Some cross-platform frameworks produce surprisingly well sized app binaries, but they still won't be as small as a native app's binary.  The issue gets worse the larger your app becomes and if you already have a large binary, well...

Frequency Tolerance:

We mentioned above how important it is to most mobile users today that your app be well maintained.

As with all things - moderation is king.  Keep in mind that for most mobile users, frequent updates to your app are good - too many updates typically are not.

We again look at what this has to do with native vs cross-platform mobile development.  We need to keep in mind that when you use a cross-platform framework, their issues become your issues and when they update - it's usually a very good idea to do so.  This means it's likely you're going to need to release updates, not just on your release cycle, but the cross-platform's as well.

It should be noted that the cross-platform frameworks really don't update too often.  You usually see an uptick around WWDC and GoogleI/O - but it is a consideration you at least need to remember.

Intermediary Tolerance:

And finally, when you and your team are considering any other reason which will lean your decision towards native development are security considerations.  This is not to say cross-platform frameworks are insecure - not at all.  What it is saying is that you have a middle layer which may be doing things you don't necessarily know about or control.  

Not things like snooping your device or stealing data, but what you must understand is that the cross-platform framework creates the underlying native code - not your developers.  Thus, there is an intermediary layer from your developers writing Dart, HTML, C# that the framework uses to then generate the mobile binary.

Know that industry has done a great job verifying popular cross-platform frameworks and the current solutions out there are solid and extremely safe.  However, some government or other entities may feel differently.

Conclusion:

I always enjoy the tea decision making process when determining native vs cross-platform solutions.  I hope this post has helped give you the information to enjoy those conversations as well.

In our next post, we will begin our forward looking aspects of mobile starting with wearables and moving into different mobile app architectures which are impacting mobile in big ways in 2022.

 

Read More

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...

 

Read More

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.

Read More

Mobile Dev Strategy: Cross-Platform Part 1

To continue the mobile development strategy series of this blog - this will be a two part post which will address the mobile development strategy that is possibly the most divisive and often has the strongest of contradicting opinions and preferences:  

We're talking about mobile cross-platform development...

Mobile cross-platform in particular, mostly due to its strongly contested and very impassioned opinions both for and against it from engineering as well as business teams alike, tends to bring up some very difficult choices for business decision makers.

Leaders must optimize their investment in mobile development dollars - certainly in today's hyper mobile reliant technical landscape.  Today, due to the cost of mobile talent and mobile solutions ever increasing complexities - mobile cost are likely to take up a significantly larger portion of your organization's development budget than even just a few years ago.  So, is mobile cross-platform the money saver your organization needs?   Maybe.  Maybe not...

When faced with the mobile cross-platform decision challenge, who should leadership go to for help?  This gets quite tricky when equally qualified professionals offer up equally well qualified contradictions of each other.

However, before allowing frustrations to break you down into passing this critical business decision off to your engineers to determine the best business and financial route of the organization's mobile solution - I highly encourage you as a business leader/investor to continue reading...

Cross-Platform Overview:

There are two aspects which need to be looked at when fully discussing mobile cross-platform solutions:

• The first part we'll look at in this post is the overall details which make up a general cross-platform solution.  This is to offer the business leaders a foundational understanding

• The next point - which will be in part-2, is a look at the technical details used to evaluate a mobile cross-platform solution for business leaders to be able to decide how, when, and if to move forward with a mobile cross-platform solution. 

Let's first get a common, overall understanding of cross-platform development in general.  This will be important when evaluating cross-platform for your mobile strategy.

One point I'd like to throw out there early on, as many may be thinking this is an old topic already exhaustively evaluated.  

As we are globally progressing into a new era of IoT, fog computing, 5G and edge computing, Web3, the MetaVerse, increasing AR & VR performance demands, a hyper aggressive world of wearables, and decentralized security concerns - today's mobile cross-platform considerations for a business leader are not the same as that of 5 years ago.  That said, neither is the quality of the cross-platform offerings today - many of which are absolutely phenomenal today!

OK, back to our regularly scheduled program...

The cross-platform concept is nothing new (mobile or otherwise) and is a "promise" we in the industry have heard for decades.  Has the cross-platform promise come to fruition - including mobile?  I think the technical answer is "eh..."

First, the reason for "eh..." is because cross-platform today is still usually achieved via platform specific virtual machines - the one you've most likely heard of is the JVM (Java Virtual Machine) and since it's likely the most familiar, we'll use JAVA as our example cross-platform use case to come to common ground.

Essentially, the JVM is a piece of middle-ware software that knows how to take the JAVA byte-code, "turn it into" machine instructions, which can then be run on various and differing systems.

FYI:

• JAVA code (what your developers write) is compiled into JAVA byte code

• JAVA byte code is read by the JVM and converted/compiled into machine code
• Yes, there's a JRE factor in there, but it isn't really needed for this conversation

• "Machine code/instruction set" is what's run by the system
• We could go into O/S and HW specifics regarding this, but instead, we'll just refer to the system rather than diving into O/S and HW specifics.

Essentially know the JVMs allow us to seemingly write an application once and have it run on multiple machines running different systems.  Sounds like the differences between iOS and Android.  

So if the same principal applies, then mobile cross-platform development sounds great!  Write my mobile app once and using a single baseline, have it run exactly the same on every mobile platform.  Sign me up!!!!

What more is there to discuss?  Well, as it turns out - a lot!  ie: A two part blog...

So, does the need for a JVM intermediary to run a JAVA app qualify JAVA as fulfilling the cross-platform promise?  I'd say "eh..."

The issues:

The first issue to note - if you intend on running your JAVA app on a system which does not have a JVM,  JAVA's cross-platform'ness won't help you at all.  Granted, there is a way to compile JAVA natively but that kind'a defeats the cross-platform purpose and we won't go into this here. 

The point to take away here is that the JVM is what JAVA apps/byte-code run through.  However, know that the JVM itself is not at all developed using a cross-platform code base.  The JVM itself is a piece of software very much written for the native platform and has many code bases - and most likely a lot of "special-cased" code. 

ie: The Windows JVM code base is different (probably very much so) than the Linux or Mac or Chromebook JVM...

Special case:

 Since I will be using the term a lot when discussing mobile cross-platform development, and in keeping with this blog's theme as a blog for business leaders - I want to briefly describe the term "special case" regarding code.  Below is a simplified code snippet which might be used to print out the user's home directory.  However, getting the home directory is "special cased" depending on the O/S the user is running:

var UserHomeDirectory:string = ""

if(O/S == WINDOWS)

    UserHomeDirectory = "c:\\username\\"

else if(O/S == MAC)

    UserHomeDirectory = "/Users/username"

else if(O/S == Linux)

    UserHomeDirectory = "/username"

print(UserHomeDirectory)

OK, now with everyone on common ground, we now enter into mobile cross-platform environments.

What is mobile cross-platform:

From a business leader/decision maker's perspective,  when we talk about cross-platform for mobile, we're usually discussing frameworks and full development environments rather VMs for apps to run on.  

So:

• Don't think about a mobile cross-platform solution as a byte-code app running on an installed VM

• Instead picture a mobile cross-platform development environment which produces multiple natively executable mobile applications - one for each of the respective platforms

• These native apps are then pushed to the respective app store using that same development environment's tools - either via your DevOps Pipeline or a tech lead pushing that app(s) up to the store(s)

This may seem simply a conceptual point, but it's important and will make your life as a business leader easier to think of mobile cross-platform in these terms.

To sum this part up:

• JAVA cross-platform compiles to an intermediary language - byte code, which uses a platform specific intermediary app (the JVM) to run your JAVA solution on multiple platforms

• Mobile cross-platform is a native app built for multiple mobile platforms from within a single development environment/IDE

Why think in these terms?  Because each platform uses a different paradigm how each specifically compiles and runs apps on the respective mobile O/S.   These are details you as a business leader don't really need to worry about - your engineers do.  Further more, these specific technical details rarely, if ever, play a part in financial and business considerations.  

As a note, because I know some developers will freak if I don't mention this - yes, Android uses a JVM internally as its "native" apps are developed using JAVA/Kotlin - both of which get compiled to byte code.  Regardless, as a business leader this might be a nice to know, but it's an incidental detail and you shouldn't be worrying about.  This level of detail doesn't change the fact that a mobile cross-platform solution is about building, testing and deploying your mobiles apps, not worrying about system layer details how the app is loaded by the mobile O/S.

Now that we have the gist of what mobile cross-platform is, let's jump into some of the common terms you'll often hear when this topic comes up.

Mobile Cross-Platform environments:

As mentioned, JAVA is generally considered a cross-platform language, but when we discuss mobile cross-platform development, we refer to environments/frameworks/etc...

The reason for this is that mobile cross-platform takes place in a much larger ecosystem - more so than what a programming language in isolation could provide.  The frameworks provide a full spectrum of features specific to mobile development and other features needed specifically for development, deployment, and testing.

NOTE: There are technical reasons to refer to these environments as either an environment, framework, IDE, etc... For simplicity, I will simply refer to everything as a framework.   I look forward to the comments on that one.

The important take away for business leaders here is - mobile cross-platform frameworks are a layer of abstraction so your mobile developers can leverage a single language and development environment to produce native mobile apps on multiple platforms from a single'ish code base.  

Single'ish - remember that special case term from earlier?  This will be a very interesting component in the second part of this post

When you hear discussion around these frameworks, each framework implements a language of their choosing which may play a factor into which platform your organization chooses.  

Examples include:

• Xamarin (framework): C# (Language)
• Flutter (framework): Dart (Language)
• React Native (framework): HTML/CSS/JS (Language)
• Cordova (framework): HTML/CSS/JS (Language)

All of this will get tied together for further clarity in the second part of this post when we dive into various mobile cross-platform technical details and the impact various capabilities can have on your mobile development strategy.  

Read More

Mobile Dev Strategy: PWAs

 

When evaluated properly, a solid Progressive Web App (PWA) development strategy can have a huge cost and time savings affect for your organization.  This post is a dive into the necessary PWA principals which will best server today's business decision makers. 

Here, a realistic understanding of PWAs well beyond the often WAY over simplified - "PWAs allow you to access HW..." will be explored.

Let's begin with a question that often comes up when first discussing PWAs: "What's the difference between a PWA and responsive/mobile web page?"

An initial straight forward answer is that your PWA is a responsive web page, but not necessarily the other way around, and your PWA can access the device's HW.  However, there are critical PWA nuances many business leaders do not fully understand or miss with this very trivial explanation. 

Again, general understanding misconstrued as deep knowledge will likely lead to serious and costly mistakes when determining how a PWA can best fit into your organization's mobile strategy, and this (PWAs) is one area where it can cost you more dearly than others of mobile development.

PWA vs Responsive Web:

As mentioned - a PWA is likely a responsive web page but not the other way around.

NOTE:  Just to acknowledge this - yes, if I wrote some poorly designed HTML/CSS/JS which was not at all responsive, but still developed PWA capabilities along with my service worker and app manifest (more on these in a bit) - it is possible to have a PWA which isn't responsive.  This is simple acknowledgement, but not a scenario we'll be discussing further.

What we have so far is a PWA is a responsive web page which has a couple of extra files - the service worker and manifest.  All these files are, are files your developers use to state what HW and services the PWA will try to access (ie: GPS, Camera, Bluetooth, contacts, etc...) - as well as some behavior and UI specifics.  ie: the icon to install onto the user's home-screen when the user "installs" the PWA on their mobile device. 

Above, all good stuff, but pretty general web page reading.

Now let's look into the PWA surrounding capabilities, access levels, structure, and tactics which decision makers often don't fully understand and dive into the real PWA knowledge points which will have real world impact on your mobile and business strategies. 

PWA Capabilities Layer:

You'll hear it all the time, in fact, I've even stated it in this post - "PWAs can access HW and services on the device."  This is absolutely almost true!!!  And here's where PWA complexities will start to play a significant role in your mobile strategy decisions and where you will need to ensure you and your organization's decision-makers fully understand the finer points regarding a PWA's capabilities and perhaps more importantly, how they're achieved.  

The reality is - PWAs give you the ability to make request to the browser, which can then make a request to the O/S services for the information from the device's HW or other services.  So, does your PWA really have access to the device's HW and/or services - no.  Does this really matter?  Yes!  So yes!

Important points so far:

• Your PWA will have no additional access outside the device's browser capabilities, permission, or access levels.

• Your PWA only has direct access to the browser - not the device

• Your PWA will make requests to the browser for information and:
1. The browser chooses how or if to process the request from your PWA
2. The device's O/S then chooses how or if to process the request from the browser.  Note that the O/S will have no idea about your PWA - it cares about the mobile app. The mobile app is the browser - not your PWA

• The PWA will be running inside the permission boundaries and sandbox of the browser the user is using...
• Critical that you keep in mind that may not be the browser that natively comes installed on the mobile O/S - or even a browser you didn't fully test with.

Below is a general overview.  In the image the user has "installed" the PWA, ie: The "app" icon on the right side: (One note here - when a user starts a PWA after it's installed onto their mobile device, they don't see the browser really, but regardless, the PWA is in-fact running in the device's browser - just an FYI.)

Now that we have a more solid understanding of the PWA's inner-workings, let's take what we just learned and pertain it to solid mobile strategy decision making to determine how much of the organization's mobile presence is going to rest on a PWA.  Maybe all of it - maybe almost none of it...  

Leveraging PWA Capabilities:

When discussions come up about fully leveraging PWA capabilities, business leaders and non-engineer decision makers often find themselves frustrated with seemingly vague answers to what appear as straight-forward questions.  For example: when a business leader asks - "Can our PWA access the device's camera" and the answer comes back from the engineering team - "Probably" or "we should be able to."  Of course, inevitably, there's always one - "Absolutely/Of course!"

It is this very scenario which makes the decisions regarding how to properly incorporate a PWA into your organization's mobile strategy often difficult for business leaders.  

While it can seem frustrating, there are reason's your engineers are answering this way.  Here's how it breaks down technically:

• If the browser the mobile user is running your PWA inside of allows the call to take a picture...  Well then - Check-mark!

• If the O/S the user is running your PWA on allows that browser to access the camera to take a picture...  Well then - Check-mark!

• Does the user have an MDM/EMM/UEM active which does not restrict camera access?  If no...  Well then - Check-mark!

• Does the PWA make calls within the boundaries regarding what is allowed by both the browser and mobile O/S?  If yes...  Well then - Check-mark!
• ie: You can take a picture once every second on some mobile O/Ss, maybe once every 10 on others, but if you need to take 10,000 pictures a minute - a PWA isn't going to help you.

Thus, there are factors that play a role in your PWA's capabilities in the real world and "absolutely, we can access the camera!" - absolutely does not cut it when you're looking at serious investments dollars for your organization's mobile strategy and overall presence.

NOTE:  Regarding the first two points above, you're probably fine using the camera reasonably as most mobile O/S's and browsers have access and few MDM/EMM/UEM configurations are configured to restrict camera access (some do though).  But for simplicity's and clarity's sake,  I was just using the camera as a trivial example.

PWA Weaknesses (There aren't many - but there are some):

Let's start off this section with a discussion which revolves around the popular PWA concept of off-line storage.  This feature is a huge benefit and is truly awesome!  The issue isn't storing offline data using web technologies, it's understanding how much and for how long your PWA's data is stored and how it's "shared." 

What you'll need to understand as a decision maker is, there isn't a number regarding "how much" (ie: how many bytes) a PWA can stored nor for exactly how long. 

The browser will have some rules it follows for PWAs, such as evicting unused data.  This means that if the user hasn't interacted with your PWA for N (time), all your PWA's data, and your PWA itself are evicted from the device.  Evicted, since nothing was really installed - ie: nothing to "uninstall."

Some browsers state eviction after 30 days, others 90 days, and others have other rules...

Some mobile O/S's say PWAs are capped at X MB/GB - other mobile O/S's say X% of available disk space.  Again, "available" space.  Some users have a lot less than others...

Thus, when you as a decision maker states "we need offline storage."  You need to understand there are varying limits on amounts and durations...   How does that play into your organization's mobile strategy feeding into your organization's overall business strategy?

A final note about PWA storage to consider - remember your PWA is sharing the same sandbox memory segment along with all the other PWAs and the browser itself.  Therefore, if the browser your customer is using to run your PWA has a security issue - you likely do as well.  Essential rule of thumb - don't store hyper sensitive data on a mobile device, and certainly not in a PWA.  Keep in mind, this isn't logIn credentials - PWA's and browser excel at securing this type of info - this is about your organization's offline stored data.

Below is an image to help clarify:

The final point to consider when evaluating PWAs as a component of your organization's mobile strategy is frequency of device access to services and HW data and severity of background operations.  Please keep in mind that we're talking about more than the relatively simplistic use case of receiving notifications while the browser is inactive.  Instead what we're talking about is high pressure usage of the mobile device's HW and services at high rates while the browser is either shutdown or in the background.  There are some high performance BTLE or Location Based Services (LBS) access issues you'll fall short on with PWAs vs a native mobile app.

Again, this may be something which has no bearing on your organization's desired capabilities, but if real-time HW interactions plays a role in your mobile strategy - the PWA may need to play a different role, such as a support role to a hyper performant native app.

Regardless, it is highly likely that the inclusion of a PWA will only serve to strengthen your organization's overall mobile strategy no matter if its the primary or secondary component.

PWA Conclusion:

As we ended pointing out the finer details regarding the PWA's weaknesses, the fact of the matter is that an incredibly high percentage of organizations today could have their entire mobile solution more than satisfied by a PWA rather than a mobile app.  Now, regardless if the PWA's capabilities fully satisfy your organization's needs - PWAs should at least be considered as an extremely capable and great addition to any organization's mobile strategy today!

Read More