Android vs. iOS: UI/UX Differences


Create application that supports both platforms (iOS and Android) and has a similar functionality optimized for interaction design principles and users expectations unique to each platform.


The important thing to keep in mind is that iOS and Android environments are based on unique for each platform guidelines, user interaction architecture and design patterns. There is a number of iOS and Android similarities in look and behavior of various UI components like

  • information structure;
  • basic UI elements (sliders, checkboxes, tabs, text boxes, fields etc.);
  • list-based navigation;
  • majority of gesture touch controls (excluding “tap and hold” gesture, which is commonly used to reveal contextual bar with options or enter a data selection mode).

However the number of differences is worth paying attention to. Below you may find a short overview of the core design peculiarities that should help better understand differences in the design approach for both Android and iOS.

1. “Back” navigation.

In iOS applications “back” option is placed in the upper-left corner of the navigation bar. It is used to navigate backward within the defined screens in the application however it is not used to navigate backward across the entire device.

In Android devices there are two types of “back” actions: “up and “back”. “Up” is placed in the upper-left corner of the top bar and is used to navigate up the application’s information hierarchy. In contrast, “back” option is presented as a button on the physical device that allows navigating backward across the entire device.

Back navigation

Back navigation in GMail for Android and Dropbox for iOS

2. Top navigation.

In iOS applications tab navigation is placed at the bottom of the screen. In addition, according to iOS guidelines there are no more than 5 tabs displayed at a time.

In Android applications tabs are recommended to be placed at the top of the screen. Besides scrollable tabs are allowed to be used in case there are more tabs than can fit in the viewable screen width.

Top navigation

Top navigation in Google Play and Dropbox for iOS

3. Switching between various data views.

In iOS applications switching between views of the single set of data is typically done through the bar divided into segments.  Each segment is responsible for one view.

In Android applications switching between views is done through the UI control “spinner”. This control is presented like a drop-down list of options. “Spinner” is usually placed at the top action bar.

Switching between various data views

Switching between data views in Google Calendar for Android and iOS Calendar

4. Search.

In iOS applications the searching UI control is placed at the top of the screen mainly.

In Android applications several searching options are available:

  • “search bar” at the top of the screen that is similar to the iOS approach. However the bar is hidden until the user clicks on the search icon;
  • “search widget” that can be placed anywhere within the application interface. Coomonly it is used within the application’s action bar at the top of the screen.


Search in Google Play and Foursquare for iOS

5. Actions.

In iOS applications can be accessed through the toolbar that contains action buttons, through the action button that is in the upper-right corner hand side of the navigation bar or through the buttons within the interface screen.

In Android applications it is recommended to display actions in the action bar at the top of the screen. If there is any need in displaying more actions than can fit on the action bar, either an action overflow icon appears on the action bar for devices that don’t have a hardware “menu” button, or the user accesses additional actions by pressing a hardware “menu” button on devices where there is one. Android applications may also use contextual action bar. A contextual action bar is a temporary action bar that overlay the app’s action bar for the duration of a particular sub-task.


Actions in GMail for Android and GMail for iOS

6. Screen sizes and resolutions.

iOS phones, for instance, come in two screen sizes and three resolutions (including the latest ).

Android devices are represented by a lager list of screen sizes and screen resolutions. This issue has a significant impact on the layout while designing the application.


It may appear as the straightforward idea to create one application for both platforms however important issue to consider is that interface elements of both platforms are not the same.

Though application’s core features and functionality may be the same on both platforms application’s interface should follow specific for each platform guidelines. Therefore to meet user expectations and ensure smooth user experience application’s design should be adapted to the unique platform design patterns and respect native UI standards.

Have a question?

Speak to an expert

4 responses to “Google Glass Development Without Glass”

  1. luislukas says:

    Hi Ostap!
    I´d like to thank you about this post, I think it´s and extremely effort first to understand the technology and second to share it with the community.
    I´d like though to ask you a couple of questions. After installing following the steps in the Xenologer process, I can get into google glass in my mobile.
    However, when I try to execute your github code in eclipse and run it in the mobile, I get a dalvik conversion error followed by java heap space error.
    I´m compiling and executing the project with the google glass SDK preview and target is 15.
    I´ve also created another project where I´m suppose to create a Live Card. The error I´m getting is NoClassDefFoundError :

    Any help will be welcome,


  2. Hi luislukas!
    Thanks for the response.

    >>I´m compiling and executing the project with the google glass SDK preview
    If you want to run any code on it, you should compile with Android API 15 Runtime, not GDK Sneak Peak Runtime.

    >>I´m suppose to create a Live Card…
    >>I´m getting is NoClassDefFoundError…
    As I have mentioned in “3. Example #2: GDK Update”, you’ll get [INSTALL_FAILED_MISSING_SHARED_LIBRARY] exception or similar, when running GDK examples on Nexus Glass: no support for GDK features (auth, livecards,etc).

    Unfortunately, Xenologger APK are based on XE6-7. GDK Sneak Peak was released, when people were using XE11 version of Glass. So, there’s no shared library with GDK support.
    That’s why Nexus Glass doesn’t work with GDK Sneak Peak.

    GDK Sneak Peak is still very limited. AFAIK, you can’t post a static card from GDK to Timeline now.
    Google said, they’ll be opening new GDK features in following GDK releases.


  3. Great article, thanks!

  4. Thanks, that’s really fantastic to develop without the glass. I was thinking about the emulator but now I came to understand there is an option to develop an app using Mirror API

Leave a Reply

Your email address will not be published. Required fields are marked *