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.