Welcome!
Most of the comparisons between Android and iOS are in the end user's point of view. This is just a small step towards comparing the SmartPhone Giants in a developer's perspective.
Usually the comparison is done in a Table. But I'm not a big fan of that. I'll just go by TextViews and UILabels. (@me: is it a joke?)
Android is developed by Google and OHA(?). OHA is abbreviation for Open Handset Alliance. It's a consortium of 84 companies which includes Mobile Operators, Software Companies, Commercialization Companies, Semiconductor Companies and Handset Manufacturers.
iOS is developed by Apple alone. OMG! Is it 84 Vs 1? But don't judge now.
Android, started it's first public beta on Nov 5, 2007. After that Android has 9 major releases and each one is named after desserts(Oh! Sweeeeeet!). It is one the Operating Systems which rolls out frequent stable releases. The upcoming version, nicknamed as "L", is in developer preview now.
On the other hand, iOS, started it's journey on Jun 29, 2007(@android: I'm older than you, buddy!). They kinda following a pattern here. They are, mostly, releasing major versions yearly once at WWDC. Apple just calls the versions by its version codes. It is really bugging me that Apple names the OS X versions after the Big Cats and California Landmarks whereas for iOS, it's all numbers. The upcoming version iOS 8 is in beta now.
But this is nothing to do with an App developer. The concern is how much the Versions are fragmented. A Picture tells more than words.
If you see, the adoption rate is too high in iOS compared to Android. This is because most of the Android phones doesn't have the upgrade support. And sometimes when the Google does a major revamp(Ice Cream Sandwich), the upgrade goes incompatible to most of the phones.
The development effort is directly proportional to the number of versions you target
If you develop an iOS App, you just target it from iOS 6 to reach 99% users approx. But in Android, still v2.3 devices contribute 13.5%. And latest Kitkat contributes only 18%.
Anyway, for backward compatibility, Android rolls out "Compatibility Libraries" to bring the new features into the older versions. These Libraries are frequently updated as the new features comes in. Kudos Google! Good for You!
It's the biggest concern for any Android developer. Android phones comes with all possible screen sizes and varying screen densities. If you are not careful and thought-through while designing XML layouts, you'll wind up with UI issue fixes unimaginably. True Story!
Patience! To ease out, Android splits all the screen sizes into categories or let's say buckets. Each screen size will fall into any one of these buckets. The buckets are called, small, normal, large, xlarge or else you can use the new qualifiers introduced in Android 3.2 sw<N>dp, w<N>dp, h<N>dp. Read more about supporting multiple screens. The Tablets fall in the xlarge, sw600dp and sw720dp buckets.
iOS is powering only 3 screen size variations(as of now!): iPad, iPhone/iPod touch 3.5'' and iPhone/iPod touch 4''
The development effort is directly proportional to the number screen sizes you target
In iOS, it's easy to target 3 screen sizes. Even if you have any issues, you can just hard-code and fix it.(BTW, this is strongly discouraged). And above all, XCode's Drag-n-Drop support is amazing. The new Unified Storyboard frees the burden of developers by promising that a single design can suit all screens.
But when it comes to Android, the UI should be designed in such a way that accommodates all screens. In the area of Drag-n-Drop, Android is still way behind iOS. The newbie Android Studio exhibits some hope on this. Hence, while designing XML Layouts, try to avoid hard-coded width and height values if possible. Instead use wrap_content, match_parent and layout_wieght.
To address this problem, from HoneyComb, Android brought Fragments -> What you doing ;). A Fragment is a portion of the screen which you can design and maintain separately from the Activities. Believe me. It's POWERFUL.
Screen Density is nothing but the quantity of pixels within a physical area of the screen; usually referred to as dpi (dots per inch).
Android groups all actual screen densities into four generalized densities: low, medium, high, and extra high. Later extra extra high and extra extra extra high introduced.
Instead of dealing with Pixels, Android has a special unit called dp(density-independent pixels). Android explains dp as,
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen.
iOS comes with two types of screens only. Retina and Non-Retina.
With Screen Density, the problem is maintaining separate assets, especially Images, for separate densities.
In iOS, append @2x for Retina images. ex: icon.png for normal display and icon@2x.png for Retina display.
In Android, maintain the same name(It is important), but put the images in separate folders. For example if you need a launcher icon/app icon, you need to put the images in following sizes in the respective folders.
36 X 36 in drawable-ldpi
48 X 48 in drawable-mdpi
72 X 72 in drawable-hdpi
96 X 96 in drawable-xhdpi
144 X 144 in drawable-xxhdpi
Anyway in both platforms, the images will be downscaled or upscaled automatically if you don't provide an asset for a specific bucket.
In Android, the Hardware fragmentation is too high to deal with. The options like Front Camera, 3G Support, OpenGL ES Support, Dual SIM, NFC, SD Card, Hardware keyboard, Camera Flash, Auto Foucs and Proximity Sensors are the hot ones which may or may not present.
Apart from this each hardware varies from the very low end model to very high end one. For example if you take processors, it varies device to device and vendor to vendor. It makes the app respond unexpectedly on different devices. And the worst part is, you can not test on all devices. You have to handle this gracefully in your application. Otherwise you can block the user from installing your App if he doesn't have a required feature. These users cannot install your App from Google Play Store. If you don't do either of these you'll wind up with bad ratings and reviews.
In iOS, the Hardware fragmentation is too low compared to Android. Front Camera, 3G support and Retina Display are the hot ones which may or may not present. But in the latest devices all are available except 3G support(Ah! Wifi only iPads and iPods).
Since Android is an Open-Source, different vendors are using it for their smartphones. They have the freedom to modify the OS upto some level. That's why Android looks differently in Samsung, Sony, HTC, Motorola and other phones. So the expected behavior varies across vendors.
For instance, a functionality to capture an image from Camera and display it, will not work on all devices as expected. Here you are left with handling these overheads. Google has to do something about these Vendor Customizations.
iOS is a closed source and it's only for Apple devices. Needs no more to say.
Android gives more freedom to access core level and sensitive APIs ofcourse with some limitations. For example, your app can make SMS or Phone calls unknown to user. You can even access hidden APIs. Once I've invoked a hidden API to block the incoming calls. Android applications can run in the background invisibly. For example, once I've developed a hidden camera, which will record even after you came out of the App.
In Android even the built-in Apps can be replaced with your custom Apps. This freedom and flexibility calls for lot of innovative ideas such App Lockers, SMS Auto Replying, Battery/RAM boosters and a lot more.
iOS enables strict policies when it comes to core level and sensitive APIs. iOS makes sure there is no harm for the users. Even switching between Apps will be animated in such a way to alert the user that he is now in another App.
In iOS, it is clearly defined what you can do and can't do whereas in Android it's a lot confusing.
Android Apps are primarily developed using Java. As you know Java is with us for around two decades and it's one of the best Object Oriented language out there. It is Statically Typed and Garbage Collected.
iOS development is mostly done with Objective C. Objective C is a superset of C in which you can do both OO and non OO programs. It is a dynamically typed language and there is no Garbage Collection. Introduction of ARC(Automatic Reference Counting) made ease the life of iOS developers.
Objective C is a compiled language. Java is both compiled and interpreted language therefore does not offer the same runtime performance as Objective C. But the performance and responsiveness is also dependent on the hardware and the way you code.
Now Apple introduced a new programming language called Swift with the release of iOS 8.
Read more
Android apps are distributed via Google Play Store primarily. But you are free to distribute the APK files via any medium. For instance, Amazon App Store is the next popular one.
If you want to distribute via Google Play Store, you have to buy Google Play Developer account. It costs 25$ and it's for lifetime. 70% of the Profit is for you and remaining 30% is for Google.
When you submit an App in the Google Play Console, nobody will review it and it will get published within 2 to 3 hours.
iOS apps are distributed via App Store and it's the only way to reach global users. You also have Enterprise Account Distribution but that's a different story. The Developer Account costs 99$ per year. 70% of the Profit is for you and remaining 30% is for Apple.
Apple follows a very strict review process. After submitting the App, all the meta details you have provided such as description, screenshots, etc and the functionality will be validated manually which may take 5 to 7 days to get published if passed. Thus maintaining the Quality of the App Store.
Each platform has its uniqueness, limitations and advantages. From this article, iOS may seem developer friendly but that is completely based on the functionality of your App. As we witness, the race continues.
Most of the comparisons between Android and iOS are in the end user's point of view. This is just a small step towards comparing the SmartPhone Giants in a developer's perspective.
Usually the comparison is done in a Table. But I'm not a big fan of that. I'll just go by TextViews and UILabels. (@me: is it a joke?)
Organizations
Android is developed by Google and OHA(?). OHA is abbreviation for Open Handset Alliance. It's a consortium of 84 companies which includes Mobile Operators, Software Companies, Commercialization Companies, Semiconductor Companies and Handset Manufacturers.
iOS is developed by Apple alone. OMG! Is it 84 Vs 1? But don't judge now.
Versions
Android, started it's first public beta on Nov 5, 2007. After that Android has 9 major releases and each one is named after desserts(Oh! Sweeeeeet!). It is one the Operating Systems which rolls out frequent stable releases. The upcoming version, nicknamed as "L", is in developer preview now.
On the other hand, iOS, started it's journey on Jun 29, 2007(@android: I'm older than you, buddy!). They kinda following a pattern here. They are, mostly, releasing major versions yearly once at WWDC. Apple just calls the versions by its version codes. It is really bugging me that Apple names the OS X versions after the Big Cats and California Landmarks whereas for iOS, it's all numbers. The upcoming version iOS 8 is in beta now.
But this is nothing to do with an App developer. The concern is how much the Versions are fragmented. A Picture tells more than words.
If you see, the adoption rate is too high in iOS compared to Android. This is because most of the Android phones doesn't have the upgrade support. And sometimes when the Google does a major revamp(Ice Cream Sandwich), the upgrade goes incompatible to most of the phones.
The development effort is directly proportional to the number of versions you target
If you develop an iOS App, you just target it from iOS 6 to reach 99% users approx. But in Android, still v2.3 devices contribute 13.5%. And latest Kitkat contributes only 18%.
Anyway, for backward compatibility, Android rolls out "Compatibility Libraries" to bring the new features into the older versions. These Libraries are frequently updated as the new features comes in. Kudos Google! Good for You!
Screen Size
It's the biggest concern for any Android developer. Android phones comes with all possible screen sizes and varying screen densities. If you are not careful and thought-through while designing XML layouts, you'll wind up with UI issue fixes unimaginably. True Story!
Patience! To ease out, Android splits all the screen sizes into categories or let's say buckets. Each screen size will fall into any one of these buckets. The buckets are called, small, normal, large, xlarge or else you can use the new qualifiers introduced in Android 3.2 sw<N>dp, w<N>dp, h<N>dp. Read more about supporting multiple screens. The Tablets fall in the xlarge, sw600dp and sw720dp buckets.
iOS is powering only 3 screen size variations(as of now!): iPad, iPhone/iPod touch 3.5'' and iPhone/iPod touch 4''
The development effort is directly proportional to the number screen sizes you target
In iOS, it's easy to target 3 screen sizes. Even if you have any issues, you can just hard-code and fix it.(BTW, this is strongly discouraged). And above all, XCode's Drag-n-Drop support is amazing. The new Unified Storyboard frees the burden of developers by promising that a single design can suit all screens.
But when it comes to Android, the UI should be designed in such a way that accommodates all screens. In the area of Drag-n-Drop, Android is still way behind iOS. The newbie Android Studio exhibits some hope on this. Hence, while designing XML Layouts, try to avoid hard-coded width and height values if possible. Instead use wrap_content, match_parent and layout_wieght.
To address this problem, from HoneyComb, Android brought Fragments -> What you doing ;). A Fragment is a portion of the screen which you can design and maintain separately from the Activities. Believe me. It's POWERFUL.
Screen Density
Screen Density is nothing but the quantity of pixels within a physical area of the screen; usually referred to as dpi (dots per inch).
Android groups all actual screen densities into four generalized densities: low, medium, high, and extra high. Later extra extra high and extra extra extra high introduced.
Instead of dealing with Pixels, Android has a special unit called dp(density-independent pixels). Android explains dp as,
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen.
iOS comes with two types of screens only. Retina and Non-Retina.
With Screen Density, the problem is maintaining separate assets, especially Images, for separate densities.
In iOS, append @2x for Retina images. ex: icon.png for normal display and icon@2x.png for Retina display.
In Android, maintain the same name(It is important), but put the images in separate folders. For example if you need a launcher icon/app icon, you need to put the images in following sizes in the respective folders.
36 X 36 in drawable-ldpi
48 X 48 in drawable-mdpi
72 X 72 in drawable-hdpi
96 X 96 in drawable-xhdpi
144 X 144 in drawable-xxhdpi
Anyway in both platforms, the images will be downscaled or upscaled automatically if you don't provide an asset for a specific bucket.
Hardware:
In Android, the Hardware fragmentation is too high to deal with. The options like Front Camera, 3G Support, OpenGL ES Support, Dual SIM, NFC, SD Card, Hardware keyboard, Camera Flash, Auto Foucs and Proximity Sensors are the hot ones which may or may not present.
Apart from this each hardware varies from the very low end model to very high end one. For example if you take processors, it varies device to device and vendor to vendor. It makes the app respond unexpectedly on different devices. And the worst part is, you can not test on all devices. You have to handle this gracefully in your application. Otherwise you can block the user from installing your App if he doesn't have a required feature. These users cannot install your App from Google Play Store. If you don't do either of these you'll wind up with bad ratings and reviews.
In iOS, the Hardware fragmentation is too low compared to Android. Front Camera, 3G support and Retina Display are the hot ones which may or may not present. But in the latest devices all are available except 3G support(Ah! Wifi only iPads and iPods).
Vendor Customization:
Since Android is an Open-Source, different vendors are using it for their smartphones. They have the freedom to modify the OS upto some level. That's why Android looks differently in Samsung, Sony, HTC, Motorola and other phones. So the expected behavior varies across vendors.
For instance, a functionality to capture an image from Camera and display it, will not work on all devices as expected. Here you are left with handling these overheads. Google has to do something about these Vendor Customizations.
iOS is a closed source and it's only for Apple devices. Needs no more to say.
Platform Limitations:
Android gives more freedom to access core level and sensitive APIs ofcourse with some limitations. For example, your app can make SMS or Phone calls unknown to user. You can even access hidden APIs. Once I've invoked a hidden API to block the incoming calls. Android applications can run in the background invisibly. For example, once I've developed a hidden camera, which will record even after you came out of the App.
In Android even the built-in Apps can be replaced with your custom Apps. This freedom and flexibility calls for lot of innovative ideas such App Lockers, SMS Auto Replying, Battery/RAM boosters and a lot more.
iOS enables strict policies when it comes to core level and sensitive APIs. iOS makes sure there is no harm for the users. Even switching between Apps will be animated in such a way to alert the user that he is now in another App.
In iOS, it is clearly defined what you can do and can't do whereas in Android it's a lot confusing.
Language:
Android Apps are primarily developed using Java. As you know Java is with us for around two decades and it's one of the best Object Oriented language out there. It is Statically Typed and Garbage Collected.
iOS development is mostly done with Objective C. Objective C is a superset of C in which you can do both OO and non OO programs. It is a dynamically typed language and there is no Garbage Collection. Introduction of ARC(Automatic Reference Counting) made ease the life of iOS developers.
Objective C is a compiled language. Java is both compiled and interpreted language therefore does not offer the same runtime performance as Objective C. But the performance and responsiveness is also dependent on the hardware and the way you code.
Now Apple introduced a new programming language called Swift with the release of iOS 8.
Read more
Distribution:
Android apps are distributed via Google Play Store primarily. But you are free to distribute the APK files via any medium. For instance, Amazon App Store is the next popular one.
If you want to distribute via Google Play Store, you have to buy Google Play Developer account. It costs 25$ and it's for lifetime. 70% of the Profit is for you and remaining 30% is for Google.
When you submit an App in the Google Play Console, nobody will review it and it will get published within 2 to 3 hours.
iOS apps are distributed via App Store and it's the only way to reach global users. You also have Enterprise Account Distribution but that's a different story. The Developer Account costs 99$ per year. 70% of the Profit is for you and remaining 30% is for Apple.
Apple follows a very strict review process. After submitting the App, all the meta details you have provided such as description, screenshots, etc and the functionality will be validated manually which may take 5 to 7 days to get published if passed. Thus maintaining the Quality of the App Store.
Each platform has its uniqueness, limitations and advantages. From this article, iOS may seem developer friendly but that is completely based on the functionality of your App. As we witness, the race continues.
