To understand full-stack mobile development more fully and to explore native and hybrid mobile development alternatives, read Getting started with full-stack mobile development.

To design a full-stack mobile app, you must consider the total user experience of the app – from the graphical design of the user interface, to the performance of the app, to requesting support when something goes wrong. Additionally, you need to consider each platform and the expectations of the users based on that platform.

Mobile apps have been around for over a decade now. Developers are tasked with including a number of criteria in the user experience for a modern full-stack mobile app:

Initial and subsequent loading animations
Responsive and adaptive design
Device and platform-specific fonts and iconography
Consistency and familiarity with app brand across devices
Caching and other forms of persistence
Offline and network-interrupt experience
Asynchronous considerations for UI

While some aspects of design are similar across web and mobile applications and sites, others are unique to each. Broadly, you can consider the application body, form controls, font and typography rendering, component rendering, and navigation or routing as those elements that need to be addressed for each distinctly.

Web versus mobile web versus hybrid versus mobile app design

Web designers of days gone by had their roots in print design, but that is less common these days. Many modern mobile app designers might have a background in traditional web or print design, and as such, mobile app developers need to recognize and benefit from the commonalities but also need to differentiate between the user experience, concepts, and tools that are available and appropriate for each environment. Things that work in one environment or platform might be out of place in another for myriad reasons.

To learn more about the different types of mobile apps, read Choosing the best programming language for mobile app development.

Briefly, it is not difficult to imagine how and why traditional web design evolved into mobile web design. Pages and sites still exist that are built only for the desktop browser, but these have been replaced in large part with a mobile-first responsive design paradigm, most likely because Google changed its algorithm to rank mobile-friendly web pages higher. Well over half of site visitors to traditional web content experience it from a mobile device. Among other things, this means that mouse events like hover do not apply; at the same time, orientation and multitouch events have been added to the mix. Through the use of media queries in CSS and counterpart code in JavaScript, traditional web design has been able to include device targets using familiar constructs in new ways.

While mobile web design generally refers to browser content, it can also be used to describe content within a UIView embedded within a mobile app. Hybrid design, on the other hand, refers to a design paradigm where the output content is the mobile app itself. For web designers, hybrid design provides a bridge between familiar frameworks such as React or Angular, and those needed by iOS and Android devices. These include approaches as disparate as React Native, which outputs native mobile apps, and Apache Cordova, which essentially wraps mobile web content and provides an interface for communication with native mobile app functionality. Both of these output native apps: the former does it with new components that match native features, and the latter does it by providing a messaging layer from web content to the native environment.

Mobile design methodologies

One of the greatest challenges to mobile design is ensuring expected, acceptable presentations across broad device targets. These can have distinct aspect ratios, display resolutions, bandwidth, and power differentials. Vendors like Facebook have published Facebook Lite on Android, which does not include video features, for instance. In many cases, the vendor has tablet and phone versions of apps.

In the following list, the first three items refer to physical presentation level descriptions of the device. These include size, operating system, and orientation. Based on these, a different view of the interface is displayed. The last two items refer to design considerations that differentiate use cases in favor of mobile and offline, respectively. It is important to remember that the world’s content audiences consume primarily on mobile devices that might be unable to be online.

These terms apply to 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.

Essential design considerations for mobile apps

The structures that are perhaps the most important to consider when building a mobile app or desktop app are the layout hierarchy and the navigation, or routing hierarchy. These structures are the high-level organization that arrange the interface into pages, views, or components and their children or nested components. The way that the pages, views, or components are structured influences the type of navigation that is used within an application, such as a tab or stack navigation. Mobile app designers must then factor orientation, resolution, and pixel density into the style guidelines and templates that are created for the app.

You will face specific challenges no matter which app building technique you choose. Sometimes you can circumvent these challenges through hybrid design, but that often requires designers to be exposed to each device platform’s requirements or idiosyncrasies. We might want to design once and consume anywhere, but we are often forced to incorporate device-specific look and feel considerations, such as the placement of navigation or the appearance of a form element.

Table 1 gives a high-level view of how you can approach these design considerations in native and hybrid mobile app development.

	iOS	Android	Cross-platform
Application body	Controllers and views.	Activities and containers.	Body and divs.
Navigation	Navigation generally on top.	Navigation generally on bottom.	Navigation on top.
Routing	Handled by controllers and not exposed in URL form. Storyboards and views provide presentation layer routing.	Floating action button (FAB) is the initial starting point. Layouts and activities are the main landing areas and host secondary navigation elements.	Often used in conjunction with state, allows users to have drill-down access to content. URLs often drill down to state and routing views and nested content.
Component rendering	Uses built-in or custom-built components that have details included in the application at build time.	Uses built-in or custom-built components that have details included in the application at build time.	Can use traditional HTML components that are translated to native counterparts. Often requires special attention when using custom or non-standard native components.
Form controls	iOS has form controls that are unique to it, such as the spinner. These might not be matched on others, and substitutes could be required.	Android’s form controls also have unique controls. Select elements and other multidata components do not match traditional form elements.	HTML components, but these should be tested on devices (not only simulators). Form elements are among the most difficult to match across platforms.
Custom elements	Elements can have their own independent font, sizing, and placement requirements. Third party as well as platform guidelines might both be required for placement, scaling, and interactivity.	Elements can have their own independent font, sizing, and placement requirements. Third party as well as platform guidelines might both be required for placement, scaling, and interactivity.	Some third-party elements can work the same in web and hybrid app settings, but these often require additional code in the wrapping or host technology.
Font and typography	Apple users have font and typography expectations that are provided on the Apple developer site.	Android can use Google’s Material Design and other device-friendly fonts and layout guidelines.	It is often prudent to use preprocessing methods that discern which device is being used so that fonts and typography match appropriately to the platform.

Regardless of the platform, regardless of the approach you take, native or hybrid, you should respect users in a common fashion. For navigation, 48 pixels has been a guideline (1.5cm or 2/3in) for the minimum diameter of a touchable screen element. Orientation change on devices is handled rather directly, in adaptive fashion, as opposed to the choices available to hybrid development.

One of the more common pitfalls to make is treating mobile apps too much like traditional or mobile web apps. While React Native can give you access to CSS flexbox styling and Cordova gives you even more familiar web styles and constructs, XCode and Android Studio do not, nor do the native languages understand CSS. Also, websites look like websites. When a mobile app looks like a website, you notice that you are no longer in the warm and fuzzy that the native look-and-feel provides.

iOS styling

Within XCode, you can create and insert storyboards, views, and components within them and use constraints and alignment in the interface builder to position content. When moving between hybrid and native environments, you must realize that, ultimately, it is what you see in the native application authoring environments that is addressable from processed code. That means that whatever is used in React Native or Apache Cordova will at the end of the day be translated into the same constructs that are available in XCode, in the case of iOS. Becoming familiar with these by spending some time in XCode can improve the way that you structure hybrid apps in other tools.

Android styling

Android Studio, unlike in XCode, is one of several applications that you can use to author Android apps. In the case of iOS, the application is required for exporting the completed app. Android Studio provides emulators in addition to its authoring environment. From the GUI, you can see similar properties to XCode available for its visual elements. There are some identically named, such as view or button, but the two systems are not directly compatible. With Android, there are many more target environments to consider than iOS. Emulators do not always reveal how items actually look on devices, nor do they exist for every targeted device. Using Android Studio can give a broader view of what components are built-in and available than by using hybrid approaches, which generally offer subsets of what the native environment itself provides.

Conclusion and next steps

The overriding concern for the design of full-stack mobile apps is the user experience. Mantras that we have adopted such as mobile first or offline first both draw attention to this consideration. Well over half of all site visitors in 2018 use mobile devices, including not only smart phones and tablets, but other screens that might use iOS or Android operating systems.

While our concern today might be with the iPhone X or Pixel 3, this target will change over time. It is important to not only keep up with expectations by the device vendor, but also to ensure that the app brand does not take second place to the demands that device platforms put on it.

Every app has its own character that is above and beyond the platform(s) where it is found. Keeping the app true to its own identity supersedes device requirements, but ignoring the impact that devices have on app design might keep your app’s identity while distancing it from potential users.

Whether you choose to design and develop a native mobile app for either iOS or Android, or whether you choose to design and develop a cross-platform app for both iOS and Android, you need to pull together a design checklist for how you will approach mobile app development.

Designing full-stack mobile apps

Designing full-stack mobile apps