Responsive web design enables people to create websites and web apps that work on any number of devices, but there’s often an assumption that the skills needed to create and design a web app can be directly translated to native applications.
Rather than offer a cost-benefit analysis, this post will breakdown the differences between native design (e.g. iOS, Android, and macOS) and designing responsive websites or Progressive Web Apps (PWAs).
Interface Guidelines
While responsive design guidelines are not strict–there are web standards and accessibility guidelines–each native app platform has more stringent parameters that creators must comply with. Apple is particularly strict about their guidelines and often turns down apps from the App Store for this reason.
The web and–to a degree–Android are open sandboxes that allow creators to do whatever they want with any number of technologies. Conversely, guidelines for native applications are in place to ensure consistent experiences, usability, and interactions across applications (e.g. gestures and flows), and help maintain a level of quality for the OS. The guidelines for native design are vast and complex, with more and more considerations or platforms added every year.
To create the highest quality apps, designers must ensure they are up to date with the latest guidelines while being able to develop new and interesting patterns for their clients.
Motion
Where the web is primarily a static medium, with less fluidity moving between screens and traversing an interface, native applications are typically designed with motion in mind. Open up any app on your phone and you’ll soon experience subtle transitions when you tap an icon or slide between two tabs—dig further and you’ll find more elaborate animation.
Each operating system has different standards for animation. What feels at home on iOS may not feel right on Android which, in turn, may not feel right for a web app. The knowledge of which animation to use and where requires experience in the platforms as well as knowledge of how to create and communicate this animation to engineers (e.g. using After Effects, Principle, or Figma). To make handovers smooth, consider pairing with an engineer to work on these animations together.
Motion definitely exists in responsive web design, but not to the degree that it needs to exist in native design. This is a big hurdle for people moving towards native design—a motion designer needs to understand what is possible, find a way to communicate the desired motion, and provide it to an engineer who is able to make it a reality.
Interactions
Creating a consistent interaction experience across web apps and native apps is challenging. The ways a user traverses through an application on each OS or on the web are all unique. Knowing the differences between these and when to use them is essential for making an app feel native to the device you’re using.
As an iOS user, I’m used to swiping to find more options and tapping the top left of the screen to go back to the previous view. These schemas are different on Android where a long press is more common and there is a persistent back button on the bottom left of the screen. On the web, we have many types of inputs to consider: keyboard and mouse, keyboard-only, touch, or other inputs like eye-tracking.
Having knowledge of which interactions to use and how to disclose them requires experience and sensitivity to design.
Notifications, Alerts, Banners, and Other System UI
System-wide notifications, alerts, banners, and other system UI are uncommon on the web outside of built-in browser alerts for certain websites.
When designing a native application, we must create different views, help communicate what this element says, define when they trigger, and more. Notifications are on the easier part of the spectrum, whereas things like action sheets, pull-down banners, and widgets make designing a native app more complex.
Ethics for System UI
As a society, we’re becoming more and more addicted to our mobile devices. Some companies manipulate people’s behavior through dark patterns to increase engagement, keep users on their devices by triggering a notification at a specific point, or use emotive language to get a user to open up an app.
Creators need to understand the psychology behind what they are doing and create apps in an ethical, responsible manner. We need to meet business needs, but also be aware of the impact of the decisions or trade-offs we make.
DPI, Screen Size, Handoff, and QA
For the web, we barely need to consider pixel density. Our tools do the heavy lifting by enabling us to design @1x and exporting at any scale our engineers might need to use (e.g. @2x, @4x, or SVG).
For native apps, this is a fragmented process. The number of screen sizes and pixel densities for Android is huge, the number of Apple devices is growing, and native applications on things like Apple TV, smart TVs, and even smart refrigerators is making this more complex.
Fortunately, the tools for handing off design and motion work for web and native design are making this less challenging, but that’s before we hit the QA process.
There are thousands of devices on the market, each with a different screen size and a different operating system. Some are connected to hyper-fast WiFi while others are barely getting 2G or 3G speeds. The QA team must emulate these scenarios, reproduce bugs, and get them fixed. Doing this effectively is time-consuming and expensive–that’s a lot of devices to buy.
User Research
User research for websites is pretty simple. In-person sessions allow for a computer setup with screen sharing turned on and cameras in the room so spectators can take notes. In remote sessions, we just send the person a link to a video chat and share the prototype with them.
For native applications, researchers and recruiters must be more versatile. In person, we can give a participant a device to use, but there’s a challenge in making sure spectators can see the device. It’s not always as simple as connecting the device to a screen or projector; this might mean a camera pointing down at a phone and having the participant hold the device in a very specific area.
Remote research is tough because we need to make sure the user has a compatible device, that they can share their screen, and make sure they have the right profiles to download the application (when using iOS).
Store Approval
The timeline for getting an application approved by Apple is a big unknown. It can take anywhere from a few days to a few weeks. And, in a lot of cases, the application will be denied. A designer should work closely with a product manager or product owner to ensure the app meets the required criteria for approval and help make the process as efficient as possible.
Responsive vs. Native Design
Comparing design to engineering, people who use React and people who use Vue are developing in the same language, but they wouldn’t be able to apply all the same rules of one framework to the other. Engineers need to know the rules, nuances, methods, and patterns of different languages and frameworks to use them well. It’s the same when it comes to designing for different platforms.
With time, mentorship, education, and experience, most teams can become versatile enough to produce excellent apps for web and native platforms.
DockYard is a digital product agency offering custom software, mobile, and web application development consulting. We provide exceptional professional services in strategy, user experience, design, and full stack engineering using Ember.js, React.js, Ruby, and Elixir. With a nationwide staff, we’ve got consultants in key markets across the United States, including San Francisco, Los Angeles, Denver, Chicago, Austin, New York, and Boston.
