Android v. iOS guide for newbies

If you're just starting out in app development and trying to choose between the Android or the iOS SDK, this basic guide might be useful.

In tech years, the iOS vs. Android argument seems like it is half a century old and has stretched the limits of human tolerance for passive-aggressive retorts. Since 2008 the ongoing comparisons between these operating systems have been in the spotlight because of the growing Android market and the possible iOS expectation that everything be done through Apple and with Apple products.

Amidst all of these debates, it can be difficult for anyone starting out in app development to figure out which mobile OS they might enjoy working with more. Here's what you need to know to choose between the Android SDK and the iOS SDK.

Android SDK

The Android SDK is an amalgamation of different tools that allows anyone interested to develop and manage their applications. Some of those tools include:

Tools like The Simple Project and RFO BASIC! provide needed support and training for novices.

Android uses a Java-based language. Eclipse is the common IDE used through the ADT Plugin, which fully supports Android development. Though Eclipse is commonly used, it is still a difficult system for some to learn. The same goes for XML (which adds another layer of complexity when working with the UI), especially if you are used to CSS for design. The NetBeans IDE is another supporting platform that can also be used via a plugin. Developers can use any text editor to edit Java and XML files, which they can pair with command line tools to develop and debug Android apps and control Android devices.

Android has a 70.1% market share (as of the end of 2012), creating a higher demand for the apps. The number of tools at the developer's disposal and the availability of forums and other online support systems prove that Android is geared more toward developers being able to create at will. The downside to this freedom is that the quality varies depending on the app, and the developer has very little to hold him/her accountable to any expectations besides that of the customer.


The iOS SDK is a governed system that is centralized on consistency; the many tools used by this system illustrate this focus. While some of the restrictions regarding cross-platform development have relaxed, the overall inclination for control over the app development process is still pronounced.

Some of the tools used in the iOS SDK are listed below, each covering a specific area that Apple would like included with whatever application is developed.

  • Cocoa Touch
    • Multi-touch events and controls
    • Accelerometer support
    • View hierarchy
    • Camera support
  • Media
    • OpenAL
    • Video playback
    • Image file formats
    • Quartz
    • Core Animation
    • OpenGL ES
  • Core Services
    • Networking
    • Embedded SQLite database
    • Core Location
    • CoreMotion
  • Mac OS X Kernel
    • TCP/IP
    • Sockets
    • Power management
    • File system
    • Security

In addition, the SDK contains the Xcode toolchain and an iPhone Simulator, a program used to simulate the iPhone on the developer's desktop. Core location is also a central framework used in the iOS. The current version is 6.0.

All developers are required to go through the iOS Developer Program (enrollment is $99 USD for the standard class) the first time in order to ensure they meet Apple's standards and have a complete understanding of the systems involved.

Once an app is developed, it can be disturbed three ways: the App store, exclusively internal (for employees etc.), and free distribution for up to 100 iPhones. Each stage goes through levels of review by Apple, which affirms the app's quality and purpose or rejects it. Java and Flash are no longer used by Apple.

Comparing Android and iOS

One of the biggest benefits to developing apps for Apple is the ease of Xcode. Get a MacBook and install it, and suddenly you can begin writing and installing apps. Android isn't that simple.

One of the main differences in developing apps for Apple is interface construction. When working with a fragmented ecosystem such as Android, you have to take into account all the various types of devices that run Android; with iOS, there are only two resolution scales to take into consideration.

Outside of the comparison between these two systems is HTML5, which allows developers to write apps that are more efficient and faster than Flash apps of yesteryear. HTML5 apps have a lot of benefits over native apps, but they should be used with caution for the time being due to their lack of web standards and missing libraries.

Both systems provide tools for development and distribution. Both have markets that are central to whatever the developer would like to provide in the way of applications. Both languages are being adjusted for cross-development platforms.

In conclusion, while Android offers more opportunity, Apple may offer better checks, which assure quality and distribution. Basically, a developer needs to consider which option best suits the application they intend to create and not worry about answering the flawed question of which mobile OS is better.

Also read on TechRepublic


Joseph Parker has worked in management, supply chain metrics, and business/marketing strategy with small and large businesses for more than 10 years. His experience in development is personal, stemming from his work in mobile marketing and applicatio...


This should have been a three-way comparison and included Windows Phone 8 OS. For a Newbie, the Active Tile interface is much easier to use and understand. As for developers, using a unified development platform allows them to reach more users, not to mention, make more money!


I suppose this is an 'ok' article, but there are a few things which are misleading. First, it doesn't even mention the language needed for iOS, and the fact that unless you're already an Apple developer, you've probably never used it before and you'll need to spend some time learning the syntax. Second, the author states you only have to worry about 2 resolutions for iOS. That's only true if talking about icons. If you're talking about screen ratios, then there's 3. If you're talking about screen sizes, then there's 4. If you're talking about pixel counts, then there's 6. Third, the old 'fragmentation' saw that always gets thrown around when talking about Android vs iOS. Yes, there are many more screen sizes & shapes in Android, but it's not really a problem. You could also say that iOS is fragmented also since, as I stated above, you have 6 different screens. Whether it's 6 screens or hundreds of screens, you should never code your app to a specific size. The tools for both platforms provide means to handle different screens and should be used, or you'll get yourself into trouble. And what is the difference between this and desktop 'fragmentation'? How many monitor sizes do Apple have? Does this 'fragmentation' make it impossible to develop apps for Mac OSX? We've been dealing with this 'problem' since the dawn of the GUI, and it's easily solvable. The only reason this is ever mentioned was because for a very short time (when there was only 1 screen for the iPhone and the iPad wasn't released yet) the developer had a guarantee of pixels. And everyone who coded to that guarantee got bitten when the iPad was released and had to rewrite iPad-specific apps, doubling their support and maintenance costs. So to me, 'fragmentation' keeps developers from painting themselves into a corner and forces them to be screen-agnostic (as they should be). This is a good thing. Next, the whole section on HTML5 smells. How can you say that a standard (which HTML5 is) lacks web standards? It IS a web standard. The problem is with developing specs which are not included into the standard yet, and with platforms not supplying the standards. Also, the comparison to Flash is wrong. On what do you base your statement about performance on? And what part of HTML5 is faster? Video rendering? 3D transforms? Fibonacci factoring? Both are very large platforms and you can't make blanket statements like that. It's like saying Mac OSX is 'faster' than Windows. It depends on the implementations and what you are trying to achieve. Finally, your last paragraph. I'll give you that you can interpret that the Apple gauntlet you need to run though can result in your app being of 'higher quality' (of which there is no proof of this correlation being the cause) but distribution? I don't see how when (as you stated yourself) Apple has fewer customers and no guarantee of inclusion into the marketplace. A better way to determine which platform to develop on (if you only plan on doing 1) should be the following criteria: 1. Do you have access to the tools needed (you need a Mac for XCode). 2. Do you have any knowledge of the language (do you already know Java? ObjectiveC?) 3. Which platform do you already own? 4. Are there similar apps already on in the marketplace? How much competition will there be? 5. How do you plan on marketing the app? Which platform is easier for you to reach your potential customers? 6. Which countries do you plan on distributing to? Does the marketplace exist for that platform there? 7. Does it need to be a native app? Can you do it as a web app using responsive design (and therefor support all modern mobile platforms) instead? 8. Do you plan on making money? If so, how will you get paid (paid app, advertising, other)? Which platform will allow you to meet your revenue goals? 9. Are you OK with Apple's controls? Or do you want the relative freedom of Android?


"Get a MacBook and install it, and suddenly you can begin writing and installing apps...." OK. If you have $1500 to spend to buy a MacBook. What does it cost to develop Android apps? If the issue is still there, apple still does not allow cross-platform compilers. Regarding "you have to take into account all the various types of devices...." So I guess you assume that programmers are lazy or just want to take the easy way out?

Chaz Chance#
Chaz Chance#

I had by first Android app in a package, and the package installed on my tablet, just two hours after I wondered how hard it would be to develop for Android. And I hadn't paid a thing. Granted it didn't do very much, but hey, it answered my question. I am not the world's best java programmer, but I found that Android/Eclipse makes everything easy, because everything I could think to do is already built into the OS. All I had to do is call it, and it just worked. Multi-touch, GPS, file handling, graphics, it's all in there. If Xcode is easier than that, then color me impressed!

HAL 9000
HAL 9000

Absolutely no mention of Blackberry 10. That should also have been included if they need to include Windows Phone 8. ;) Col


Bill, Thank you for the comment! The purpose of my article was to give an overview of the differences between the platforms and go into the needed detail to explain said differences. As the length of your comment shows, it’s often difficult to include everything one would like to say about a particular topic within the parameters of a blog post. Also, the points you gave at the end of your comment is a wonderful checklist for every developer in the preliminary stages of app ideation. Often those considerations come before one would dive into developing the app, and are often considered on a case-by-case basis depending on what a person is trying to do. Thanks again for your comment and for the details you provided!

Chaz Chance#
Chaz Chance#

Bill Hannah, YOU should have this comment published as a full article. You would do a better job writing an impartial, properly researched, intelligent comparison between the two platforms. You might halt the falling standard of so-called technical articles that has been the cause of me visiting less and less???

Editor's Picks