With the already huge and still rapidly rising popularity of mobile phones, there is an equally fast growing number of different tools for building applications for them. It’s no longer just a case of deciding what libraries to use but also what patterns and development environments empower developers, UI and UX designers the most, to produce what they need easily. While planning one of such mobile projects with a non-technical client, we summarized various possible approaches for him but the text is so generic, it applies to any mobile project and may be just as useful for future clients as well.
Read on to get an overview of how rich the mobile developer's toolset currently is.
Summary of approaches
There are three major methods for developing apps: native, hybrid and embed.
The most popular is still native development which focuses on using platform specific languages and functionalities. Compared to the other two it's the most low level approach, requiring knowledge about all platforms that an app is being developed on but it also unlocks all the abilities of specific platforms and is always the most up to date, allowing newest technologies to be used.
For example, Google provides a set of compatibility libraries backed by online tutorials that, depending on the version of their Android system, use different system functions to do the same thing. It’s sometimes a cumbersome and complicated process to use them and definitely puts more pressure on developers to find ways of creating great apps while still making them widely available but it gets the job done.
Of course, whether it’s a good idea to put more work into a project and provide a spectrum of approaches depending on what devices most users, say 80%, have or only support the newest technologies and isolate most users is up to the client to decide.
There also exist companies that do not gracefully add new functions to their apps over time but instead switch to completely new designs that work only on newer phones while still supporting the older, separate version for older phones until their popularity falls below a certain level.
The burden of having the knowledge to develop on multiple platforms can be decreased by having multiple, specialized developers and ensuring they share knowledge between themselves. Many times, the only part of the app that really changes between platforms is the user interface. If we want to create something comfortable to use on iOS, Android and Windows Phone, we'll have to adhere to three different design guidelines. But the logic in the background stays the same, minus having to write it in a different programming language.
This similarity is where the most obvious optimization could’ve been made and it has. I categorize these tools as hybrids but depending on the specific tool, it might be more or less about converting code to native, machine code and not simulating anything. Xamarin and React Native qualify as such hybrids. The first uses logic written in C# and distributes it in combination with different interfaces depending on the platform. Xamarin abstracts common UI elements so that during compilation native ones are used.
That being said, in some cases, custom native code might be a better approach, like when doing very specific interfaces. What that forces is either having two developers, one for native code and one for shared code or finding a developer with skills in both areas. How much code will be shared varies from project to project. The more logic and less visuals are needed, the faster the project will be delivered compared to native development.
Xamarin is also a complicated tool, has bugs and problems of it’s own and forces some conventions upon developers which can prevent some things from being done in a straightforward fashion.
React Native works similarly except it doesn’t compile logic to native code. Instead, it uses a separate thread to run logic so even if it’s JavaScript being run on mobile devices which potentially means slower execution of code, the interface runs separately and without any hiccups. React is a much younger tool than Xamarin, so it doesn’t abstract as many things as Xamarin does but it’s been gaining traction rapidly for the last few months. For one, it requires more native code than Xamarin for specific mobile platforms to create really custom apps. One major advantage of React over Xamarin and native development though is very fast rebuild time. After the initial build, updates take milliseconds to appear on screen. I also experienced some disconnects during development between the ongoing React thread and phones, so there definitely is room for improvements and bugfixes but it does look promising.
The last possibility is to simply run a website within a mobile app environment. It doesn’t focus on creating the most native look-and-feel in apps or achieving native running speeds but is currently the simplest (in terms of programming skills needed) and fastest way of creating apps for many platforms at once. Pretty much every tool for this task uses Cordova behind the covers. Ionic and Meteor represent this group but they’re really just frameworks for creating websites with Cordova integrated inside of them. For example, AngularJS, React or just plain HTML with JavaScript can be used instead. If building apps fast is critical and not bells and whistles, it might be a good choice to use one of them. Clients who know that Cordova exists tend to use it for prototyping ideas and less important products, as the decrease in quality is pretty significant. Because apps created this way tend to not look fully native, they might get rejected from stores easier than hybrids and native apps.
End notes
There are many other issues to take into account before making a decision and the three major options do interpolate each other to a degree. For instance, Basecamp created their mobile experience by putting HTML websites into their apps in various places. Hybrids, as already mentioned, can dip into native APIs for more control and embeds can recreate views with HTML and CSS, closely resembling native ones in how they look and work.
In my opinion, hybrids will eventually become most popular. An analogy to this is when Apple released the first generation iPhone years ago with a different, more touch friendly interface but with OSX as the base. At the same time, Microsoft still has problems with making Windows touch, keyboard and mouse friendly. It’s impossible to create a single interface that will work perfectly on any hardware and software stack. I believe this issue will be emphasized by even more IoT devices in the future. Nowadays, the tech market is being flooded with smartwatches which need a completely different interface. To be comfortable to use, we need to accommodate for their small screens. With hybrid apps, it’s possible to simply change the interface and keep existing logic from mobile apps and cover a new user base much faster. This is as far as we can go with optimising development time and retaining the right level of user experience. However, with the choices we currently have, the best way to figure out the optimal setup for development is to check the requirements of the project being built. When we know what we want to achieve businesswise, we’ll narrow down the number of choices and get a satisfying solution. Deciding to build a simpler app might be a good choice for an MVP version, so don’t assume upfront that native is always the way to go and others aren’t as powerful. Power is relative. Also, as a software house, don’t immediately assume that a client wants a native app. He might not understand what he’s getting into.
