Comment by zmmmmm | Hacker News Reader

Comment by zmmmmm | Hacker News Reader

A lot of people seem to be missing the main point here. I don't think the article is actually advocating developing for Android and NOT iOS. I don't think it is even particularly advocating releasing on Android first. However starting your development on Android - as your first way of prototyping and finding your MVP - gives you a tremendous amount of agility and flexibility. You can create as many APKs as you want, send them to whoever you want without any fuss and they can test them out. You can fix bugs or implement features for just one person and send them the APK the same day. You can integrate your app with the OS and other apps in ways that are impossible on iOS to find what really works and matters to your users. And you can do all this for virtually zero cost on commodity hardware with free tools.

In other words, even if you believe iOS is ultimately going to be your primary platform, there's still a strong argument to do your initial prototyping and development on Android.

None of what you said makes sense.

Firstly on iOS you can send as many IPAs as I want to friends, testers, colleagues etc provided I've gone through the 30s process of adding them to Apple's list. This isn't some giant inconvenience that warrants completely switching a platform.

Secondly if your app is intended to be cross platform. Then why would you start creating OS specific functionality you know will never work on the other platform. It's completely illogical.

iOS is likely to remain the primary platform for prototyping. Why ? Because it is just so much nicer. The iOS Simulator "just works" and exactly mirrors your target devices. Not the pathetic joke that comes with the Android SDK which has no relation to how your app will run on a Samsung versus HTC devices.

We are not comparing Dev tools. We are comparing Dev life cycle and methodologies

We are talking about choosing iOS versus Android for prototyping. My point is that the iOS development experience is far superior to Android in particular because of the strength of the simulator. How you "get your code running" is the most important part of the dev life cycle.

Perhaps for software development, but not for product development. Often as or more important to a product is finding out how it works for real users, and rapidly prototyping and disseminating builds is a good way to do that.

While software engineering is hard as a discipline, I don't feel it is the hardest part of building a startup.

On the other hand, for Android it's far easier to get your app running on the device itself. The only thing you have to do is to connect the device to your computer and click Run in the IDE. Beginners can get something up and running within minutes, which includes the time to download the IDE and create a Hello World. The whole workflow runs well, as you get the logs in your IDE or whatever and you can do debugging and so on and it's really not that bad, given that no simulator can match an actual device - there's something to be said about keeping the phone in your hand, rotating it at will and touching it to see how the app feels.

Apple's provisioning process on the other hand is the most painful thing I ever experienced.

> Apple's provisioning process on the other hand is the most painful thing I ever experienced.

Your information is years out of date. In XCode, you click 'use this device for development' and all the provisioning is done fully automatically.

So no. It is not far easier to get your app running on the device itself. That is just false.

I get the impression that everyone in this thread with strong negative opinions, regardless of platform, hasn't spent more than half an hour on the other one.

How you "get your code running" is the most important part of the dev life cycle.

How you *get your code running on a device" is even better. And it's trivial with Android. It's a royal pain in the butt with iOS.

I take it you've NEVER actually developed on iOS before.

The simulator in almost every situation matches the device. And I don't understand how connecting your phone to your Mac constitutes "a royal pain in the butt".

Oh yes I have. Both on iOS and Android.

While suppressing disbelief that this is even something being argued, I present the instructions to run your newly built app package on your Android device:

1) Make sure your the appropriate security options to allow app installs are checked in the phone settings. 2) adb -d install <path to apk> 3) Enjoy the your own app on your hardware you own without asking permission from anybody else

For iOS, start by paying $99 to Apple to register in the dev program. Then go through this tutorial explained with the help of >20 screenshots:

http://mobiforge.com/developing/story/deploying-iphone-apps-...

My company has prototyped on both platforms, and I strongly prefer Android for this purpose. Test flight is significantly more inconvenient for all parties than sending around Android apks. So is Apple's provisioning process for development (you'll certainly have to figure out how to re-provision your development devices a few times).

Android's OS integration also makes for better demos of our app. Since it's a remote control for another device it makes a lot of sense to have lock-screen and pull-down controls. We can't show that off on iOS.

Finally, the Android developers that I know simply don't use the simulator, they always use hardware. I found it strange coming from iOS, but I've gotten used to it. I weight this negative much lower than the deployment advantages that Android has for prototyping.

Of course in the end you'll have apps on both platforms, but here's a vote for doing early development on Android.

I love Android. I really only develop for Android. But to say the Android emulators are better than the iOS simulator (or even comparable) is hilarious to me.

The reason everyone tests on hardware is because the emulator is %@$#ing slow. i7 @ 4.2GHz, 12 GB of RAM... the emulator still takes MINUTES to start and runs unusably slow.

The iOS Simulator on the MBP work gave me (mid-2010) runs at basically native speed.

I do some development with Cordova. During development I either test on my Android phone or an iOS simulator. Those are the only realistic options.

Have you tried using the x86 images with KVM? They're quite speedy.

try using genymotion. it takes 20 seconds on my mbp to starting up.

I'm always surprised when people complain about the slowness of the emulator and they haven't tried genymotion or the x86 emulator.

I mean, they're tools developed for your job, learn to use them!

It would be like coding using a plain text editor.. you can do it, but it's not what you're supposed to do.

Did you think I said the Android emulator is better than the iOS one? I wasn't trying to say that. Maybe I confused the use of "simulator" v. "emulator".

Agreed, the Android emulator sucks and I don't use it. One of its many flaws is that it doesn't support multicast, which is pretty much a requirement for doing device discovery in a remote control app.

With regards to the speed, that's because the Android emulator is an emulator - it's converting ARM instructions to x86. Because of this, the Android emulator is actually a better representation of how apps run on real hardware than the iOS simulator.

There are x86 images available for the Android emulator, which will run as fast as your host machine will allow.

Does real hardware convert x86 to ARM ?

No. So remind me again what your point is ?

What? I can't tell if you're trolling, but I'll answer anyway...

The Android emulator allows you to run applications that were compiled for ARM because it translates the ARM instructions to x86. This is really CPU intensive and can eat a lot of memory as well.

Technologies like Intel HAXM[0] speed this up, which is how the x86 Android images manage to be so much faster than the regular ARM images.

[0]: http://software.intel.com/en-us/articles/intel-hardware-acce...

I'm wondering whether you tried enabling acceleration (http://developer.android.com/tools/devices/emulator.html#acc...). If not, you might find the speedup rather shocking.

It does run on native speed - that's because it's a simulator and not an emulator.

XCode compiles your source code to match your computer, not your phone, when you run the simulator. With Eclipse and ADT you build for an actual device, and then emulates the device running your app. That's why there's a speed difference.

However, when building for connected devices - both XCode and Eclipse+ADT compiles and runs at the same speed IMO.

The problem with the XCode approach is that some implementations can't be simulated (I remember trying to play a video from YouTube, embedded) - and needs an actual device to work. This hasn't happend with the Android emulator for me, because it actually behaves like a device.

At $work we had an IOS application developed. Test Flight wasn't too bad to setup, but it was a bit of a pain having to click the link in the email from within the IOS device (an old ipod touch in my case). Once Test Flight was setup, it was pretty smooth from my end to update, but certainly wasn't as simple as an auto-update in the Play store.

We're not a software shop, but we did make an iOS apps to interface with our hardware. Everyone in the development and testing was asked to jailbreak their phone. We probably had over 20 testers. By the time we reached beta and were ready for wider test market, we used Apple's signing process.

We probably broke some rules and while it's not for everyone, it worked for us. Jailbraking my phone was amazing simple and fast with tools like limera1n.

The easiness with which you can break an iPhone depends on the firmware it has installed on it and the precise moment in time you want to do it - if there's an easy jailbreak solution available or not. If it happens for an iPhone to be updated to the latest version for which there's no known vulnerability, you either have to wait some time for a jailbreak to be available or you have to go through hoops to downgrade it.

For me jailbreaking the phone just to be able to do development on it does not make sense. Why go through so much trouble, when clearly this hostility towards tinkering coming from Apple will likely get worse in the future.

You see, I believe in voting with your wallet (or time, or eyeballs, or whatever). If enough people complained to Apple that the current process sucks, then Apple might do something about it. But if the ones affected simply jailbreak their phones, taking the status-quo as a given and working around it, then Apple simply has no reason to change their policies.

We (developers) tend to have preferences and these preferences end up clouding our judgement. I love Android for example, but I hate it that I can't be a Google merchant on Google Play because of the country I live in. When something sucks, it sucks in spite of all the other things we love, and we really shouldn't let our preferences cloud our judgement.

> My company has prototyped on both platforms, and I strongly prefer Android for this purpose. Test flight is significantly more inconvenient for all parties than sending around Android apks. So is Apple's provisioning process for development (you'll certainly have to figure out how to re-provision your development devices a few times).

Mine has also prototyped on both platforms and I will personally strangle anyone who suggests we do that on Android again. Slowly and painfully.

Sending applications for testing is somewhat more difficult on iOS, but that's really the only gripe we had. Between the useless documentation and the horrible development environment, it consistently takes us about twice as long to get an initial demo up and running on Android. This is especially on UI-heavy applications, considering that Android still doesn't have a decent UI builder.

(Just to put things into perspective: iOS's has incremental/convenience features over the original NeXTStep GUI builder, which basically puts Android's in a pre-1992 state).

The initial costs were higher for the Apple hardware, too, but even in the short term (1-3 months), it was worth it. This is especially true for a small company, that should prefer being punctual and keeping short deadlines.

> Finally, the Android developers that I know simply don't use the simulator, they always use hardware.

I also used hardware when developing for Android. However, that was not because I'm an uberdeveloper who has some obscure skill, it's simply because it sucks. It's slow, the debugger borks every once in a while, the management interface is unusable and while the list of integration features is longer, when you start crossing out those that break every other build you're pretty much left with just starting and stopping the simulator.

Great points (upvoted). It probably also depends on what skills and experience you have in the team.

SoundFocus is using http://hockeyapp.net/ to do distribution of betas. It seems very smooth from my experience.

> This isn't some giant inconvenience that warrants completely switching a platform.

WRONG. Contacting all 30 of your friends and WAITING for them to give you their device UUIDs and giving them long instructions on how to find it from iTunes if they don't know how? How is that easier than sending an APK to your friends which they can simply download and install? And you seem to just have glossed over how it's a waste of money to sign up for an iOS developer license to build an app that, you find out, nobody wants to use.

> why would you start creating OS specific functionality you know will never work on the other platform. It's completely illogical.

Uhhhhhh, what? What do you mean OS-specific functionality? GPS? File reading and writing? Motion sensors? Buttons and text fields? Are you kidding me? Both Android and iOS have those. Do you even own a smartphone?

If you mean iCloud, why is that a problem? Even if you're developing for iOS, you can use Google Drive. If my startup had something to do with cloud syncing, catering to platform-exclusive cloud services isn't illogical.

> iOS is likely to remain the primary platform for prototyping. Why ? Because it is just so much nicer.

I'm pretty sure a "prototype" doesn't have to be "nice."

> The iOS Simulator "just works" and exactly mirrors your target devices.

Again, WRONG. You're not supposed to rely on the simulator precisely because it DOESN'T exactly mirror your target devices. It doesn't have motion sensors, uses your computer's internet connection as its own, uses your computer's processing power as its own, doesn't give you the same retina iPhone experience, etc.

Gee, have you even tried developing mobile apps?

You know, there are dozens of free apps out there that accept an email address as input, and provide a MIME encoded UDID as output.

I know it's a pain in the ass to buy an entire Apple computer just to develop for iOS, but crikey, why are you so angry about it?

threeseed is well known to "favour" the Apple ecosystem and disdain the Google one. In other words, it's trollish

I spent many years in "agency land" developing for iOS, Android, Blackberry, Windows Phone.

If you disagree that iOS is the more enjoyable platform to build for then contribute to the discussion. Otherwise you are the worthless one here.

1)I have a good memory, so I remember clearly that you developed for more than one platform, and, more than that, I remember you complaining about your agency application having to support ALL versions of Android starting from 2.1 (used by less than 1% of the market).

2)It is clearly visible from your comments history that you are biased (and that's ok, everyone is allowed to have a preference, I am biased as well), but also refusing to consider any arguments that go against your views, ergo the trollish behaviour. I especially dislike the way you address your replies. Most of the things that don't make sense to you, have a perfectly reasonable explanation if you only would consider changing your point of view for a while.

3)mattquiros already refuted your arguments on why iOS is more enjoyable as a platform.

4)I already commented elsewhere that as a developer you have to know your tools. Not using the x86 emulator or genymotion puts you in the position of the masochistic developer that wants to prove that the platform is horrible AT THE COST OF MAKING HIS OWN LIFE MISERABLE.

If you would developped for Android, you should have known that you don't simulate a brand.

You simulate application sizes :)

Ever developped for Android, because i doubt so.

Easier collecting feedback and faster "getting it out" iterations to improve your application.

With TestFlight, it's very un-fussy to send test builds on iOS as well. It's perhaps more fussy than with Android (I'm not sure), since you need the people to sign up and add their device to their TestFlight profile, and you then need to add the device UUID to your provisioning profile. But we're still talking about very quick turnaround (like 5 minutes.)

Even easier than that in my experience. We've just been updating the provisioning profile with new devices and uploading the profile to Testflight, then sending testers a TF web link that they can click from their iOS device for ad hoc testing. As long as the UDID is in the provisioning profile, testers don't even need to register for a TF account. It really is a breeze.

On Android you can mail a file, people click on the attachment, click allow installation and they're done.

I'm not saying it's better, in fact I think TestFlight may have many other useful features that this crude method doesn't offer (like tracking the UUIDs)

There are more Android apps than iOS apps, and this advantage has always been present.

So, why aren't Android apps already of superior quality?

Well, so many reasons ... until 4.0 the whole framework was ugly and the tools were very immature compared to where they are now. Few developers, especially ones who care about design, had much or any experience building apps for Android. A lot of early Android developers were either people with no experience at all or iOS developers who tried to apply iOS principles to Android development and failed hard. And it's possible the Android user base in general cared less about design so that in itself was not such a high priority (perhaps this is not so true now).

But aside from all that, this discussion is not really about quality per se. It is about figuring out your business idea, getting it right. Whether you then go and execute it well after that point is a different point.

> But aside from all that, this discussion is not really about quality per se. It is about figuring out your business idea, getting it right.

But surely the same logic applies to this too. Why haven't we already seen all kinds of innovative business ideas emerging through the rapid iteration that Android supposedly enables?

There are probably more innovative Android apps. Problem is nobody cares about the apps that much. When they choose a phone, they choose the phone first. Apps are an afterthought.

iPhone caught on for the phone itself, its ability to browse the web and make calls. iPhone didn't even start out with apps. Even then, apps didn't come into play because customers demanded them.

So you're saying Android users don't care about innovative apps? That makes this whole discussion moot.

I'm saying no users care about apps, or buy phones based on apps.

*no = very insignificant

If that's the point, start your prototype with Appcelerator, or to a lesser extent Kivy. Or popapp.in for that matter.

The dev distribution problem is thoroughly solved by testflightapp.com and I don't see anything else missing.

Reply on news.ycombinator.com