Do you have a favorite department store that you know so well you could navigate to the right section with your eyes closed? Have you ever visited that same store, in a different location, and felt lost or confused? It’s like stepping into an alternate dimension where everything is a bit off. 

This is how it feels to use a smartphone app that wasn’t designed with the platform in mind. 

When developing an app for Android and iOS platforms, the term “parity” is thrown around a lot. The belief is that the experience on one platform should be the same as on the other. 

Imagine if someone who frequently uses an iPhone app decides to download it on an Android tablet and is now confused about how to use it. One concern could be that this user would see a table view without chevrons pointing to the right and think, “Well, I guess these aren’t selectable.” 

After toggling features with a tab bar for weeks, the user is presented with a hamburger menu and doesn’t know what to do. In reality, this would never happen.

Dual-wielding users

A user that owns both iOS and Android devices is familiar with the native interfaces of each platform, and would more likely notice when an app doesn’t follow the standard conventions of its platform. 

Little things, like menu navigation, become second nature when using a Pixel phone or an iPad on a regular basis. A navigation bar with a “< Back” button wouldn’t register for an iOS user, but would instantly stand out on Android. 

These inconsistencies with the platform, ironically created in the interest of consistency between apps, show that the platform wasn’t considered during development. 

More often than not, Android users are the ones left with a sense of neglect, even though they make up a large majority of the market share for smart devices. In the end, parity can hurt the brand more often than it can help.

Consulting the counterpart

Parity discussions can cause confusion well before apps begin the design phase. A mobile developer must be careful to never declare that a feature is easy to implement without first consulting the counterpart. For example,

• Menu Navigation & Workflow: bottom placement and better access to hidden items (iOS) vs. hamburger type with left-side placement (Android).
• Notifications: two-step alerts and action sheets (iOS) vs. one-step cancellation actions (Android).
• Back Button Navigation: go back hierarchically through the app (iOS) vs. using a physical back button (Android)
• Native Styling and Best Platform Practices

 The composition of views and workflow can be very different between the two platforms.

Saving time and effort

Not only does sticking to the native styling of the platform make an app feel more natural, but it can also save a lot of development time. The tools and frameworks created for application development offer easy solutions for implementing user interaction the way the platform designers had intended.

The SwiftUI (created for iOS) provides a NavigationController which automatically handles the presentation and dismissal of views. The view title is in the center of the navigation bar and the back button text automatically populates based on the title of the view that came before it. 

This textual representation of the previous view is discouraged on Android because navigation bar titles are typically left-aligned. Building custom navigation views with centered titles and dynamically generating text (made to look like an iPhone app) is both time-consuming and unnecessary. 

Inversely, Android native styling is designed for showing depth for emphasis while iOS maintains a flattened look. Subviews on Android have “elevation” which creates shadows. Some widgets naturally have shadows, possessing a default elevation, while others need only a single property value change to cast a dark haze below it. 

To achieve the same look on iOS, every subview must be referenced in a ViewController and several lines of code must run to add and modify a shadow layer. If you want curved edges and a shadow, a developer will need to add a containing view for rounding corners, a subview for applying shadows, and yet another view to display the actual content. 

You can imagine how laborious populating a view with several shadows can be not just for the developer, but also for an iPhone’s memory for rendering them.

Business sense

Choosing to use platform-specific coding language and other standard tools means that your app will receive all of the support enhancements provided by the platform. This translates directly into faster app performance and higher graphical performance.

In the long run, app parity can cost much more than you might anticipate because of the needs that will arise around supporting a complex app. Technology is continuously evolving and you might be surprised by the cost to keep up with it. 

If you require strong usability and functionality for your app, definitely consider separate apps for iOS and Android. This is the best way to avoid the headaches of functionality and compatibility issues associated with app parity. 

Moderation

All this being said, app parity can be a good thing in moderation. Common image styling and placement are important between apps. Making sure that any copy changes made are applied to both apps can ensure messages are clear, as the verbiage is always the same. 

Basic UX choices, such as menu items and navigation workflow, should also match even when the user interactions may differ. Sometimes, adding a new feature to a framework on one platform will be more work than on another. The benefits of having the same feature on both platforms (often) outweigh the added effort. 

Ultimately, when feature work is flagged as difficult or unconventional for a single platform, a couple of questions should be raised:

1. Does the value added for this extra work outweigh the time and effort required?
2. Will the extra effort on this platform confuse or alienate the user?

More often than not, keeping the apps different in minor ways for a more native experience is in everyone’s best interest.

If you are in the market for a new or updated mobile app, our developers can help you navigate the field to decide what’s right for your organization. Send us the details to get started.