10

“A design that merges iOS and Android”

5 years ago from , Interface designer at Mono

As designers, we are often asked to design cross-platform apps.

However, the design systems behind iOS and Android are vastly different.

Small examples include the way that indicators are treated on table views (the chevron on the right side); or small touches on tab bars (on Android, the label is only supposed to be shown on the active item).

Larger is the way movement is depicted. Android has a concept of transitioning elements from screen to screen. iOS has relatively strict view hierarchies and the animations are mostly on the full view.

If you try to explain these differences in a client meeting, the client will probably acknowledge them, then start talking about budget and in the end you have to deal with the problem anyway.

I have been exploring React Native (from the design side) which allows you to more easily build custom cross-platform interfaces (versus starting a native Android and iOS app from scratch).

However, in a custom UI you still have to decide which combination you make between iOS and Android.

Any thoughts? How do you deal with this problem?

6 comments

  • Ben RamseyBen Ramsey, 5 years ago

    Been on my mind a lot lately. Distinguishing between the core of a design system vs the unique patterns and components.

    Similar to the latest material.io, Huddle by Uniform offers source code for multliple platforms across web/react native/iOS/android: http://uniform.hudl.com/

    I haven't had the luxury of designing a system across all platforms (web/android/iOS) at the same time until recently, so still figuring much of this out as I go. When it comes to sticking with native platform patterns vs. pure consistency of a system, I tend to prioritize based on risk.

    As an oversimplified example, navigation consistency with a platform is more critical than a table view that behaves the exact same.

    In general—Material Guidelines feel more specific vs Apple HIG to me. Designers are changing the way we work (systems,) and meeting user expectations is critical, but defining when you can bend those expectations to create beautiful, custom brand experiences will become more key, depending on the type of the project / audience / goals / etc.

    2 points
  • Andrew C, 5 years ago

    We just design for both systems. Since the patterns are pretty well established translating designs across platforms is pretty simple.

    2 points
    • Johan Ronsse, 5 years ago

      Do the apps get developed natively for each platform then?

      0 points
      • Suganth SSuganth S, 5 years ago

        React Native is still part Native. Your design system/product design can exist separately without worrying about that.

        Reason being React still powers your product and features but your platform engineers can define different components that don't have to necessarily look the same. The functionality needs to be pretty much same though, in order to move fast.

        0 points
        • Andrew C, 5 years ago

          Yeah. We've been exploring React Native but there was mixed sentiment after investigating. I'd be surprised if we didn't go with it, tbh (since our web stuff is all React and great).

          Johan: Yes, we develop native. Nothing seems faster or easier than just having the talent sitting in engineering.

          0 points
  • Wouter RamakerWouter Ramaker, 5 years ago

    We're currently developing an app with React (both JS and Native) that will have the same design for both platforms and web. Reason being a shorter time to live (ship fast). It'll help us determine quickly if the concept is a succes or not (fail fast). If it is a relative succes, we'll be able to work on custom views for the native versions, with all the main logic remaining shared across all platforms.

    0 points