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.
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.
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.
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.
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.
There are x86 images available for the Android emulator, which will run as fast as your host machine will allow.
No. So remind me again what your point is ?
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 speed this up, which is how the x86 Android images manage to be so much faster than the regular ARM images.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
While software engineering is hard as a discipline, I don't feel it is the hardest part of building a startup.
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.
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".
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:
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)
The dev distribution problem is thoroughly solved by testflightapp.com and I don't see anything else missing.
So, why aren't Android apps already of superior quality?
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 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?
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.
*no = very insignificant