Cost Benefits vs Sacrifices in Cross-Platform App Design

Aug 7, 2015

Ok, so there are a thousand articles out there doing a Pros/Cons analysis of cross-platform applications (including ones written by us here and here). At Sourcetoad, we used to do both, but we’ve since focused solely on specializing in the cross-platform application development side. But today what I’d like to dive into is the approach to designing an application to run on two or more platforms (eg iOS and Android) when it comes to budget and time.

Really good design is device focused. What I mean by this is that users expect their apps to follow the analogies and metaphors of interaction that are unique to their platform. For example, iOS applications frequently have a row of buttons along the bottom of the screen to access various areas of the app. Android often has a physical “options” button that pressing will pop up an overlaid menu of extra items. These might not seem like huge differences, but for a long time it has been claimed that if you deviate from the native metaphors, users will be confused.

The solution, for cross-platform developers, has been to build separate interfaces for each platform, if it isn’t cost prohibitive to do. But herein lies the dilemma: If you are going to really take advantage of cross-platform development’s costs savings, you want to obviously use the same user interface across all your devices. That is to say, that your Android application will look exactly the same as your iOS device. And this flies in the face of the above mentioned “Good design is device focused.”

There are times when I agree that there is no way around this. Maybe you’re still going to get 30-40% cost savings across platforms if you stick with the cross-platform method and write separate interfaces for separate devices. But you’re not going to get the 60-80% cost savings of doing the same (vs going native). When we talk costs that large, its understandable why you are still finding lots of applications that share an interface across platforms. I think the main reason that you’re now seeing the “hamburger” menu these days is because it’s a menu metaphor that is becoming universally understood although there are arguments for not using them. Universality translates to cheaper in terms of cost.

There are tools out there that allow one code base to have two, mostly-automated, separate views. We use a lot of Ionic here at Sourcetoad, and it supports some out-of-the-box styling for Android vs iOS apps. There are things like Chocolatechip UI  which will do similar things regardless of framework, but none are perfect.

But I think there is a better way: Just design something better.
Ok, a bold statement. And yes, I understand that not every app should be beautiful and original. Often times you want to build something that is functional and familiar. But let me show you some things that I like.

First up, the Rate Whiskey app that Sourcetoad is busy redesigning (yes, yes I know we’re showing off a little.) Which platform do you think this would feel more natural on? I argue that it would look great on any screen.

whiskey-login  whiskey-profile

Next up are two of the most beautiful apps I’ve seen in a while. Overcast and Litely.

litely  Overcast

What’s great about these apps is you don’t care what system they’re built for. You don’t care how they were built. They just work. And they’re beautiful. And that should be good enough.

RECENT POSTS

The Agile Manifesto in Practice: Part 1

The Agile Manifesto in Practice: Part 1

  How Sourcetoad Values People Over Process The software development process can involve a lot of uncertainty for both development teams and clients alike, especially in the early phases of a project. How can the long-term vision of an application be balanced...

What to Consider When Building HIPAA-Compliant Software

What to Consider When Building HIPAA-Compliant Software

In 1999, the Department of Health and Human Services (HHS) passed the Health Insurance Portability and Accountability Act (HIPAA) as a measure to protect personal health information (PHI) and allow people control of their healthcare records. The HITECH Act was enacted...

The Evolution of Buy Now, Pay Later in eCommerce: Part 2

The Evolution of Buy Now, Pay Later in eCommerce: Part 2

In Part 1, we talked about the rapid growth of Buy Now, Pay Later (BNPL) and discussed its expansion across industries. In Part 2, we will consider how impending regulation may shake up the short-term lending space.   Impending Regulation of BNPL While consumers...