This article explores the features of full-stack mobile development environments and covers several core native and hybrid mobile alternatives and the factors that influence the selection of each platform.

First, let's agree on language. The term full stack conjures up an image of a singular, multidimensional chameleon of an individual with as much ability on the graphic side as the system administrator and database engineer. In some exceptional cases, this individual might be what is sought. More often than not, though, full stack refers to those who have familiarity with and desire to keep current with business logic and processes of front-end frameworks, back-end databases and services, and automating application and data creation, editing, and provisioning. It is less the ability to craft and edit media as it is to make it presentable and interactive.

Full-stack mobile app development lies at the nexus of content and technology. Billions of people worldwide now use smart phones and tablets, which form the client side of the full-stack app. The server side is often a distributed collection of microservices, authenticating servers, and CDN assets that are compiled at runtime each time an application is opened. Between the two lies the processes that connect them, including testing, continuous integration and continuous deployment, scaling and containerization, and proprietary device requirements.

Devices are driving the way that media is delivered and consumed. In many cases, people are more likely to watch, read, or listen to news and entertainment on a handheld device than traditional television and radio. Televisions themselves form a device target for developers.

As a nexus of technology, mobile devices drive competing paradigms championed by such behemoths as Apple, Google, Facebook, and Microsoft®. Each of these giants has vested interest in the battles for device audiences. While Apple and Google are the two brand stewards of iOS and Android, respectively, React Native and Xamarin are products by the latter two that you can use to author apps that are increasingly native in design and function. Tech companies are heavily waging on this market to continue growing, and they are actively seeking the best and the brightest to buy into their vision of how to best service it.

Full-stack mobile development

To be a full-stack mobile developer, you need to have an understanding, or vision, of the big picture in app development.

This includes:

The look and feel in devices
The servers and containers that are accessed to provide content and data processing
Development processes like testing and debugging
Reasons and trade-offs behind choosing solutions among many alternatives

If I had to choose the most desirable trait for a full-stack developer to have, it would be the ability to lead the project and effectively communicate understandable processes. Full-stack developers must set up repositories, project management tools like Jira, communication apps like Slack, and they must be familiar with diverse client frameworks, databases, APIs, and microservices. Ultimately, they must be able to support and influence project management decisions. Full-stack developers share many traits with the architect or project manager of an application in addition to client and server stack abilities.

The client side of full-stack mobile development

Broadly, the client side can be broken down into native and hybrid silos. Generally, when you need higher performance, you want to be as native as possible. The benefits from hybrid development often come from using familiar web tools and constructs. The choice for developers is usually between learning and using a language, such as Swift or Kotlin, or going with something that is similar to what they already know, like JavaScript and CSS. Another benefit of hybrid development is the potential to use one root set of components and styling for multiple devices. Each device has its unique qualities in look and feel, but these can come from a single source, unlike native apps.

Let's define new concepts to look at the comparison: native versus cross-platform coding and native versus hybrid execution.

What do we mean by native and cross-platform coding?

Native (coded) apps are developed with programming languages and tools that are offered by the company that develops the platform and the OS that they run on. For example, native iOS apps would be written mainly in Objective-C and Swift, whereas native Android apps would be written in Java code or Kotlin.
Cross-platform (coded) apps are developed in programming languages and tools not included in the development tools offered by the company that develops the platform and the OS that they run on. This is a broad categorization, including stacks and frameworks like Ionic, Xamarin, React Native, Apache Cordova, Flutter, and more.

Let's now look at the difference between native and hybrid execution.

Native (executed) apps are written in native or cross-platform programming languages and are then either compiled to assembly code ahead-of-time (AOT) or just-in-time (JIT), which still leverage native UI widgets. For example, apps written in Xamarin, React Native, and Flutter belong to this category. This is a recent concept, as supported by the fact that these frameworks have all been recently released (Flutter had their first stable release in December 2018) or in early stages of maturity (although often used in production, React Native versioning is still far away from release "1.0" as the most recent version at the time of writing is 0.59).
Hybrid (executed) apps are written in cross-platform, web-based programming languages (HTML, CSS and JavaScript/ECMAScript or their supersets such as SCSS and Typescript) and are executed within a native shell, usually a WebView or equivalent. Apps written in Cordova and Ionic are examples of this category.

The server side of full-stack mobile development

Mobile app development at the server is in large part similar to desktop or web server app development. Exceptions include the limited way that new applications are installed on a device (that is, the Apple Store or Google Play), server-side functions that are tied to a single operating system, and nuanced ways that device apps can be updated using a specific service, such as Meteor or Ionic. Similarities include the way that data is interacted with through API calls, updating content through version control, and ensuring scalability and persistence. Throughout the project, full-stack developers often research how to best balance the load of processing, caching, and other tasks across microservice layers that make up the server side of the app.

Consider these mobile design methodologies for mobile web design and mobile app design:

Responsive design: Responsive design was introduced in earnest with the arrival of mobile devices, taking advantage of CSS media query business logic, size, and orientation features. Its intention is to respond to distinct static and changing features of the application’s presentation. (Learn more about the future of responsive design in this IBM Developer article.)
Adaptive design: The difference between adaptive and responsive design generally refers to the fixed, discrete measurements of the former compared to the typically fluid sizing and placement of the latter. In adaptive design, you tend to see more exact dimensions for multiple display resolutions.
Progressive design: Progressive design, such as that in progressive web apps, refers to apps or sites that can load quickly and that have an authentication layer available for tasks such as filling in form fields or setting the display of a map.
Mobile first: Mobile first is a guideline for designers to develop traditional web content in a manner that the smaller screens of phones and other devices have first consideration and the highest quality views when possible.
Offline first: Offline first refers to developing an application that is able to function when there is no network connection. This can include features like having initial content loaded in the app, using local storage for accessing and saving data, and avoiding interruptions to the user experience.

While these terms might seem more at home when speaking of websites and pages, applying these same style techniques to mobile devices generally requires a bit more fine-tuning than their traditional counterparts. Both Android and iOS provide for a number of different resolutions and sizes of icons, screens, and fonts. Even when using scalable content, whether SVG or dynamically calculated dimension and placement, the exactness that is required for each of the specific devices for each platform can be daunting. Fortunately, most tools these days do a great deal of the work for you. It is a good idea to know the specific devices and platforms that you intend to support. Particularly, you should know the minimum requirements and the size breakpoints that require different presentations of the app.

Features of full-stack mobile development environments

Full-stack mobile app developers likely need to ensure that their production environment provides the following features. These might be considered as more the realm of the full-stack developer over back end or front end concerns.

Automatability: Forget spell-checking this word; we know it through terms like continuous integration and continuous deployment. It is vital for current coders of mobile apps to allow for updates that do not break an app or take it offline.
Scalability: A close relative to automatability, also dealing with deployment, is the scalability factor in design. This includes containerization (such as Docker) and database and disk redundancy to ensure against data loss and reliability. Many developers become victims of their own success when scalability is not properly executed. CDN, caching, and the ability to add and remove boxes from the network all contribute to this phenomenon.
Feedback loop: There are several places where user feedback can provide guidance to developers. This can include testing frameworks and build mechanisms, and also getting user feedback through interface or session tracking to understand how people typically use an app or are blocked from using app features.
Accessibility, internationalization, and localization: A great opportunity for reaching previously overlooked groups comes from personal enhancements like accessibility, language, and localization, which can increase the value of your app to a wider audience. When you use variables instead of text, localization and internationalization become broadly trivial to implement. Accessibility has still not taken the deep root in web content design that it merits. There are more people who can use accessibility features than there are users of Internet Explorer, for instance. When you consider the size of the markets that are not difficult to serve, the onus is on mobile developers to rise to the occasion and fight to address these features. Each of these accessibility features brings rewards that are balanced by their impact on development time.

Choosing a mobile development framework

Choosing the right mix of tools for building a mobile app depends on a number of criteria, including:

Ease-of-use of the tool and its ecosystem
Device-appropriate look and feel for content, including fonts and iconography
User experience and wow factor
Integration with third-party APIs and network services
Community support through forks, stars, likes, and other ratings
Documentation and current examples
Familiarity of previously known code and constructs (for example, familiarity with React for the ReactNative framework)

The degree to which competing needs factor into software choices varies for a number of reasons, including time, budget, and demographic targets. There is often no single best answer, but there are reasons why some make more sense than others for specific applications and their intended audiences. Table 1 presents six popular tools for mobile app development.

Core software	iOS	Android	Web	Pros	Cons
XCode	X			Only method to author iOS and MacOS apps.	Large and proprietary; forces developers to include it as well as their own IDE choice.
Android Studio		X		Android Simulator; large plug-in community.	JetBrains tooling, not Eclipse or other IDE for those familiar with those Java™ tools.
Apache Cordova	X	X	X	Ports WebView straight to native implementation.	Online articles and sources not always up to date.
Xamarin	X	X		Visual Studio and C#; familiar to Microsoft developers.	Microsoft bias in code and services.
React Native	X	X		Large community and ecosystem.	Hybrid app is not as fast as native app.
Ionic	X	X	X	Free and pro version differentiated; Pro has server-side features that include continuous integration and testing.	Hybrid app is not as fast as native app; not as large of a community; Angular bias.

At first glance, you can already determine that if you are including an iOS target, you need to have an Apple ID and associated account and XCode installed. For Android, although it is not clear here, device simulators are most easily accessible through Android Studio. This generally indicates that the fastest apps are written with the Apple or Google-backed software. The larger benefit for the other four come from integrating common code into native apps, which means that web developers lose less time due to learning curves during production.

IDE, CLI, and wrappers

Integrated Development Environments (IDEs) have been around longer than the internet. The Command Line Interface (CLI), while older than IDEs, has been experiencing a rebirth through open source embracing the CLI as the most typical way that apps are created today. Mobile apps introduced the concept of a wrapper technology: something that we know from the web like a plug-in on a page that communicates with the browser wrapper around it.

For example, when you build an application in React, it goes through a transpiling before it is published. During that process, the code is converted into something that works in all target devices and browsers as defined within a webpack configuration file. If you put this inside of a wrapping technology for a device, it involves something similar to applying the transpiling performed by Babel or Typescript on the entirety of the client application. A wrapper is the shell that communicates with the system outside of itself (its parent) as well as with its child.

Several of the reviewed software include IDEs, versioning, deployment, and CLI companion software; others require a wrapping technology to author mobile apps. Ionic, for example, is generally written within a Cordova wrapper, and Xamarin and React can be as well. Singularly important is XCode on the Mac for iOS authoring. It is the only must-have among the software to develop native apps for Apple devices. Apache Cordova stands out for its export to browser content. For those wanting to have a single codebase for mobile web and device applications, Apache Cordova remains in the front row of choices for targeting the most platforms. See Table 2 for the comparison of IDE, CLI, OS, and languages for each of the mobile development frameworks.

Core software	IDE	CLI	OS	Languages
XCode	XCode	xcodebuild	OSX	Swift, ObjectiveC
Android Studio	Android Studio	gradlew	OSX, Linux®, Windows™	Java code, Kotlin
Apache Cordova	PhoneGap, Builder, others	cordova	OSX, Linux, Windows	Node, JavaScript
Xamarin	Visual Studio	msbuild, others	Windows, OSX	C#, F#, VisualBasic
React Native	Atom, Sublime, others	react-native, expo, others	OSX, Linux, Windows	Node, JavaScript
Ionic	Visual Studio, Atom, others	ionic	OSX, Linux, Windows	Node, TypeScript, JavaScript

At the time of this writing (late 2018), Swift 4 is the current and most popular language for XCode iOS apps. For Android Studio, Kotlin is increasingly the language of choice over Java code. Of the four remaining, Xamarin stands alone in the C# and .net universe, while the others are closer to hybrid development platforms. Ionic was built from an Angular root, React Native from a React root, and Apache Cordova is that open source agnostic center of all things hybrid. It is the closest to a Swiss army knife in the group that can convert most any web content to platform-specific applications.

A word on dependencies

Keeping an open source application stable with a large number of dependencies can be daunting. For many, yarn has replaced npm as the most used package manager for handling them. Both now produce .lock files that include version numbers of dependencies. The .lock file associates specific versions of libraries with a project, giving confidence that a project will be able to recompile at a future point after one or more dependencies might no longer be supported by one or more library partners.

Online examples often use a mix of technologies, and it is not always easy to find preexisting stacks that give you exactly what you are seeking. StackShare and other sites let you see what others are using, compare usage, and seek as close a mix to your tech stack as possible. Whenever you find something close to what you are looking for, check the dates of the libraries and make sure that you are using the most current versions possible. This could require you to edit a stack that already exists but might be out of date.

Developer and contributor communities

Among the factors to consider when selecting the right software for mobile app development is the size of the developer and contributor communities. How much mindshare does a technology capture? How available is support, and does it cost to access or use it? While a technology might claim a great deal of support in a given moment, how has it performed over time against competitors?

Angular was the most important framework to know five years ago. Today, Angular appears in its Ionic derivative form and can be included in an Apache Cordova wrapped app. For all the features that Xamarin offers, its core product is based on Microsoft languages that many developers still seek and just as many developers avoid. React and React Native are the most popular of the client-side frameworks today, but this has been a historically finicky market that has been known to change, sometimes often and quickly.

Figure 1 is from stackshare.io, a site that you can use to compare technology stacks on a number of axes and was captured in May 2018. You can use stackshare.io to help you make the decision as to which mobile development framework is right for your solution.

Figure 1. Compare technology stacks

Lastly, Microsoft, Google, and Apple have developer conferences each year, where they announce new products and present product roadmaps. In 2018, AI, XR, and IoT features for mobile apps were announced. The short story is that in mobile development, things do not stay constant for long, so always make sure that your information is current by doing searches throughout the development process.

Summary and next steps

This article provided an overview of some of the most popular tools (in 2018) for developing full-stack mobile apps. I touched on some of the core concepts, considerations, dependencies, and ecosystems, while leaving the heavy lifting to upcoming articles and tutorials.

Mixing ecosystems and dependencies or tools and technologies in a way that you are most productive and fully enabled is a never-ending process. What is true today will invariably be out of date in the near future. Full-stack mobile developers embrace change, as it is the only constant that is always true.

Getting started with mobile development on Android

Getting started with full-stack mobile development

Getting started with mobile development on Android

Getting started with full-stack mobile development