We often get asked about iOS versus Android and why you would need separate development and design for each. I’m not going to get into why you would develop for iOS over Android or visa versa, but I would like to explain just a few of the main differences so that the situation is hopefully a little more clear. Also, to be clear, this post is referring to native development. Without going too far down the native vs web vs interpreted/cross-platform solutions (i.e. Xamarin, etc.) rabbit hole, web doesn’t always provide the user experience you or your users are expecting. Interpreted or cross-platform solutions tend not to save much – if any – time/cost and sometimes take more time because of working around quirks in those systems. I also will not be getting into comparing all of the various market places for iOS and Android applications.

At MotionMobs we all believe very firmly in taking pride in our work and in having the best possible end user experience. We can’t always make it perfect, but we go above and beyond to get it as close as possible, and always make trade-offs with the user’s experience in mind. We believe this is the best way to make the best product which, in the end, will have the best chance of making an impact on the market! There are two sides to user experience, design and development. You obviously want the design to be attractive, but also intuitive to the user. Then in development, you have to make sure that you are not only fully bringing the designer’s vision to life, but also making the application respond and react in the way the user is expecting. Great user experience means not only meeting the user’s expectations but exceeding them.

Design

Let’s start at the beginning of the user experience. In the user’s first use of their shiny smart device they will be learning about the operating system, or OS, that is embedded in that device. In the case of an Apple product it will be iOS and in the case of an Android device it will be the Android OS. As the user interacts with the device they learn the OS’s way of doing things, where to expect things to be, how things should react, and how everything flows together. These interactions become expectations on not only the OS but all the applications on the device. If the user presses the Back button they expect the OS or app to go back. If they press the home button, they expect for the OS to drop back to the launching interface with their pretty background and launcher. If they load an app they expect it to look like it belongs there. On an Android device the app looks like it fits on an Android device and not like an iOS app and visa versa.

This principle of recognizable design and interaction is something that both Apple and Google have full sections of their developer websites dedicated to. These standards are generally called User Interface Guidelines and are EXTREMELY important to the design of any app on these devices. Google even has an on-going blog where they keep developers and designers up-to-date on the platform and talk about the best practices, as well as give some tips and tricks.

Android Action Bar

iOS Navigation Bar

Let’s walk through an example of differences in the two design guidelines, Action Bars (or Tool Bars as well with Android Lollipop) in Android versus Navigation Bars in iOS. Both are completely optional; however, both should keep the user informed with where they are in the application as well as giving the user a quick, recognizable method of navigating through the app. Keep in mind that iOS devices don’t have a built-in Back button on the device, so in order to have a way to go back you have to program it in, and a Navigation Bar is a fantastic place to put a back button if it fits with your design. On the other hand, the Action Bar has a built-in “Up” functionality (the caret indicated by the “1” in the example above) which is the Android way of doing the same thing, or the user can just hit their hardware/embedded Back button (which will always be there and should always function in this way).

Another attribute both have is that they can contain dropdown selections (i.e. “2” in the image above), buttons, labels and/or search fields. However, both guidelines are fairly stern about how these are used and laid out. One huge difference between the two is that Navigation Bars are only meant to have a very limited selection of navigation embedded in them. Past that, as a designer, you are to turn to some sort of container, be it a drawer, a pop-over, a dropdown, or something new, but all will have to be created and designed. In addition, this all has to be made to fit within each device’s screen layout (iPhone 5 vs iPhone 6 vs iPad, etc).

Conversely, the Action Bar allows any number of “Action Items” which are essentially buttons that can display as either labels or icons (the “3” above indicates the shown Action Items). Android has been built from the ground up with responsive design in mind and this is reflected in just about every aspect of the operating system. In this case, you see it in the fact that no matter how many Action Items the Action Bar has, it will only show the ones that fit and are appropriate to show (toward which the designer/developer can give hints). All of the overflow Action Items are auto-magically put into a dropdown list that is accessed through the menu button that appears at the end of the Action Bar (the “4” above indicates this menu button). No matter how big or small the device, this will all look how it is supposed to without much, if any extra work. This is just one of the more simple examples of designing Android versus iOS applications.

Development

When it comes to the development of these applications the difference becomes even more severe. Without getting too far into the world of programming languages and computer science, when you program anything you generally don’t use the raw binary format that the device actually reads unless you have no other choice. Instead you use what’s called a programming language which is then either interpreted at runtime or compiled into the binary format that the device actually reads and understands.

In the iOS world we have Objective-C and now Swift that we code, and in the Android world you generally code in Java (unless you are getting in to it with C++ and JNI). Yes, you can use C++ in both platforms and when you write a cross-platform library that is performance dependent you tend to, however, there is a LOT of boilerplate code on both sides, and you generally don’t do any of the standard user interface graphics in C++ (or Objective-C++ as it really is on the iOS side). C++ is generally only useful when writing an OpenGL ES game, another hardware-dependent application or writing a performance dependent library. Therefore, I won’t be talking about it. As a way to give you an idea of the differences, here are some simple code snippets that at runtime simply display an error message to the user and require interaction to dismiss them via an “OK” button:

Objective-C:

 

[[[UIAlertView alloc] initWithTitle:@"Error" message:@"Please enter a name" delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil] show];

 

Swift:

 

let alert = UIAlertController(title: "Error", message: "Please enter a name",
        preferredStyle: UIAlertControllerStyle.Alert)
alert.addAction(UIAlertAction(title: "OK", style: UIAlertActionStyle.Default,
        handler: nil))
self.presentViewController(alert, animated: true, completion: nil)

 

Java:

 

new AlertDialog.Builder(context)
    .setTitle("Error")
    .setMessage("Please enter a name!")
    .setNegativeButton("OK", new DialogInterface.OnClickListener() {
        @Override
        public void onClick(DialogInterface dialogInterface, int i) {
            dialogInterface.cancel();
        }
    }).create()
    .show();

Even with this simple example, there is room to differ even more between the platforms. On Android it may be more appropriate to use what’s called a “Toast” to display this message to the user. This is a message that gets shown for either a “short” or “long” amount of time and doesn’t require any user interaction before it dismisses itself. The code for it would look like this:

 

Toast.makeText(context,"Please enter a name!",Toast.LENGTH_SHORT).show();

Android Toast

 

You can do something similar on iOS, but it’s not built-in and requires a third-party library or for you to write the functionality yourself. This introduces another HUGE difference between the two platforms: the Software Development Kit, or SDK. The SDK is the collection of tools and libraries that you get “for free” to develop with. This is where you get all of your core functionality as well as any functionality that Google or Apple thought would help developers push their platforms in the directions they see them going (i.e. Google Play Services, Apple’s HeathKit, etc). The SDK normally has all of the functionality you need to have, but if you write applications long enough you are going to come to a point where you want to use someone else’s code or library.

With iOS you have several ways of using third party code/libraries, but the two most popular options are a third party system called CocoaPods or simply downloading and adding the code to your project yourself. On the Android side you can just include the code as well, however, the Android Studio build system uses a system called Maven that makes it so that all you have to do, if the library supports it, is add a line to your build script like this:

 

compile 'io.realm:realm-android:0.73.1'

With this, the build system will automatically download the ‘0.73.1’ version of the Realm-Android library, compile it if needed, and include it into your project for use.

The build system of Android Studios may be one of my favorite features in it. In short, Xcode and Android Studios are Integrated Development Environments, or IDEs, that were shaped to help developers be as efficient as possible in creating apps for their platforms. While both have pros and cons, one feature difference between them that can not go unmentioned is their user interface, or UI, creation tools. As mentioned before, Android was created from the ground up with being responsive to difference devices in mind and has always used a very readable XML format to describe “layouts” or UIs. As such, the editor for this format is excellent, however, the What You See Is What You Get (WYSIWYG) editor for UIs in it is getting better but still isn’t great.

Xcode, on the other hand, which also uses a modified XML format to store UIs, is pretty good at letting you drag and drop an interface together even though there are always snags that you learn to bypass. These have gotten much better with the new AdaptiveLayout functionality, but don’t ever try to write the raw files; it’s not worth it. Also, be warned that AdaptiveLayouts require a minimum version of iOS 8.0 to be available as an option.

In Conclusion

This doesn’t even get into the actual structure of the code, which would be a blog post in and of itself, but hopefully this helps you to see that while there are small crossovers here and there, for the most part, developing for iOS and Android is as different as night and day. If you want the application to perform, look, interact and react the way that the user expects, you are going to need to invest into both. In the end, it’s all about the user’s experience. It’s that user experience that is going to keep the user coming back to your app every time, and user expectations play a large role in that.