Should you build a native app? Is X technology better than Y? Do I need an Android app?
These are some of the most common questions that our clients approach us when we start talking about building a mobile project for them. I tell them what I am telling you now… it depends. Each project targets different audiences and has different requirements. It is these differing factors that play a major role as to which technologies are used to develop mobile apps. Today I am going to talk about some of the benefits that Native mobile app development has.
Native development is getting easier.
In the beginning…
IT firms and developers often describe native mobile development as the hardest and slowest approach to building mobile apps. There is some truth to that. And it was especially true in the early years of mobile development. Developer tools were crude and were not developed originally with mobile in mind (XCode 3 and Eclipse). Good tutorials, methodologies and communities were few and far between, and there were nearly no schools or courses to learn to be a mobile developer.
App stores may have been seen as the next great gold rush for games and novelty software, however, practical business uses seemed to be lacking. User interactions and experiences seemed to lag behind what many websites were doing and user adoption in a workplace setting was rather sparse, especially outside of the IT departments. In all, mobile apps appeared to be on the path to being just a fad.
But things have changed…
Thankfully things have changed. User adoption is continuing to grow. Smartphones have become commonplace rather than the oddity. Even smartwatches and other connected devices are starting to become status quo, and with this, the toolsets have become significantly better.
XCode has first class support and Swift has been out for over 3 years now and each iteration becomes cleaner and more precise as the carryovers from Objective-C start to fade. Even autolayout and constraints have greatly improved to allow developers to implement designer’s fancies much easier.
JetBrains and Google have teamed up to make Android Studio. Android Studio gives developers the power of Java development familiar to IntelliJ and the added benefit of automation, libraries and editors that are geared towards making the next great app. Now with the addition of official Kotlin support in Android O (Google IO 2017 Announcement), Android developers are going to be able to write more precise and cleaner code.
Life is getting pretty good for native developers. Time to market gaps and cross platform training is becoming less of an issue in the choice for going native.
OS knowledge is still required
Against the beliefs of some managers, not all software development is the same. Slinging code is just as much an art as it is just telling the computer what to do and good senior developers are able to balance good and bad outcomes of the decisions to choose their implementations.
Good decision making is done by knowing how the system works and why you would use method X vs. method Y. Just because a developer is good at building APIs, does not mean that the skillset is translated to building an embedded system.
This is the issue with systems that lay claim that a [Web, C#, Java, C++…] developer can create a mobile app with almost no training. The knowledge of the systems is lost in translation. I first started to build mobile apps using Cordova and my web skills to build software that ran on a mobile phone. This did not mean that I was necessarily a mobile developer. I had to learn about the iOS and Android ecosystems. What makes them the same and what makes them different. As projects grew past simple business applications there almost always seemed to a reason I needed to deep dive into the native code and hardware functionality to add a key feature or to fix performance issues properly.
Building mobile apps with your existing developers sounds great in a sales call, however, in practicality, a lot of the knowledge that is needed to write an application with a native build system is needed even on the other approaches.
Removing the abstraction
Projects with more dependencies have more failure points. This directly translates to project risk and project costs. Using any abstracted software adds this risk to your project. Alternative mobile app platforms are sometimes dependent on hundreds of other libraries just to work.
Don’t believe me? Here is a real example. I have enjoyed the Ionic platform since pre-Beta and love what it offers in the hybrid mobile realm. It is usually a great option to get mobile apps to the market quickly and provide lower cost options for some projects. Late 2016, Milk Can started work on a project that we have been planning and talking about for the last two years. The developers on the project had more than a few conversations about what the MVP platform would be. We narrowed it down to Ionic and full native for numerous reasons.
What did we choose though?
What did we choose? Our final decision was to go Native. For this project it made the most sense.
Okay Matt… still waiting to hear how this abstraction thing comes into play?
Well here it is. In November, Ionic 1 was the recommended version to use (2 was still in beta). Since the start of our project, version 2 came out, then 3, now 3.X. And each of these had breaking changes. This is just the core. Some of the libraries that we would have used have also had multiple changes. All of these would have caused our development to stop and fix items that were done correctly originally.
Were there upgrade tools? Sometimes. There were ways around most of what I am describing, but it is something you have to be aware of. iOS and Android did not have breaking changes themselves, this was all at the abstraction level. Those changes would have caused issues as well. In fact with the release of iOS 9, due to last minute changes by Apple, there were breaking changes that had to be fixed, patched and released at the Ionic level that affected many Ionic apps. The Ionic team responded quickly, but with Apple review times, it took some apps weeks to recover.
Again, the Ionic team is great, and their tool is amazing. The same can happen (and does) to Xamarin, React Native, Unity and more.
New shiny features!!!
This is another issue with abstracted platforms. You have to wait for support of new features and implementations from the 3rd party before your app can take advantage of the latest features. This usually does not affect that Android platform as much as iOS. This is because of the current delays in update support for many Android devices. However, Google is consistently upgrading the Android platform to remove this limitation from being a factor. So if your goal is to take advantage of new features to get your users excited and engaged with your mobile apps, native is nearly always required.
Give the users what they expect
Android and iOS have different user experiences. And by this, I do not mean just the presence or absence of the back button. Interactions and assets differ between the platforms. Often mono-platform users have difficulty when the interactions that they have learned to count on, react differently.
Native is not the only approach to give you at least some of this. Ionic does a pretty good job of handling some interactions that are more native feeling with the same code set. But in platforms like React Native, Xamarin and Unity, you are either forced to use a limited set of controls, or to build your user interfaces multiple times. When you add in the life cycles, animations, power management and storage, you are sometimes talking about very little code that can be truly shared to give your users a native feel.
So… I should just do native app development???
Not at all. As I said in the beginning of this article, there is a time and place for nearly all mobile platforms. Knowing when to use the platform is the key. These were the benefits of mobile development, I plan to have articles in the future about other options as well.