written by ThinApp Founder, Ken Davis

Quick Mobile App Tip of the Day: What does the "Native" in Native Mobile Apps actually mean? 

In a nutshell, "Native" means - a mobile app made IN the environment (framework platform/program + coding language) that the makers of the platform created. 

So, for example - Apple created XCode (platform) and Swift (language) exclusively for "Native" mobile apps to be created for their devices (iPhones & iPads). And, Google created Android Studio (platform) for Apps to be made in their official language (Java) for Google Play - and all the devices that support Android, like Samsungs and such. 

Of course, Developers can also use all kinds of "old" languages too, which aren't the "supported" choice of Apple and Google.

PART II

For those interested in learning a little more, we'll get a little more in depth about the "native" app development approach. In our experience as both a builder of apps and a consulting firm that works with other companies who make apps (usually on behalf of a client who has come to us for a specific specialty), most companies "claim" to be native development firms, but actually use various coding frameworks as the basis of the Apps they build. There are tons of opinions about the value that these frameworks offer, but the simple reality is the more you use those frameworks (vs Swift or Java for example) the less "native" your App actually is. And here's why that matters:

If your App is based on a framework - and not truly native, then that means there's another layer of code, functions and logic being added to your App. What that does is simply "muddy" your code base, increasing the likelihood for mistakes, glitches, incompatibilities and overall size, not to mention volume of code. Although, some frameworks do minimize the code required by some features by utilizing the "library" approach, this only minimizes the first layer of code you see in the native programs, NOT the overall code in general, because usually you still have to connect to and/or import those support-code librairies in your app to even be able to use or reference them - which now creates a "dependency" on that library, framework or API - thus creating another variable that you have to make sure stays up to date.

We always tell clients this - Mobile Apps are a 2-company game now. Since Microsoft bowed out a couple of years ago, Apple and Google now both control the entire market share of mobile apps. They also coincidentally control and are the makers of 2 of the 4 most used browsers - Google Chrome and Mobile Safari. Just think about that for a minute.

Now, here comes the aha moment - they both are now not just "tech" companies any more - they are also "device" companies now too. They both make phones, tablets and computers - and they are constantly coming out with new ones, which sends a ripple effect of changes all the way down their ecosystems. Have you ever noticed how many issues there are with the various OSs (ie. operating systems) of phones when they come out? That's not a mistake. Obviously, those companies are focusing so much on getting their new products (er uh phones) to market that they are a little distracted from the software. Get the phones out. Make billions. Fix software after in update patches. Then, somewhere and sometime after that, we eventually get updates to the whole mobile app ecosystem (ie. XCode, Swift and Android Studio). 

A lot of times, both Apple and Google's Developer ecosystems, message boards and even little notifications right in the code will let a Developer know when a feature or function is going to be going away soon (ie eliminated, updated or replaced). They typically call this "deprecation" (ie. this feature will be deprecated, but you can still use it for 4 more months). So, it's basically inevitable that the coding environments (and programs) that mobile apps are made in are perpetually changing. And, as long as Google and Apple continue making money from phones you can pretty much count on it. So then the question looms - Is it really smart and cost effective to use a framework? If you do, now you have to wait for Apple and Google to make their inevitable changes (and improvements) after a big device/phone release - then you also have to wait for that framework to update before you even get to update your app (to make sure it still works on all the newly released phones and tablets).

Most Developers will argue to the ends of the earth in favor for this approach, claiming that it saves clients time and money, blah, blah, blah. Oh sure, it's helping you. Ok. It's all fine and dandy until that big release comes and you actually see how fast your app gets updated and what it costs you. If it does save you time and money, then why the heck are mobile apps still so darn expensive? Well, they aren't and shouldn't be, but that's another article. 

In our experience, what we've learned is that making mobile apps is indeed difficult, time consuming, cumbersome and expensive, but not as expensive as 90% of development firms claim - and our technology and prices alone proves it, but we aren't the only ones. There are other firms out there that are as efficient, we're all just a smaller pool. But, this isn't about us (or them) - this is about the "native" approach and common sense. Common sense would lead one to deduce that no matter how smart a developer or even a team of developers is, they're still no match for Apple and Google's engineers, developers and armies of smart people. So, trying to doing anything but "native" is really like trying to shoot a moving bullseye. You're trying to chase and keep up with 2 near trillion dollar companies who are moving SO fast, they can barely keep up (their software/OSs) with their own device/hardware releases. 

At ThinApp, we believe that if you follow current industry-standards (ie. what the "big" boys...and girls, ie. famous tech companies are doing), good coding practices and some modular approaches (towards development) that you can easily maintain a fully "native" app for your Apple iOS App and another one for your Android App that will be less expensive than every other alternative, both upfront and long-term. Singular back-end webservices that "power" both apps is a no-brainer of course (we'll release some articles on this soon) and obviously helps keep that overall cost down. (FYI - for example, ThinApp uses RESTful API-styled webservices with JSON to power both apps from one single back-end).

What it takes every other development firm (or Creative Agencies) 10 to 30 people to do, we can typically do with teams of 4-5.

And for those that say the framework approach is "native" - no, it's not. Sorry, you're not getting a native app - a partially native app maybe. Disclaimer: Yes, there are a lot of "famous" apps that aren't completely "native" - that doesn't make it right or wrong and when you consider they have entire departments dedicated to it - do you really want to try to replicate that? 

And for those who says it's less expensive (to go the framework route) - well, maybe they just aren't that great of developers to begin with because while it may be a difference of $250k (for the native approach) to $150k (for the framework approach) for them (for example) - we make the same apps with visibly superior, world-class front-end UI/UX (ie. User Interface & User Experience, ie what the User sees and touches) in a way that's much more stable and has much longer-term performance for about 1/10th of that (in both cost and timeline).

So in summary, "native" mobile apps are apps that are made the way Apple and Google intended them to be made (for their phones and devices). Feel free to deviate away from that as much as you like - and feel free to hire companies that do, but at least now you know to ask if what they're going to be making you is based on a "framework" or truly "native".

Here are some articles below for reference. We didn't reference these, but we always like to give our clients and readers a jumpstart of seeing what others have said about these things:

Apple iOS

https://developer.apple.com/swift/

Google Android

https://www.zipcodewilmington.com/blog/i-want-to-develop-android-apps-what-languages-should-i-learn

https://www.androidauthority.com/develop-android-apps-languages-learn-391008/