6 ms·

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

by slewis 13y ago

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.

nucleardog 13y ago
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.
- charleslmunger 13y ago
  Have you tried using the x86 images with KVM? They're quite speedy.
- yla 13y ago
  Hay. Have you tried Genymotion (http://www.genymotion.com/ http://www.genymotion.com/). It's really really fast. Currently, they only support for Android 4.+ emulators but they will support the lower api soon.
- antback 13y ago
  try using genymotion. it takes 20 seconds on my mbp to starting up.
  - BitMastro 13y ago
    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.
- slewis 13y ago
  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.
- wldlyinaccurate 13y ago
  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.
  - threeseed 13y ago
    Does real hardware convert x86 to ARM ? No. So remind me again what your point is ?
    - wldlyinaccurate 13y ago
      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-accelerated-execution-manager/ http://software.intel.com/en-us/articles/intel-hardware-acce...
- clhodapp 13y ago
  I'm wondering whether you tried enabling acceleration (http://developer.android.com/tools/devices/emulator.html#acceleration http://developer.android.com/tools/devices/emulator.html#acc...). If not, you might find the speedup rather shocking.
- bjrnjs 13y ago
  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.
- deleted 13y ago
  [deleted]
ajtaylor 13y ago
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.
slacka 13y ago
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.
- bad_user 13y ago
  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.
weland 13y ago
> 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.
- slewis 13y ago
  Great points (upvoted). It probably also depends on what skills and experience you have in the team.
- mentat 13y ago
  SoundFocus is using http://hockeyapp.net/ http://hockeyapp.net/ to do distribution of betas. It seems very smooth from my experience.

by slewis 13y ago

nucleardog 13y ago

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.

charleslmunger 13y ago
Have you tried using the x86 images with KVM? They're quite speedy.
yla 13y ago
Hay. Have you tried Genymotion (http://www.genymotion.com/ http://www.genymotion.com/). It's really really fast. Currently, they only support for Android 4.+ emulators but they will support the lower api soon.
antback 13y ago
try using genymotion. it takes 20 seconds on my mbp to starting up.
- BitMastro 13y ago
  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.
slewis 13y ago
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.
wldlyinaccurate 13y ago
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.
- threeseed 13y ago
  Does real hardware convert x86 to ARM ? No. So remind me again what your point is ?
  - wldlyinaccurate 13y ago
    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-accelerated-execution-manager/ http://software.intel.com/en-us/articles/intel-hardware-acce...
clhodapp 13y ago
I'm wondering whether you tried enabling acceleration (http://developer.android.com/tools/devices/emulator.html#acceleration http://developer.android.com/tools/devices/emulator.html#acc...). If not, you might find the speedup rather shocking.
bjrnjs 13y ago
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.
deleted 13y ago
[deleted]

ajtaylor 13y ago

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.

slacka 13y ago

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.

bad_user 13y ago
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.

weland 13y ago

> 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.

slewis 13y ago
Great points (upvoted). It probably also depends on what skills and experience you have in the team.
mentat 13y ago
SoundFocus is using http://hockeyapp.net/ http://hockeyapp.net/ to do distribution of betas. It seems very smooth from my experience.