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.
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.