7 ms·

An iOS Developer Takes on Android

720 points by nfarina 15y ago

flyosity 15y ago
As an iOS developer, this is probably the best comparison between iOS and Android development that I've read. I'm pretty scared of Eclipse and the slow-as-hell emulator doesn't sound fun, but coding layouts that don't involve lots of "how tall is this text for this given width?" calculations is a welcome addition.
- nextparadigms 15y ago
  The emulator is very slow indeed, but they talked about it at I/O and they said they will improve it this fall with hardware acceleration (they think lack of it was the biggest issue). Another smaller issue would be that the Android emulator is basically running "ARM hardware" on top of x86 (it's not just a fake simulator like the one for iOS). They're also bringing a new UI builder this fall. They talk about all of that here: http://www.youtube.com/watch?v=Oq05KqjXTvs http://www.youtube.com/watch?v=Oq05KqjXTvs
  - masklinn 15y ago
    > Another smaller issue would be that the Android emulator is basically running "ARM hardware" on top of x86 Uh... no shit? That's exactly what the "emulator" part of "ARM emulator" means. > it's not just a fake simulator like the one for iOS It's not a fake simulator, it's a simulator period. There's nothing fake about it.
    - jrbj 15y ago
      Why are people down-voting this parent? The iOS Simulator is specifically refereed to as a simulator NOT an emulator. It simulates the iOS on top of OS X and makes no attempt to be an emulator. It is a decent simulator.
      - stonemetal 15y ago
        My guess is people are down voting for tone, and the fact that he didn't even read what he quoted.
        masklinn 15y ago
        > and the fact that he didn't even read what he quoted. Of course I did. An Android emulator can only mean Android running on top of an ARM emulator, otherwise it's a simulator (like the iOS simulator). Emulators are always about hardware unless otherwise specified.
        stonemetal 15y ago
        An Android emulator can only mean Android running on top of an ARM emulator How so? Android supports both x86 and ARM. I would have thought x86 on x86 would be the way to go since it has been done before with good performance. Heck they wouldn't even have to write anything just ship a customized virtual box or QEmu.
        vetinari 15y ago
        The current emulator _is_ QEmu. However, the current problem is not arm emulation, but moving pixels in software. You will notice, that the more you increase resolution, the more the performance drops. The Google IO talk linked in this thread addresses this point, so hopefully in Autumn the emulator will be usable (especially at tablet resolutions).
    - stonemetal 15y ago
      Note what you quoted. He said Android emulator this could be emulating just the OS portion of Android with a jvm that targets x86. Instead they ship an actual ARM emulator and do not emulate Android. From what I understand of iOS development they do it the other way. They compile to x86 and emulate the iOS system calls. They don't emulate an ARM and run the real iOS on it. Therefore the Apple way is a little fake, it is possible for behavior to differ between emulated iOS and real iOS. When you run the android sim there is no possibility of stub vs real OS differences, you are always on the real OS. edit: Basically it boils down to too little context around the words emulated vs simulated.
      - masklinn 15y ago
        > He said Android emulator this could be emulating just the OS portion of Android with a jvm that targets x86. That's exactly what the iOS simulator does. It would not be an emulator in that case. It would be a simulator. Like the iOS simulator. > From what I understand of iOS development they do it the other way. They compile to x86 and emulate the iOS system calls. They don't emulate an ARM and run the real iOS on it. Hence being a simulator. > Therefore the Apple way is a little fake, it is possible for behavior to differ between emulated iOS and real iOS. It's not fake, it's a simulator. That's the whole point, and that's why it's called "simulator" not "emulator".
  - angry-hacker 15y ago
    Wow, thank you so much for that information about the new UI builder... it looks awesome. Do we have anything more specific than just "fall" about the release date?
    - estel 15y ago
      They've largely been released a month ago [1]. Some elements are still missing, however. [1] http://android-developers.blogspot.com/2011/06/new-editing-features-in-eclipse-plug-in.html http://android-developers.blogspot.com/2011/06/new-editing-f...
  - wallflower 15y ago
    Emulator snapshots help the initial bootup time Run adb install and adb uninstall from a command terminal to get a little bit faster deploys. We almost never run the debugger in Debug mode, we run it in Run mode (any runtime errors you can debug later from the stacktrace and how you got there) http://stackoverflow.com/questions/4842612/how-do-you-save-android-emulator-snapshot http://stackoverflow.com/questions/4842612/how-do-you-save-a...
- starwed 15y ago
  I've found eclipse not too bad using my MacBook Air -- having an SSD helps a lot. I actually used it as my primary Latex editor while writing my PhD thesis this spring.
  - rsynnott 15y ago
    Eclipse itself is _reasonably_ fast once it's loaded (occasional disruptive GC pauses aside); I think he's talking more about the (hideously slow) Android emulator.
    - shareme 15y ago
      you can disable those GC pauses..how? the default eclipse.ini do not change it..
- qeorge 15y ago
  I jumped into Android development about a month ago, and after a slow start its really been fun. I hated Eclipse at first, but it gets a lot better with time. The emulator though - don't bother. The author is not exaggerating about several minutes to load. Just buy an Android phone and debug on that, or you'll spend more time cursing at the emulator than coding.
  - simmons 15y ago
    I mostly use real Android devices for developing and debugging. However, another alternative is running Android-x86 in a VirtualBox. (If you aren't trying to test native ARM code, of course.) It's very fast, and I use it sometimes to test different screen resolutions and DPI's.
  - tomjen3 15y ago
    Just start the emulator op in the morning. There is no reason to shot it down when you go back to coding.
    - nickheer 15y ago
      I was going to ask whether there was a problem with your 'u' key, but you used it in "you". I'm confused.
      - fashio 15y ago
        You are confused? LOL. Kids.
      - akat 15y ago
        Jst trying to confose you more - He used 'u' in more than just you. (Just, emulator)
  - FaceKicker 15y ago
    I've found that booting the emulator does take a minute or two (I don't know about "several", but that's besides the point), but you don't have to restart every time you make a change or anything. It's just a once-per-session thing unless you accidentally close it.
- tomjen3 15y ago
  Eclipse is big, but it is really, really good to. And he is not kidding about the write your code for you, it really feels that way.
- camiller 15y ago
  If your scared of Eclipse spend some time with IBM WebSphere Developer workstation (Eclipse underneath, smothered with 10,000 "best in class plugins)[NOT an exaggeration]. Eclipse seems downright zippy in comparison! Full disclosure... I develop using Eclipse every day.
- joelhaasnoot 15y ago
  While the emulator may be slow, it's got a lot more features than the iOS simulator. The Android emulator, for instance, has built in support for GPX tracks for the GPS, very useful for location-based functionality. There's an iOS lib for it but it's not quite the same.
- fleaflicker 15y ago
  He's right about eclipse. After you learn it the productivity boost is tremendous. I'm sure lots of dev environments are like this.
chriseidhof 15y ago
This is really good stuff. As an iOS developer, this is exactly what I hoped to read someday soon. I'm impressed, great writeup and quite thorough.
al_james 15y ago
Interestingly (but inevitably) as a java developer who first learned Android and then moved to iOS, the sticking points he mentions are exactly the same ones I found, but the other way around. I think Eclipse makes sense if you think like a java coder, Xcode not so much, and Objective-C will fry your mind... That said, Eclipse and the Android SDK is a pain to install even if you are a java wizard.
- rimantas 15y ago
  Why would ObjC fry anybodie's mind? I am that weird to like it (coming from web dev background: PHP, Ruby, JavaSript)?
  - rsynnott 15y ago
    Ruby would help there; Ruby and Objective C both took considerable influence from Smalltalk for their object system.
  - mitchty 15y ago
    I might be biased as well since I learned smalltalk+ruby about the same time prior to objective c. I personally find smalltalk derived OO much less painful than the java/c++ counterparts. But thats just my opinion, they both get the job done in the end. I'm curious how it fries your mind exactly? Fries like Haskell in that it makes you learn different paradigms or fries as in challenges base assumptions on how things like OO/etc... work?
  - KirinDave 15y ago
    ObjC's main "frying" factor is that it uses a different (and to my mind, superior) set of object-oriented patterns as primary abstractions. For example, subclassing is much less common in ObjC than in Java, preferring to use the less complex delegation pattern as opposed to subclass-and-implement patterns for behavior extensions. Another problem some people have is that ObjC brings to the table all the pain of C. You've got memory management and bounds checking and unsafe casts all dumped into your lap. It can be pretty painful if you're not experienced in C, C++, or ASM programming.
- 15y ago
dmix 15y ago
This was great. Im curious, where you experienced in Java before jumping into Android?
- nfarina 15y ago
  I "learned" Java in college, but didn't use it after graduating in '02. I was quite pleasantly surprised by all the (new to me) stuff like "anonymous inner classes," and ultimately I've come to respect the staunch minimalism of the language overall.
  - rsynnott 15y ago
    If you were finishing college in 02, the anonymous inner classes should have been there; I'm pretty sure they showed up in Java 1.1 at the latest. AWT used to be heavily dependent on them.
  - vynch 15y ago
    >staunch minimalism of the language overall. really?...m just curious...are you saying it takes less code in java than objC for a given problem?
podperson 15y ago
Seems like a very balanced article to me. The comments about Eclipse made me laugh (I just had to start using Eclipse for a different reason and hate it with the heat of a thousand suns).
- simmons 15y ago
  Using Eclipse gets better as you get more comfortable with its peculiarities. I think the author did a good job of summing up the Eclipse experience--there's a lot to hate, and a lot to like. After using Eclipse for several years, it still has that "designed by committee" feel, but I do find myself missing some of its features when I'm using other environments.
  - Cyranix 15y ago
    I've actually been using the PHP... perspective?... for Eclipse and have found it to be pretty decent. (The author is right, some of the terminology is amusingly abstract.) Configuring the program just-so and learning to accept the slow boot-up are spot-on assessments. That said, I should take some time to look for another IDE that captures the basic advantages of Eclipse. I'm mainly interested in having a panel with the project's directory structure, intelligent navigation (e.g. Ctrl-click on a function call to be taken to its definition in another class), and decent code completion and syntax checking. I might even be willing to pay for it.
oflannabhra 15y ago
Great write-up. I read the whole thing and bookmarked it as well for future reference. Thanks for sharing. Which resources (online or otherwise) did you find most helpful?
- nfarina 15y ago
  I thought the Android docs were quite good for the most part, but I usually just Google my questions and end up on StackOverflow. I'd love to give StackOverflow a great big hug someday.
  - nextparadigms 15y ago
    Have you tried the forum at http://www.anddev.org http://www.anddev.org ? They have a lot of code snippets there for example.
mricardo 15y ago
I installed the Android SDK easily. I do not understand all the fuss regarding the SDK installation. The emulator is slow though, no question there.
wallflower 15y ago
Good overview and I recommend this detailed dive into the deep end by a HNer: http://clayallsopp.posterous.com/building-an-android-app-from-scratch-or-this http://clayallsopp.posterous.com/building-an-android-app-fro...
rimantas 15y ago
Question to Android devs with iOS experience: are there any tools available which would be counterpart for Instruments? Instruments do not get mentioned in these comparisons for some reason, I think these are great tools to debug and improve performance.
- wallflower 15y ago
  Traceview but you run out of stack frame capture space in about 30 seconds (even if you write to SD) Instruments has no competition from traceview. http://android-developers.blogspot.com/2010/10/traceview-war-story.html?m=1 http://android-developers.blogspot.com/2010/10/traceview-war...
ThomPete 15y ago
What a wonderful approach to development. Skip the ideological critiquing and start shipping some awesome products.. I guess that is really what separates the great developer from the good developer.
- gmac 15y ago
  Agreed, the attitude is refreshing. Nice quote: Java is a high level programming language. It’s unproductive to have an opinion about it.
  - tomjen3 15y ago
    Depends -- with that attitude we would still have assembler.
    - to3m 15y ago
      That's a fair point, but if your goal is to create something that people will pay for, targeting a popular platform with an infrastructure based around Java, what will having an opinion about Java buy you? Very little. You can like it, or you can not like it, but you'll have to use it anyway, so your time would be better spent thinking about something other than how much you like it or (as is probably more likely...) not.
      - Volpe 15y ago
        I don't think that's true. - Python - Ruby - Ruby on Rails - Django - Coffeescript - Node.js Were all results of people challenging the status quo of language/platform capability. Developing new languages/frameworks/platforms is NOT unproductive, and has proved very successful in the past. While java may not be a good excuse to avoid android, it's certainly a good excuse to improve upon the stack (as another commenter suggested, strapping Scala to it would probably be a huge productivity win). Alas the OP took a pragmatic approach and just built the product. That's fine, but it isn't "better" than someone who (rightly) thinks java is junk and attempts to improve it.
pgr0ss 15y ago
Fastdev makes the Android Emulator usable: http://developer.appcelerator.com/blog/2011/05/titanium-mobile-intro-series-fastdev-for-android.html http://developer.appcelerator.com/blog/2011/05/titanium-mobi... After you suffer the initial emulator load, changes appear in the app by simply bouncing the app. It's one big win for Titanium.
reidmain 15y ago
Why do you "have to kiss that silky smooth scrolling goodbye" if you setup your UITableViewCells in Interface Builder? I've used it for all of my apps and the scrolling is just as fast as any of Apple's native apps. Interface Builder just packages up all that initial layout code and then it is executed when the nib when it is unpackaged. After that there is no difference.
- napierzaza 15y ago
  I also don't think it's particularly hard to do the x,y frame setups either. Just start by drawing boxes on a piece of paper. Figure how things interrelate, make the code, tweak the margins.
  - reidmain 15y ago
    I agree. It's not the frame setup that sucks when compared to Android. It is the layout containers that Android has. Setting the origin of a view in iOS vs Android is going to be approximately the same amount of code (whether it be Objective-C or XML) but it is the layout containers that save you from writing all that boilerplate code when the size of the parent views change. He did make a good point of being able to preview your XML. I would kill for the ability to do that with iOS. Interface Builder needs to go the way of Expression Blend where you aren't writing plugins that allow you to edit all the properties of a UIView. Interface Builder should scan all the possible properties of a UIView and then allow you to modify them.
- clawoo 15y ago
  Actually there is a difference. If you create a table with a considerable number of cells (say, over 20) that contain a couple of labels and maybe an image when you swipe really fast the scrolling will hang, even if you are using the dequeue mechanism. The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics. Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Classes/FirstLastExampleTableViewCell.m https://github.com/ferostar/fast-scrolling/blob/master/Class...
Yhippa 15y ago
What a great comparison. Admittedly I haven't researched this but I was surprised to read that the UI components in iOS were based on OpenGL. That's pretty cool! Hats off to Android for their layout manager. I like when I use an app on Honeycomb that scales well as opposed to blowing up the pixels to fill the screen.
xcode 15y ago
Few Comments. 1. The most important thing to think about and say is the market share, fragmentation, monetization issues. Article doesn't pay enough attention to this it, but it still drives why we do what we do. (save, the author was egged on to make the app by their users). A paragraph would be useful. Perhaps something like. Fundamentally, Android is the platform you have to be on to defend the turf. It generally wont make a lot of money, but you have to be there to protect & project mind share. Additionally, it is the dominant mobile platform. 2. Development Tools. You can use IntelliJ Idea. Its a Mature Development Platform, and gives you many options. The article doesn't make any strong arguments against eclipse. The installation/getting started was more involved, but personally, it took me an hour or so, so I don't think it is a big deal. It is useful to separate opinions from facts. Personally, I use emacs bindings in all my editors, and Eclipse is pretty nice to me in general. 3. UI Design Tools This section is written in a way that projects inaccurate information. It implies that you have to use XML as opposed to using a Interface Builder interface. This is not true - there is indeed a drag and drop interface akin to IB in android. The author mentions it as a preview tool. Indeed it is also a design tool.
- MatthewPhillips 15y ago
  It wasn't an advocacy piece, it was a developer's experience in changing environments, and giving some pointers on what to do differently in Android than what one is used to in iOS. The point is not to convince you to develop for Android. The point is to help someone make the switch quickly (such as using Eclipse rather than some other method that hardly anyone uses which will cause you to spend hours getting things set up and a lot of pain following a how-to that is written with the assumption that you're using Eclipse because, you know, almost everyone who developers for Android does).
- rsynnott 15y ago
  Number 1 here is really beside the point; it's a business issue, not a development one, and a controversial one at that.
znq 15y ago
Totally agree with the other comments. This is the first honest and realistic writeup about "Android vs iOS development" I've read. I started with Android myself and started porting an Android app (which I wrote) to iPhone and I had exactly the same problems iOS developers have when starting with Android. So it's just a matter of what you're used, too. From my experience some things can be done quicker on iOS, others on Android. However, that doesn't necessarily mean better, because providing a framework for a special case usually comes with the cost of restricted flexibility. I also agree that Eclipse is a behemoth and quite overwhelming in the beginning, but there is a great tool for any code base that is larger than your typical pet project. Especially when having to read, understand and trace down other people's code.
hahainternet 15y ago
The biggest complaint seems to be that Android is software rendered. As of 3.1 (i think, maybe 3.0) this is no longer an issue as a single line in the manifest will cause Android to automatically accelerate your drawing if possible. I've yet to actually try it though :)
- nutjob123 15y ago
  It works pretty well in all the cases i've used it. Its the only way that i have been able to get the new animation class to work smoothly.
  - babebridou 15y ago
    It works pretty well... except for software input method (the other name for the touch keyboard). A simple example: make a webview that scrolls down and ends with a textfield a couple screens below. Activate Hardware acceleration, scroll, touch the textfield, boom, the textfield remains below the keyboard so you don't see what you type. Deactivate hardware acceleration. Do the same test. Boom, the screen pans up and the textfield is visible. Once you've done this on a xoom, try it on an iconia or whatever other tablet you have. Enjoy the fun of Honeycomb hardware acceleration.
eevilspock 15y ago
Eclipse is to IntelliJ as Android is to iPhone. Anyone who's used both IntelliJ and Eclipse as IDEs for Java development knows what I'm talking about. Eclipse, like Android, emphasizes "openness" and customizability while IntelliJ, like the iPhone, emphasizes "It Just Works" coherence and integrity. If you like IntelliJ's approach, you might want to try AppCode, a development environment for Objective C made by the makers of IntelliJ, JetBrains. http://www.jetbrains.com/objc/ http://www.jetbrains.com/objc/
- div 15y ago
  I've used IntelliJ for previous projects, but I am definitely going to give Eclipse a spin for the next one. The Visual Layout Editor seems like too much goodness to miss out on. Jump to 7:17 in this video for a demo: http://www.youtube.com/watch?v=Oq05KqjXTvs http://www.youtube.com/watch?v=Oq05KqjXTvs
- sjs 15y ago
  It's funny that he wrote off all the other IDEs in favour of Eclipse which requires more setup than to do Android development than IDEA does. Even if I didn't hate Eclipse it'd be hard to argue with "1. Install IntelliJ, 2. write your code".
marcomonteiro 15y ago
I hate to be picky about this but in all the time I've been doing iOS development and throughout everything I've ever read I have never seen anything to suggest that iOS using OpenGL for all of it's drawing (simulating a 2D interface in a 3D environment like the article suggests). Drawing is done using the Quartz system and animation is handled by Core Animation (which creates "an illusion of motion").
- nfarina 15y ago
  The OpenGL-nature of iOS was explained to me at WWDC by the head of graphics at Apple. But you can never be sure of anything!
  - marcomonteiro 15y ago
    Interesting.
- jrbj 15y ago
  Knowing that Quartz on OS X uses OpenGL, I'd assume it also uses it on iOS.
- pagliara 15y ago
  No, the author is right. Quartz and Core Animation are built on top of OpenGL.
- koko775 15y ago
  The more you know: UIViews are basically event-handling abstractions above CALayers, which in turn are a relatively thin abstraction above common OpenGL actions. Core Animation simply manipulates these layers in the hierarchy, of which there are three per view: model, presentation, and render. The model is the one you interact with. When you change the location of a view, it changes the model, which is then reflected in the presentation. When you animate, it tweens from the beginning state to the end state. Fun fact: when you start a new animation and start it from the current screen state, it uses the presentation layer, instead of the model layer. If you don't start the animation from the current state, this is why you might see jerking - it tweens from the model layer instead of the presentation layer. The render layer, the last of the three, is rendered by the render server, which is hardware accelerated, and shown to you. Fun fact: CALayer's renderInContext runs on the CPU, whereas UIGetScreenImage uses the render server, which is why it's so much faster - it runs on the GPU.
pwelch 15y ago
"It takes the Android Emulator ~2 minutes to boot up on my perfectly-modern machine. But what really hurts is the edit/debug cycle. Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day." I do not have any experience with iOS development but I can vouch for how hard it is to use the Android Emulator. I just recently submitted an Android application for a programming course and if it were not for having an Android mobile device to replace the emulator I would not have completed the project in time. The Emulator is slow and buggy and made it hard to test new code. If you are interested in developing an Android application deffinately check it out but take this guys advice and get a device to test it on. It will save you a lot of time.
- jamesbritt 15y ago
  Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day." Is there no practical way to reduce this by using unit tests? I understand if you're doing UI tweaks but otherwise it seems far more efficient to do targeted testing.
smcj 15y ago
This is a great and honest article and has changed the way I think about Apple users/developers. Before that, I considered Apple users to be a group of gay douchebags, but today I have learned that there is at least a sane person on the other riverside. (I have neither developed for any smartphone nor do I possess one, so no need for "Stupid FANDROID!1!")
- camtarn 15y ago
  Us gays also use Android, y'know ;)
  - smcj 15y ago
    Yes, sure. There is much less discrimination against "other" people on non-Apple platforms and that's great!
mooneater 15y ago
Clicking their site http://www.meridianapps.com/ http://www.meridianapps.com/ leads to "App Engine Error: Over Quota. This Google App Engine application is temporarily over its serving quota. Please try again later" Ouch!
- nfarina 15y ago
  Just increased the quota. Humbling.
rheide 15y ago
Wow. I never expected that much negativity for the Android side. I've dabbled in both but haven't done Android since over a year ago. I was (and still am) really looking forward to using Eclipse and reading Java. I just get very tired of XCode.
rudy750 15y ago
Slow Clap for you sir...
scottjad 15y ago
> Apple has made it pretty easy to start writing iOS apps. Of course, Step One is “Buy a Mac.” Easy! Then just download the free Xcode Installer from the Mac App Store, and start writing code when it’s done. > Android is a bit more involved. You can download the SDK easily, but to actually start writing code, you’ll want to setup Eclipse and install Google’s ADT Plugin. Buying and setting up a new computer is "Easy!" but installing Eclipse is "more involved"? Having to sign up for a $99 developer program is omitted. The size difference, of a couple hundred mb for Eclipse vs 4gb for Xcode is omitted.
- bitwize 15y ago
  You don't need eclipse. You can get by with Emacs, JDK, and ant. Plus the Android SDK of course. That's how I roll, and it works just fine.
- rimantas 15y ago
  You don't need to sing up for develper program to start hacking for iOS. But if you want to run your code on real device or make it available in App Store you will have to do that. Setting up new Mac is really that easy. You can just launch Mac App Store application, press a button to download Xcode and when it's done lauch the installer.
- nfarina 15y ago
  My sarcasm may have been too subtle there; I definitely think it's a bummer that you have to own a Mac to develop for iOS.
ZoFreX 15y ago
A couple of points... > Android has a system of layout containers (similar to HTML) It would be more correct (I think) to say it's inspired by other Java layout managers, Swing and SWT aren't a million worlds removed from Android (but I can't really expect someone new to Java to know that!) And the emulator. The Android emulator is not slow. I have a netbook, which is an absolutely fantastic way of finding out which applications do far too much but you never notice because your computer is very fast. Team Fortress 2 is slow. Eclipse is slow. I tried booting the Android emulator and gave up waiting after an hour and a half. Overall, awesome article. Refreshing to see someone providing a useful comparison between the two rather than arguing over one or the other, and as a Java developer who knows a little about Android, I feel I just learnt a lot about iOS. I'm actually amazed at how much they have in common, you wouldn't think so from the arguments!
S_A_P 15y ago
This article was damn near perfect. I much prefer this style to "the problem with X" or "Why X will never succeed". This person isn't interested in platform evangelism, he/she wants to ship. A very inspiring attitude to have.
bad_user 15y ago
If you're starting Android development, just save yourself the pain and just use the IntelliJ IDEA community edition. The Android plugin included doesn't have fancy UI stuff, like for designing interfaces or visually editing the XML configuration files, but it does have code-completion of XML tags and properties and it works better as a code editor, being less painful.
- zmalltalker 15y ago
  I've tried doing that, but whenever I'm actually doing work on Android app a really large percentage of my time spent is done working on the UI. Not having the ADT tools for the UI just doesn't make sense to me.
euroclydon 15y ago
Didn't Apple just release Auto Layouts for Cocoa? Will Auto Layouts come to iPhone? http://news.ycombinator.com/item?id=2788608 http://news.ycombinator.com/item?id=2788608
juliano_q 15y ago
Thanks for this article it just made me feel happy. I so tired of flame wars regarding IOS x Android that I barely read Engadget anymore. Many people dont understand why I have a Macbook, an Android phone and an iPod, looks like you MUST took a side and be an evangelist.
alain94040 15y ago
Best explanation of why rendering on the iPhone uses the GPU and Android can't. A great article to read.
bignoggins 15y ago
iOS developer here. Releasing first android version of my app this week. Even though I didn't do the coding, I've taken a look at the code and done quite a bit of testing. The part about animations is totally true. Animations are much faster and smoother on my iPod 3rd Gen than the equivalent animation on a Droid Incredible, which has much better hardware! We've tried to optimize as much as possible, but we are realizing that there is just no way to match the iOS version's speed and responsiveness.
jbuzbee 15y ago
Nice well-written article. I just did the same sort of article myself telling about my experiences going from IOS to Android: http://www.smallcloudbuilder.com/apps/articles/410-crossing-the-chasm-converting-an-iphone-app-to-android http://www.smallcloudbuilder.com/apps/articles/410-crossing-...
Becca365 15y ago
I just paid $22.87 for an iPad2-64GB and my girlfriend loves her Panasonic Lumix GF 1 Camera that we got for $38.76 there arriving tomorrow by UPS. I will never pay such expensive retail prices in stores again. Especially when I also sold a 40 inch LED TV to my boss for $675 which only cost me $62.81 to buy. Here is the website we use to get it all from, GrabCent. çom
raminf 15y ago
Nice overview. I have to disagree with the assessment of Eclipse though. Under one app you can build and debug Java, Python, Ruby, HTML, Javascript, and Air apps. Once you get used to the workflow, it's incredibly productive. As for the emulator, unless you want to invest in a large set of devices, it's the only way to test against different screen sizes and device profiles. Even though it's nice to have a device for debugging, you'll need to make peace with the emulator to make sure your app doesn't go all wonky on devices other than your exact model.

720 points by nfarina 15y ago

As an iOS developer, this is probably the best comparison between iOS and Android development that I've read. I'm pretty scared of Eclipse and the slow-as-hell emulator doesn't sound fun, but coding layouts that don't involve lots of "how tall is this text for this given width?" calculations is a welcome addition.

nextparadigms 15y ago
The emulator is very slow indeed, but they talked about it at I/O and they said they will improve it this fall with hardware acceleration (they think lack of it was the biggest issue). Another smaller issue would be that the Android emulator is basically running "ARM hardware" on top of x86 (it's not just a fake simulator like the one for iOS). They're also bringing a new UI builder this fall. They talk about all of that here: http://www.youtube.com/watch?v=Oq05KqjXTvs http://www.youtube.com/watch?v=Oq05KqjXTvs
- masklinn 15y ago
  > Another smaller issue would be that the Android emulator is basically running "ARM hardware" on top of x86 Uh... no shit? That's exactly what the "emulator" part of "ARM emulator" means. > it's not just a fake simulator like the one for iOS It's not a fake simulator, it's a simulator period. There's nothing fake about it.
  - jrbj 15y ago
    Why are people down-voting this parent? The iOS Simulator is specifically refereed to as a simulator NOT an emulator. It simulates the iOS on top of OS X and makes no attempt to be an emulator. It is a decent simulator.
    - stonemetal 15y ago
      My guess is people are down voting for tone, and the fact that he didn't even read what he quoted.
      - masklinn 15y ago
        > and the fact that he didn't even read what he quoted. Of course I did. An Android emulator can only mean Android running on top of an ARM emulator, otherwise it's a simulator (like the iOS simulator). Emulators are always about hardware unless otherwise specified.
        stonemetal 15y ago
        An Android emulator can only mean Android running on top of an ARM emulator How so? Android supports both x86 and ARM. I would have thought x86 on x86 would be the way to go since it has been done before with good performance. Heck they wouldn't even have to write anything just ship a customized virtual box or QEmu.
        vetinari 15y ago
        The current emulator _is_ QEmu. However, the current problem is not arm emulation, but moving pixels in software. You will notice, that the more you increase resolution, the more the performance drops. The Google IO talk linked in this thread addresses this point, so hopefully in Autumn the emulator will be usable (especially at tablet resolutions).
  - stonemetal 15y ago
    Note what you quoted. He said Android emulator this could be emulating just the OS portion of Android with a jvm that targets x86. Instead they ship an actual ARM emulator and do not emulate Android. From what I understand of iOS development they do it the other way. They compile to x86 and emulate the iOS system calls. They don't emulate an ARM and run the real iOS on it. Therefore the Apple way is a little fake, it is possible for behavior to differ between emulated iOS and real iOS. When you run the android sim there is no possibility of stub vs real OS differences, you are always on the real OS. edit: Basically it boils down to too little context around the words emulated vs simulated.
    - masklinn 15y ago
      > He said Android emulator this could be emulating just the OS portion of Android with a jvm that targets x86. That's exactly what the iOS simulator does. It would not be an emulator in that case. It would be a simulator. Like the iOS simulator. > From what I understand of iOS development they do it the other way. They compile to x86 and emulate the iOS system calls. They don't emulate an ARM and run the real iOS on it. Hence being a simulator. > Therefore the Apple way is a little fake, it is possible for behavior to differ between emulated iOS and real iOS. It's not fake, it's a simulator. That's the whole point, and that's why it's called "simulator" not "emulator".
- angry-hacker 15y ago
  Wow, thank you so much for that information about the new UI builder... it looks awesome. Do we have anything more specific than just "fall" about the release date?
  - estel 15y ago
    They've largely been released a month ago [1]. Some elements are still missing, however. [1] http://android-developers.blogspot.com/2011/06/new-editing-features-in-eclipse-plug-in.html http://android-developers.blogspot.com/2011/06/new-editing-f...
- wallflower 15y ago
  Emulator snapshots help the initial bootup time Run adb install and adb uninstall from a command terminal to get a little bit faster deploys. We almost never run the debugger in Debug mode, we run it in Run mode (any runtime errors you can debug later from the stacktrace and how you got there) http://stackoverflow.com/questions/4842612/how-do-you-save-android-emulator-snapshot http://stackoverflow.com/questions/4842612/how-do-you-save-a...
starwed 15y ago
I've found eclipse not too bad using my MacBook Air -- having an SSD helps a lot. I actually used it as my primary Latex editor while writing my PhD thesis this spring.
- rsynnott 15y ago
  Eclipse itself is _reasonably_ fast once it's loaded (occasional disruptive GC pauses aside); I think he's talking more about the (hideously slow) Android emulator.
  - shareme 15y ago
    you can disable those GC pauses..how? the default eclipse.ini do not change it..
qeorge 15y ago
I jumped into Android development about a month ago, and after a slow start its really been fun. I hated Eclipse at first, but it gets a lot better with time. The emulator though - don't bother. The author is not exaggerating about several minutes to load. Just buy an Android phone and debug on that, or you'll spend more time cursing at the emulator than coding.
- simmons 15y ago
  I mostly use real Android devices for developing and debugging. However, another alternative is running Android-x86 in a VirtualBox. (If you aren't trying to test native ARM code, of course.) It's very fast, and I use it sometimes to test different screen resolutions and DPI's.
- tomjen3 15y ago
  Just start the emulator op in the morning. There is no reason to shot it down when you go back to coding.
  - nickheer 15y ago
    I was going to ask whether there was a problem with your 'u' key, but you used it in "you". I'm confused.
    - fashio 15y ago
      You are confused? LOL. Kids.
    - akat 15y ago
      Jst trying to confose you more - He used 'u' in more than just you. (Just, emulator)
- FaceKicker 15y ago
  I've found that booting the emulator does take a minute or two (I don't know about "several", but that's besides the point), but you don't have to restart every time you make a change or anything. It's just a once-per-session thing unless you accidentally close it.
tomjen3 15y ago
Eclipse is big, but it is really, really good to. And he is not kidding about the write your code for you, it really feels that way.
camiller 15y ago
If your scared of Eclipse spend some time with IBM WebSphere Developer workstation (Eclipse underneath, smothered with 10,000 "best in class plugins)[NOT an exaggeration]. Eclipse seems downright zippy in comparison! Full disclosure... I develop using Eclipse every day.
joelhaasnoot 15y ago
While the emulator may be slow, it's got a lot more features than the iOS simulator. The Android emulator, for instance, has built in support for GPX tracks for the GPS, very useful for location-based functionality. There's an iOS lib for it but it's not quite the same.
fleaflicker 15y ago
He's right about eclipse. After you learn it the productivity boost is tremendous. I'm sure lots of dev environments are like this.

chriseidhof 15y ago

This is really good stuff. As an iOS developer, this is exactly what I hoped to read someday soon. I'm impressed, great writeup and quite thorough.

al_james 15y ago

Interestingly (but inevitably) as a java developer who first learned Android and then moved to iOS, the sticking points he mentions are exactly the same ones I found, but the other way around. I think Eclipse makes sense if you think like a java coder, Xcode not so much, and Objective-C will fry your mind... That said, Eclipse and the Android SDK is a pain to install even if you are a java wizard.

rimantas 15y ago
Why would ObjC fry anybodie's mind? I am that weird to like it (coming from web dev background: PHP, Ruby, JavaSript)?
- rsynnott 15y ago
  Ruby would help there; Ruby and Objective C both took considerable influence from Smalltalk for their object system.
- mitchty 15y ago
  I might be biased as well since I learned smalltalk+ruby about the same time prior to objective c. I personally find smalltalk derived OO much less painful than the java/c++ counterparts. But thats just my opinion, they both get the job done in the end. I'm curious how it fries your mind exactly? Fries like Haskell in that it makes you learn different paradigms or fries as in challenges base assumptions on how things like OO/etc... work?
- KirinDave 15y ago
  ObjC's main "frying" factor is that it uses a different (and to my mind, superior) set of object-oriented patterns as primary abstractions. For example, subclassing is much less common in ObjC than in Java, preferring to use the less complex delegation pattern as opposed to subclass-and-implement patterns for behavior extensions. Another problem some people have is that ObjC brings to the table all the pain of C. You've got memory management and bounds checking and unsafe casts all dumped into your lap. It can be pretty painful if you're not experienced in C, C++, or ASM programming.
15y ago

dmix 15y ago

This was great. Im curious, where you experienced in Java before jumping into Android?

nfarina 15y ago
I "learned" Java in college, but didn't use it after graduating in '02. I was quite pleasantly surprised by all the (new to me) stuff like "anonymous inner classes," and ultimately I've come to respect the staunch minimalism of the language overall.
- rsynnott 15y ago
  If you were finishing college in 02, the anonymous inner classes should have been there; I'm pretty sure they showed up in Java 1.1 at the latest. AWT used to be heavily dependent on them.
- vynch 15y ago
  >staunch minimalism of the language overall. really?...m just curious...are you saying it takes less code in java than objC for a given problem?

podperson 15y ago

Seems like a very balanced article to me. The comments about Eclipse made me laugh (I just had to start using Eclipse for a different reason and hate it with the heat of a thousand suns).

simmons 15y ago
Using Eclipse gets better as you get more comfortable with its peculiarities. I think the author did a good job of summing up the Eclipse experience--there's a lot to hate, and a lot to like. After using Eclipse for several years, it still has that "designed by committee" feel, but I do find myself missing some of its features when I'm using other environments.
- Cyranix 15y ago
  I've actually been using the PHP... perspective?... for Eclipse and have found it to be pretty decent. (The author is right, some of the terminology is amusingly abstract.) Configuring the program just-so and learning to accept the slow boot-up are spot-on assessments. That said, I should take some time to look for another IDE that captures the basic advantages of Eclipse. I'm mainly interested in having a panel with the project's directory structure, intelligent navigation (e.g. Ctrl-click on a function call to be taken to its definition in another class), and decent code completion and syntax checking. I might even be willing to pay for it.

oflannabhra 15y ago

Great write-up. I read the whole thing and bookmarked it as well for future reference. Thanks for sharing. Which resources (online or otherwise) did you find most helpful?

nfarina 15y ago
I thought the Android docs were quite good for the most part, but I usually just Google my questions and end up on StackOverflow. I'd love to give StackOverflow a great big hug someday.
- nextparadigms 15y ago
  Have you tried the forum at http://www.anddev.org http://www.anddev.org ? They have a lot of code snippets there for example.

mricardo 15y ago

I installed the Android SDK easily. I do not understand all the fuss regarding the SDK installation. The emulator is slow though, no question there.

wallflower 15y ago

Good overview and I recommend this detailed dive into the deep end by a HNer: http://clayallsopp.posterous.com/building-an-android-app-from-scratch-or-this http://clayallsopp.posterous.com/building-an-android-app-fro...

rimantas 15y ago

Question to Android devs with iOS experience: are there any tools available which would be counterpart for Instruments? Instruments do not get mentioned in these comparisons for some reason, I think these are great tools to debug and improve performance.

wallflower 15y ago
Traceview but you run out of stack frame capture space in about 30 seconds (even if you write to SD) Instruments has no competition from traceview. http://android-developers.blogspot.com/2010/10/traceview-war-story.html?m=1 http://android-developers.blogspot.com/2010/10/traceview-war...

ThomPete 15y ago

What a wonderful approach to development. Skip the ideological critiquing and start shipping some awesome products.. I guess that is really what separates the great developer from the good developer.

gmac 15y ago
Agreed, the attitude is refreshing. Nice quote: Java is a high level programming language. It’s unproductive to have an opinion about it.
- tomjen3 15y ago
  Depends -- with that attitude we would still have assembler.
  - to3m 15y ago
    That's a fair point, but if your goal is to create something that people will pay for, targeting a popular platform with an infrastructure based around Java, what will having an opinion about Java buy you? Very little. You can like it, or you can not like it, but you'll have to use it anyway, so your time would be better spent thinking about something other than how much you like it or (as is probably more likely...) not.
    - Volpe 15y ago
      I don't think that's true. - Python - Ruby - Ruby on Rails - Django - Coffeescript - Node.js Were all results of people challenging the status quo of language/platform capability. Developing new languages/frameworks/platforms is NOT unproductive, and has proved very successful in the past. While java may not be a good excuse to avoid android, it's certainly a good excuse to improve upon the stack (as another commenter suggested, strapping Scala to it would probably be a huge productivity win). Alas the OP took a pragmatic approach and just built the product. That's fine, but it isn't "better" than someone who (rightly) thinks java is junk and attempts to improve it.

pgr0ss 15y ago

Fastdev makes the Android Emulator usable: http://developer.appcelerator.com/blog/2011/05/titanium-mobile-intro-series-fastdev-for-android.html http://developer.appcelerator.com/blog/2011/05/titanium-mobi... After you suffer the initial emulator load, changes appear in the app by simply bouncing the app. It's one big win for Titanium.

reidmain 15y ago

Why do you "have to kiss that silky smooth scrolling goodbye" if you setup your UITableViewCells in Interface Builder? I've used it for all of my apps and the scrolling is just as fast as any of Apple's native apps. Interface Builder just packages up all that initial layout code and then it is executed when the nib when it is unpackaged. After that there is no difference.

napierzaza 15y ago
I also don't think it's particularly hard to do the x,y frame setups either. Just start by drawing boxes on a piece of paper. Figure how things interrelate, make the code, tweak the margins.
- reidmain 15y ago
  I agree. It's not the frame setup that sucks when compared to Android. It is the layout containers that Android has. Setting the origin of a view in iOS vs Android is going to be approximately the same amount of code (whether it be Objective-C or XML) but it is the layout containers that save you from writing all that boilerplate code when the size of the parent views change. He did make a good point of being able to preview your XML. I would kill for the ability to do that with iOS. Interface Builder needs to go the way of Expression Blend where you aren't writing plugins that allow you to edit all the properties of a UIView. Interface Builder should scan all the possible properties of a UIView and then allow you to modify them.
clawoo 15y ago
Actually there is a difference. If you create a table with a considerable number of cells (say, over 20) that contain a couple of labels and maybe an image when you swipe really fast the scrolling will hang, even if you are using the dequeue mechanism. The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics. Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Classes/FirstLastExampleTableViewCell.m https://github.com/ferostar/fast-scrolling/blob/master/Class...

Yhippa 15y ago

What a great comparison. Admittedly I haven't researched this but I was surprised to read that the UI components in iOS were based on OpenGL. That's pretty cool! Hats off to Android for their layout manager. I like when I use an app on Honeycomb that scales well as opposed to blowing up the pixels to fill the screen.

xcode 15y ago

Few Comments. 1. The most important thing to think about and say is the market share, fragmentation, monetization issues. Article doesn't pay enough attention to this it, but it still drives why we do what we do. (save, the author was egged on to make the app by their users). A paragraph would be useful. Perhaps something like. Fundamentally, Android is the platform you have to be on to defend the turf. It generally wont make a lot of money, but you have to be there to protect & project mind share. Additionally, it is the dominant mobile platform. 2. Development Tools. You can use IntelliJ Idea. Its a Mature Development Platform, and gives you many options. The article doesn't make any strong arguments against eclipse. The installation/getting started was more involved, but personally, it took me an hour or so, so I don't think it is a big deal. It is useful to separate opinions from facts. Personally, I use emacs bindings in all my editors, and Eclipse is pretty nice to me in general. 3. UI Design Tools This section is written in a way that projects inaccurate information. It implies that you have to use XML as opposed to using a Interface Builder interface. This is not true - there is indeed a drag and drop interface akin to IB in android. The author mentions it as a preview tool. Indeed it is also a design tool.

MatthewPhillips 15y ago
It wasn't an advocacy piece, it was a developer's experience in changing environments, and giving some pointers on what to do differently in Android than what one is used to in iOS. The point is not to convince you to develop for Android. The point is to help someone make the switch quickly (such as using Eclipse rather than some other method that hardly anyone uses which will cause you to spend hours getting things set up and a lot of pain following a how-to that is written with the assumption that you're using Eclipse because, you know, almost everyone who developers for Android does).
rsynnott 15y ago
Number 1 here is really beside the point; it's a business issue, not a development one, and a controversial one at that.

znq 15y ago

Totally agree with the other comments. This is the first honest and realistic writeup about "Android vs iOS development" I've read. I started with Android myself and started porting an Android app (which I wrote) to iPhone and I had exactly the same problems iOS developers have when starting with Android. So it's just a matter of what you're used, too. From my experience some things can be done quicker on iOS, others on Android. However, that doesn't necessarily mean better, because providing a framework for a special case usually comes with the cost of restricted flexibility. I also agree that Eclipse is a behemoth and quite overwhelming in the beginning, but there is a great tool for any code base that is larger than your typical pet project. Especially when having to read, understand and trace down other people's code.

hahainternet 15y ago

The biggest complaint seems to be that Android is software rendered. As of 3.1 (i think, maybe 3.0) this is no longer an issue as a single line in the manifest will cause Android to automatically accelerate your drawing if possible. I've yet to actually try it though :)

nutjob123 15y ago
It works pretty well in all the cases i've used it. Its the only way that i have been able to get the new animation class to work smoothly.
- babebridou 15y ago
  It works pretty well... except for software input method (the other name for the touch keyboard). A simple example: make a webview that scrolls down and ends with a textfield a couple screens below. Activate Hardware acceleration, scroll, touch the textfield, boom, the textfield remains below the keyboard so you don't see what you type. Deactivate hardware acceleration. Do the same test. Boom, the screen pans up and the textfield is visible. Once you've done this on a xoom, try it on an iconia or whatever other tablet you have. Enjoy the fun of Honeycomb hardware acceleration.

eevilspock 15y ago

Eclipse is to IntelliJ as Android is to iPhone. Anyone who's used both IntelliJ and Eclipse as IDEs for Java development knows what I'm talking about. Eclipse, like Android, emphasizes "openness" and customizability while IntelliJ, like the iPhone, emphasizes "It Just Works" coherence and integrity. If you like IntelliJ's approach, you might want to try AppCode, a development environment for Objective C made by the makers of IntelliJ, JetBrains. http://www.jetbrains.com/objc/ http://www.jetbrains.com/objc/

div 15y ago
I've used IntelliJ for previous projects, but I am definitely going to give Eclipse a spin for the next one. The Visual Layout Editor seems like too much goodness to miss out on. Jump to 7:17 in this video for a demo: http://www.youtube.com/watch?v=Oq05KqjXTvs http://www.youtube.com/watch?v=Oq05KqjXTvs
sjs 15y ago
It's funny that he wrote off all the other IDEs in favour of Eclipse which requires more setup than to do Android development than IDEA does. Even if I didn't hate Eclipse it'd be hard to argue with "1. Install IntelliJ, 2. write your code".

marcomonteiro 15y ago

I hate to be picky about this but in all the time I've been doing iOS development and throughout everything I've ever read I have never seen anything to suggest that iOS using OpenGL for all of it's drawing (simulating a 2D interface in a 3D environment like the article suggests). Drawing is done using the Quartz system and animation is handled by Core Animation (which creates "an illusion of motion").

nfarina 15y ago
The OpenGL-nature of iOS was explained to me at WWDC by the head of graphics at Apple. But you can never be sure of anything!
- marcomonteiro 15y ago
  Interesting.
jrbj 15y ago
Knowing that Quartz on OS X uses OpenGL, I'd assume it also uses it on iOS.
pagliara 15y ago
No, the author is right. Quartz and Core Animation are built on top of OpenGL.
koko775 15y ago
The more you know: UIViews are basically event-handling abstractions above CALayers, which in turn are a relatively thin abstraction above common OpenGL actions. Core Animation simply manipulates these layers in the hierarchy, of which there are three per view: model, presentation, and render. The model is the one you interact with. When you change the location of a view, it changes the model, which is then reflected in the presentation. When you animate, it tweens from the beginning state to the end state. Fun fact: when you start a new animation and start it from the current screen state, it uses the presentation layer, instead of the model layer. If you don't start the animation from the current state, this is why you might see jerking - it tweens from the model layer instead of the presentation layer. The render layer, the last of the three, is rendered by the render server, which is hardware accelerated, and shown to you. Fun fact: CALayer's renderInContext runs on the CPU, whereas UIGetScreenImage uses the render server, which is why it's so much faster - it runs on the GPU.

pwelch 15y ago

"It takes the Android Emulator ~2 minutes to boot up on my perfectly-modern machine. But what really hurts is the edit/debug cycle. Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day." I do not have any experience with iOS development but I can vouch for how hard it is to use the Android Emulator. I just recently submitted an Android application for a programming course and if it were not for having an Android mobile device to replace the emulator I would not have completed the project in time. The Emulator is slow and buggy and made it hard to test new code. If you are interested in developing an Android application deffinately check it out but take this guys advice and get a device to test it on. It will save you a lot of time.

jamesbritt 15y ago
Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day." Is there no practical way to reduce this by using unit tests? I understand if you're doing UI tweaks but otherwise it seems far more efficient to do targeted testing.

smcj 15y ago

This is a great and honest article and has changed the way I think about Apple users/developers. Before that, I considered Apple users to be a group of gay douchebags, but today I have learned that there is at least a sane person on the other riverside. (I have neither developed for any smartphone nor do I possess one, so no need for "Stupid FANDROID!1!")

camtarn 15y ago
Us gays also use Android, y'know ;)
- smcj 15y ago
  Yes, sure. There is much less discrimination against "other" people on non-Apple platforms and that's great!

mooneater 15y ago

Clicking their site http://www.meridianapps.com/ http://www.meridianapps.com/ leads to "App Engine Error: Over Quota. This Google App Engine application is temporarily over its serving quota. Please try again later" Ouch!

nfarina 15y ago
Just increased the quota. Humbling.

rheide 15y ago

Wow. I never expected that much negativity for the Android side. I've dabbled in both but haven't done Android since over a year ago. I was (and still am) really looking forward to using Eclipse and reading Java. I just get very tired of XCode.

rudy750 15y ago

Slow Clap for you sir...

scottjad 15y ago

> Apple has made it pretty easy to start writing iOS apps. Of course, Step One is “Buy a Mac.” Easy! Then just download the free Xcode Installer from the Mac App Store, and start writing code when it’s done. > Android is a bit more involved. You can download the SDK easily, but to actually start writing code, you’ll want to setup Eclipse and install Google’s ADT Plugin. Buying and setting up a new computer is "Easy!" but installing Eclipse is "more involved"? Having to sign up for a $99 developer program is omitted. The size difference, of a couple hundred mb for Eclipse vs 4gb for Xcode is omitted.

bitwize 15y ago
You don't need eclipse. You can get by with Emacs, JDK, and ant. Plus the Android SDK of course. That's how I roll, and it works just fine.
rimantas 15y ago
You don't need to sing up for develper program to start hacking for iOS. But if you want to run your code on real device or make it available in App Store you will have to do that. Setting up new Mac is really that easy. You can just launch Mac App Store application, press a button to download Xcode and when it's done lauch the installer.
nfarina 15y ago
My sarcasm may have been too subtle there; I definitely think it's a bummer that you have to own a Mac to develop for iOS.

ZoFreX 15y ago

A couple of points... > Android has a system of layout containers (similar to HTML) It would be more correct (I think) to say it's inspired by other Java layout managers, Swing and SWT aren't a million worlds removed from Android (but I can't really expect someone new to Java to know that!) And the emulator. The Android emulator is not slow. I have a netbook, which is an absolutely fantastic way of finding out which applications do far too much but you never notice because your computer is very fast. Team Fortress 2 is slow. Eclipse is slow. I tried booting the Android emulator and gave up waiting after an hour and a half. Overall, awesome article. Refreshing to see someone providing a useful comparison between the two rather than arguing over one or the other, and as a Java developer who knows a little about Android, I feel I just learnt a lot about iOS. I'm actually amazed at how much they have in common, you wouldn't think so from the arguments!

S_A_P 15y ago

This article was damn near perfect. I much prefer this style to "the problem with X" or "Why X will never succeed". This person isn't interested in platform evangelism, he/she wants to ship. A very inspiring attitude to have.

bad_user 15y ago

If you're starting Android development, just save yourself the pain and just use the IntelliJ IDEA community edition. The Android plugin included doesn't have fancy UI stuff, like for designing interfaces or visually editing the XML configuration files, but it does have code-completion of XML tags and properties and it works better as a code editor, being less painful.

zmalltalker 15y ago
I've tried doing that, but whenever I'm actually doing work on Android app a really large percentage of my time spent is done working on the UI. Not having the ADT tools for the UI just doesn't make sense to me.

euroclydon 15y ago

Didn't Apple just release Auto Layouts for Cocoa? Will Auto Layouts come to iPhone? http://news.ycombinator.com/item?id=2788608 http://news.ycombinator.com/item?id=2788608

juliano_q 15y ago

Thanks for this article it just made me feel happy. I so tired of flame wars regarding IOS x Android that I barely read Engadget anymore. Many people dont understand why I have a Macbook, an Android phone and an iPod, looks like you MUST took a side and be an evangelist.

alain94040 15y ago

Best explanation of why rendering on the iPhone uses the GPU and Android can't. A great article to read.

bignoggins 15y ago

iOS developer here. Releasing first android version of my app this week. Even though I didn't do the coding, I've taken a look at the code and done quite a bit of testing. The part about animations is totally true. Animations are much faster and smoother on my iPod 3rd Gen than the equivalent animation on a Droid Incredible, which has much better hardware! We've tried to optimize as much as possible, but we are realizing that there is just no way to match the iOS version's speed and responsiveness.

jbuzbee 15y ago

Nice well-written article. I just did the same sort of article myself telling about my experiences going from IOS to Android: http://www.smallcloudbuilder.com/apps/articles/410-crossing-the-chasm-converting-an-iphone-app-to-android http://www.smallcloudbuilder.com/apps/articles/410-crossing-...

Becca365 15y ago

I just paid $22.87 for an iPad2-64GB and my girlfriend loves her Panasonic Lumix GF 1 Camera that we got for $38.76 there arriving tomorrow by UPS. I will never pay such expensive retail prices in stores again. Especially when I also sold a 40 inch LED TV to my boss for $675 which only cost me $62.81 to buy. Here is the website we use to get it all from, GrabCent. çom

raminf 15y ago

Nice overview. I have to disagree with the assessment of Eclipse though. Under one app you can build and debug Java, Python, Ruby, HTML, Javascript, and Air apps. Once you get used to the workflow, it's incredibly productive. As for the emulator, unless you want to invest in a large set of devices, it's the only way to test against different screen sizes and device profiles. Even though it's nice to have a device for debugging, you'll need to make peace with the emulator to make sure your app doesn't go all wonky on devices other than your exact model.