As a veteran Android developer, I have always been curious about the iOS platform. Is Objective-C hard to learn? Is it really much easier to make beautiful UI in iOS?
I decided that the best way is to write an app on both platforms and compare. An app that I actually launch, so I experience the whole process, from coding to UI design to distribution. The result is Heart Collage, available on both Apple App Store and Google Play.
Here are my thoughts after learning iOS for two months.
The setup
I wrote an universal app in iOS 6, with auto layout and storyboard. I chose iOS 6 for the new functionalities like UICollectionView and UIActivityViewController. Auto layout and storyboard trickled down from the iOS 6 decision. Since I was on the latest version, I may as well take advantage of the latest tools.
Learning curve
The first three weeks were painful. Not only I did not know anything, but I lacked the vocabulary to ask questions. I would search for something and find 5 Stack Overflow threads, all of which sounding kind of related to what I need, but not really. It was really frustrating.
But things changed on the third week. By then I knew which classes I was using, so I prefixed all my image manipulation searches with UIImage, navigation searches with UINavigationController. I also had some basic understanding of how things were organized, and was able to skim and judge if a particular thread was relevant.
Once I knew how to find answers on the internet, development speed really picked up. I felt like I was actually coding, instead of walking into a wall.
UI Editing
Initially I thought I would really be bothered by all the square brackets in Objective-C, but I got used to the syntax fairly quickly. What tripped me up was Interface Builder / Storyboard.
In both iOS and Android, there are two ways to specify layout: xml and code. The difference is that Android has readable xml. Not so much in iOS.
Both systems use unique ids to refer to the various components. In Android, you define the id like this:
<Button android:id=”@+id/start_button” />
The build system gathers all the id tags and generate unique ids in Java:
public static final class id {
public static final int start_button=0x7f08003b;
}
To refer to a view in your code, use findViewById:
Button startButton = (Button) findViewById(R.id.start_button);
In iOS, the storyboard directly generates the unique ids in the xml:
<button id="vMl-QF-OAb" />
To refer to a view in your code, you first define an IBOutlet in your .h file, go to the storyboard, right-click drag your view into the view controller. This assumes you have already told storyboard that this particular window is linked to that view controller, otherwise the IBOutlet will not show up.
It all makes sense after the fact, but when I first started I would drag and drag and drag and not be able to link the views. Sometimes I forgot to specify the view controller. Other times I forgot to add the IBOutlet. On late nights I forgot it’s right-click drag, not just drag.
The most difficult part is that I cannot compare my implementation with sample code because it is all visual. In Android I would diff the whole project, code and xml and all, to find out what I missed. The XML produced by Interface Builder / Storyboard is not diff friendly at all.
Built-in Components
Once I got the ropes around UI editing, I can build the various screens for the app. People claim that the built-in components in iOS are much more beautiful than Android, but the gap has significantly narrowed since Ice Cream Sandwich. Sure, the iOS UIPickerView is still much more delightful to use than the Android Spinner, but the basic components like buttons are pretty much on par.
There was one thing that was much much easier to use on iOS than Android: the camera preview. Heart Collage shows a square camera preview for you to pose. In iOS, I can ask for a preview window in any aspect ratio, and the system crops the camera feed automatically. In Android? The system stretches the camera feed to the aspect ratio of the preview. To make a square camera preview I had to make the preview window the same aspect ratio as the camera feed, and cover up some parts so it appears to be a square. It was really involved. Who wants a distorted camera feed anyway? Cropping is the right thing to do.
For the rest I almost always find direct correspondences: ImageView maps to UIImageView, TextView maps to UILabel, ListView is roughly UITableView, and GridView... well GridView is interesting. Up until iOS 5 there is no built-in grid view. You have to use a UITableView and layout the cell on each row yourself. I was shocked when I heard that. Guess I’m spoiled by Android? We have that since version 1! Fortunately UICollectionView was introduced in iOS 6, and unlike Android, it is okay to target the latest OS release because most users upgrade very quickly.
This brings us to the famous fragmentation debate.
Fragmentation
There are two kinds of fragmentation: OS version and device form factor.
OS version
iOS is definitely better positioned against OS version fragmentation, since Apple is the sole manufacturer of all iOS devices and they completely control the OTA schedule.
Device form factors
Until recently the device form factor was pretty uniform. There is Retina and Non-Retina, that’s it. Different density, same aspect ratio. Same aspect ratio means you can still use a coordinate-based layout system and align your views in Interface Builder.
Everything was peachy until iPhone5. Suddenly there is a different aspect ratio, and Apple needed something more powerful than struts and springs. The solution is Auto Layout.
Auto layout is a declarative way to specify the positions of your views. Instead of saying, put this image 240 pixels from the top, you say, center vertically. The system computes the xy-coordinates based on your constraints, so it adapts well to different form factors.
Auto layout sounds good on paper, but it is really clunky to use in practice. In Interface Builder, you still drag and drop your views, and XCode tries to guess your intention. Most of the time it gets it wrong, so I have to remove the automatically generated constraints and create my own. I also tried doing it in code, but it is very verbose, and very easy to make mistakes. The visual format helps a bit, but most of the time I want to center my views, and there is no way to specify that in ASCII.
This is the time when I really really miss Android. The system was designed from day one to handle multiple form factors, and you are introduced to concepts like match_parent and wrap_content from the very beginning. I declare my layout in xml, spell out relationship among the the views with human-readable ids, and I can easily verify my rules whenever I need to add a view. In iOS I am always doubtful when I drop in a new view. What did it do to the existing views? It is so tedious to click through them one by one and examine all the constraints.
Perhaps there is a better way. But all my iOS developer friends started before iOS 6, before auto layout was available. They declare their views in code, compute the frames by hand, and basically run their own layout algorithms. And there is no reason to convert once you have a system in place, so I am on my own on the auto layout front.
Intents
Another thing I miss about Android is the intent system. Both for navigation and integration.
Navigation
For Heart Collage, I capture your poses with the camera, then replace the camera activity with the view collage activity, showing the mosaic. Here is what I do in Android:
Intent intent = new Intent(this, ViewCollageActivity.class);
startActivity(intent);
finish();
In other words, I add the view collage activity onto the activity stack, and remove the camera activity by calling finish().
It took me a very long time to figure out how to do that in iOS. In storyboard, most of the time you push a new view controller onto the stack by adding a segue to a button. You can also push a manual segue, which is what I do after the camera snaps all the photos. The tricky part is, how do I pop the old view controller? If I push first, the old view controller is no longer on top on the stack, so you cannot pop it. If I pop first, the old view controller is no longer on the stack, and I am not allowed to ask for a segue from it.
This is the moment when I doubt if it was wise to go with storyboard. It seems to be designed for very simple navigation needs, and even my 4-screen app is too complicated for it. I ended up popping one level higher with a flag to automatically forward me to view the collage. Bit of a hack, but I was too far deep into storyboard to back out and recreate all the views in xib. Especially since I have no way of copying and pasting the layouts, so I have to drag and drop everything again.
Integration
After you make a Heart Collage, the app lets you share it with your friends. This is super easy on Android. I just create an Intent saying that I want to share an image, and the system automatically generates the list of installed apps that can handle that. It’s an elegant way to have a personalized and extensible experience. Users can share their collages with any apps they prefer, and I don’t even need to know they use that app, let alone creating a new integration point.
For sharing, iOS 6 provides a similar functionality with UIActivityViewController. I set up the message and image, and it brings up a list of options for sharing. The big difference is the list is curated by Apple, and not extensible by the user. So everybody will see Sina Weibo as an option, whether they care about it or not.
This is where Android really shines, the seamless integration among apps, and as a result a very personalized experience.
Distribution
Beta testing
Finally my app was ready for beta testing. Yay!
Here are the steps for both platforms:
Android
- Compile the apk
- Email it to some friends
- There is no third step
iOS
- Collect UUID from friends
- Create provisioning profile from iOS dev portal
- Add UUID for each new test device
- Download provisioning profile from iOS dev portal
- Compile ipa
- Email provisioning profile and ipa
The most painful part is that I have to manually add each test device on the provisioning portal, and then download it to my local disk to compile the ipa. So tedious.
The flip side though, I know exactly who can run my app, and I don’t need to worry about leaks. For Android, once you send out an apk you have no idea where it will go. And there isn’t really a good way to limit the distribution.
Release
And now, the final moment - release to store. No anxiety for Android at all. Just upload, wait for an hour or so, and it’s live. For iOS, there is the review process.
I want to release Heart Collage before Valentine’s Day, so I submitted at the end of January. There should be plenty of time, but the potential rejection was stressing me out. I was so relieved when the app got approved the first try, in 6 days. Jubilation!
Verdict
I have been mostly pointing out the difference between iOS and Android. But at the end of the day, they are more similar than different. In terms of technology, at least. The verdict is still out on the money. Is it true that iOS users are more willing to pay for apps? Which platform will generate more revenue? That will be the driving force for my decision to spend time on iOS vs Android, and the numbers are still out. Will Heart Collage get more downloads on iOS or Android? We shall see.
Many thanks to Cyril Mottier and Tim Burks for reviewing the draft of this article.
Wanna check out Heart Collage? Download it here:
