

Android vs. iOS: Comparing the Development Process of the GQueues Mobile Apps - jrignacio
http://blog.gqueues.com/2013/07/android-vs-ios-comparing-development.html

======
rogerbinns
Not mentioned are the command line dev tools for working with the device.
adb[1] is really handy on Android. You can easily upload packaged builds, stop
and start apps, transfer files, invoke anything via Intents (am), get a list
of installed apps, and use the shell to invoke other things (eg `pm clear` to
reset an app to first user experience).

Doing the same with iOS development is painful. Apps for the simulator end up
in arbitrarily named directories so you can at least inspect their sandbox and
can be invoked via extremely long command lines. But forget about apps on the
device itself. libimobiledevice has reverse engineered some of it, but for
example there is no way to start or stop an app from the command line.

I was doing some FTUE[2] work on both Android and iOS with a third party app,
and needed to stop it, clear the data and start it again. For Android I just
had to press up arrow and return. For iOS I had to do multiple gestures on the
device, then use an app named iFunBox (really) to manually clear out the
sandbox, and then launch the app again via touch.

[1]
[http://developer.android.com/tools/help/adb.html](http://developer.android.com/tools/help/adb.html)

[2] First Time User Experience

~~~
archgrove
Why not just use the XCode organiser (via AppleScript if you want automation)
to delete applications or download/upload app sandboxes? There's no need to
touch the phone or use "iFunBox" for this.

~~~
rogerbinns
I only care about one file in the sandbox and the organizer doesn't let me
upload/download just that one file. I also can't find upload/download in the
Xcode Applescript dictionary.

The Xcode also only shows a subset of applications. My particular use case is
that other developers have written apps using a library that I have authored.
I then update the behaviour of the library for their needs based on
interactions between the app and configuration for the library.

------
wallflower
Re: CoreData

Every iOS developer has to go through that learning curve. It is part of the
initiation process, unless you want to stick with straight SQLite. CoreData
becomes a merit badge of honor. Every developer has their war stories about
NSPersistentStoreCoordinator, PSCs on multiple threads, threading,
performance, sorting, etc.

Quick note on performance in CoreData. If you need to cache objects that you
use frequently, make your own in-memory cache. CoreData is not optimized for
caching objects.

But really, CoreData, is something most people who move from iOS dearly miss.
Not everyone wants fine grained SQL-level control over persisting data. There
is no equivalent in Android. Nada. OrmLite and some other libraries have
tried. Where most of the Android OR persistence libraries break down is either
m:n relationships or performance or both.

However, times may be a'changing - maybe CoreData and some of its pain can be
abstracted itself - if I were to advise a new iOS developer - assuming their
requirements for persistence weren't too complicated - I'd tell them to go
with Parse for managing backend persistence or
[http://helios.io](http://helios.io) from Matt Thompson (of AFNetworking).

~~~
belthasar
I was able to pick up SQLite much faster than CoreData. It just made more
sense to me.

I was building the iOS and Android versions side by side, so a solution that
was similar in both platforms was important.

~~~
deminature
Core Data, as someone said earlier, has a much steeper learning curve than
straight SQLite, but it pays off in the long run, saving you from writing
enormous amounts of repeating, mindless code. I dread having to maintain my
older non-Core Data-using apps, and am in the process of migrating them where
I can.

I'm in the process of writing the same repetitive database code for an Android
app at the moment and would love a (high quality, I've tried a few bad 3rd
party libraries) Core Data equivalent to use.

------
fotcorn
I can't understand why people always complain about the performanceo of the
android emulator. With an Intel X86 image and activated hardware acceleration
(GPU & CPU KVM or HAXM), the emulator is much faster than an actual phone.
Installation Guide by Intel: [http://software.intel.com/en-
us/articles/speeding-up-the-and...](http://software.intel.com/en-
us/articles/speeding-up-the-android-emulator-on-intel-architecture).

~~~
rogerbinns
I had several problems with the emulator not doing audio recording and
playback the same as real devices. Often they don't have the google apis or
voice recognition either.

I must admit I haven't found it a big deal to use real devices. I also use
Wifi ADB so I don't actually need to mess with cables.

Compared to those long intel instructions, switching simulators on iOS is
trivial. I also found them mostly bug compatible with the devices - ie the
same bug would appear on both. The Android emulators have historically
diverged (I remember the 2.3 days when javascriptinterface on the webview
would crash in the emulator but not the real device).

~~~
archivator
AOSP is different from OEM builds. It's not an emulator problem, most of the
time. The folks at Genymotion seem to be working on fixing that with
preapproved builds and more powerful controls.

~~~
rogerbinns
The acronyms don't really matter. What I need to know is that a bug
encountered in the emulator would also occur on the devices and vice versa. If
that doesn't happen then the emulator becomes yet another platform with a
differing set of unique bugs.

~~~
archivator
Agreed. Unfortunately, that's a guarantee that Android's licensing model can't
provide. Every manufacturer can do whatever they please, so fragmentation
can't be regulated.

------
cageface
The thing you realize after writing a few mobile apps is that most of them are
really just glorified CRUD apps. Grab something from a web service, stuff it
in a table view, let the user fiddle with it, post changes to web service etc.
And overall I've found writing those kinds of apps easier in Android. The
framework is, for the most part, at a higher level of abstraction.

However, if you want to do something a little more interesting, particularly
with any kind of interactive multimedia, then Android makes things harder or
downright impossible.

------
thomasjoulin
> "Complex" Layouts"

> Neither Android or iOS support this "Flow Layout" natively

I don't know about Android, but iOS has just that :
UICollectionViewFlowLayout. It would be trivial to implement a tag list as he
did.

~~~
aa0
Was just about to post this. Also, IB is great and constraints are easy to
manage once you realize that it's a calculated ruleset that enforces
unambiguous constraints. The iOS framework is beautiful, and the author
favored Android mostly due to his inexperience with both platforms.

~~~
robmcm
Is that therefore a failing in the apple documentation, or perhaps not meeting
the conventions with other frameworks and languages out there?

~~~
rimantas
There is no failing in documentation. The framework is the same (UIKit), and
in fact the API is a lot like that for UITableViewController—the cornerstone
of many iOS apps.

------
sdogruyol
I seriously think this one is kinda biased. I've been a long time Android
developer and working with ios devs in parallel. Recently it's true that
Android development is becoming a better experience but still not even close
to ios. Have you ever really experienced shitty jar mismatchs or wrongly
generated R files or trying to fix that shitty class paths ? Those are really
making Android development xp shitty and painful.

~~~
cageface
I've had none of those problems. I made the decision early on not to use
Eclipse though. Maybe that helped?

~~~
jordanthoms
These problems are largely due to the eclipse android build system being a bit
of a hack.

This is changing though - android studio (and soon ADT in eclipse, IIRC) are
using a totally new build system based on Gradle, which is awesome.

------
LinXitoW
Almost all my mobile development experience(of which there isnt much to start
with) has been acquired via PhoneGap, meaning i only did native if absolutely
necessary.

The biggest issue and something that has gotten me into a state of white-hot
rage has been Apples certificate/provisioning profile nonsense. I don't think
I've ever gotten a profile to work from the get go, even just for
development(a requirement thats positively ludicrous). That's why I generally
develop/test on Android first.

Seriously, I've managed to require a whole week just because of some
certificate snafu.

~~~
eddieroger
I agree that the certificate and profile thing is confusing when you are
getting going, but I think a lot of that was exacerbated by not using the
native toolset. Xcode handles a lot of it for you (with more and better
support coming in Xcode 5), and point you in the right direction for things
you have to do alone. Plus, there is loads of help on the 'net about doing
this stuff in Xcode because everyone has to, whereas PhoneGap's user base is
lower, so less out there. I wouldn't say it's overly complex, but it is by no
means simple.

------
ohwp
This is why I like Xamarin Studio. You can reuse like 50% of your code base
for both Android and iOS [1] (if you strictly keep the view separated from
business/logic).

Yes the Android emulator can be very slow but testing on a real device is very
quick without the hassle of certificates.

[1] Windows and Blackberry as well

~~~
yulaow
True if you pay a not insignificant amount of money to get both xamarin.ios
and xamarin.android.

~~~
yareally
I haven't tried either yet, but there's jRuby for Android via Roboto[1] and
MobiRuby[2] for iOS. Both are free.

[1] [http://ruboto.org/](http://ruboto.org/)

[2] [http://mobiruby.org/](http://mobiruby.org/)

------
coldcode
No matter which side you work on if you put the effort into learning how to do
it right and use the tools the way they were designed to it becomes so much
easier. XCode 5 is a massive improvement. Jetbrain's involvement in Android
dev made it so much more palatable.

------
tluyben2
The article kind of matches with my experience. And I as well enjoy working in
vim more than Eclipse / Xcode. As I have significant experience with Eclipse
and with VisualAge before that, Xcode took some getting used to. The coding
part is ok, but for anything else (which I found out only after doing a real
project in it) it is horrible. I cannot count the times I have to kill Xcode
and restart it because things which were properly done just didn't work. The
Stackoverflow answer to those things usually is; restart Xcode. That kind of
behaviour, to me, makes it a horrible and unpredictable IDE to work with.

On a previous stable version I had to suffer a month without code completion
(well broken code completion) and there were many complaints online about it,
but no fix (at least none that worked for me). This did teach me to memorise
more and type faster.

Also half-baked things like Storyboards & IB which you cannot really use for
actual apps because you need code to add images, custom fonts etc to controls
and the often buggy code generation for Coredata makes me think that this has
no priority for Apple. It feels outsourced (as in, thrown over the fence with
a vague spec) and more neglected with every new version, making me think it's
some kind of arrogance; let developers do everything the hard way, they cannot
do without us anyway. Every story and tutorial I read seems to back this up;
working around the quirks in the toolchain instead of the tools helping you. I
keep wanting to believe i'm doing it wrong, but I haven't met anyone yet with
a better experience.

~~~
cageface
Xcode 5 is quite a bit better, although I'm with you on not liking
storyboards.

~~~
tluyben2
Good to hear; I have the developer preview, but I didn't dare to try it yet
for anything serious. I'll try it for the next project. Maybe it's final by
then.

~~~
chrisdevereux
Just one datapoint here, but I've found the v5 betas to be faster and more
stable than most of the v4 releases.

------
ratsimihah
> and my Objective-C coding was limited to the two games. So I basically
> started with an equal blank slate on both platforms.

It's not like game dev is one of the most complex kind of development and
requires game design as well as low-level graphics programming skills.

~~~
pmelendez
>"It's not like game dev is one of the most complex kind of development and
requires game design as well as low-level graphics programming skills."

Depending on the game that you are making the developing is not necessarily
complex nor require low-level graphics programming skills, especially now that
you can find high quality open sourced game engines out there.

------
gcb0
The gripe i have with android is that the IDE is essential. and it does not
work very well.

You can't find documentation or do with easy most things without the IDE. and
the IDE often assumes things that get you by surprise, such as saving the
project files when you change something in a preference dialog, and not
providing a Undo for that, and not telling you all the files modified by such
action.

~~~
venomsnake
Try android studio. It is based on InteliJ - I find it much more pleasurable
than Eclipse. It also under very rapid development and has vim style plugin.

Although still IDE I think you will find it better than Eclipse.

~~~
gcb0
I tried. my experience:

    
    
       1. download version 1.0
       2. create hellow world
       3. close it.
       4. open, get notification for 1.1. install it.
       5. IDE complain that my hellow world program is bogus.
       6. i can't open or import it.
    

so, yeah, bad first impression.

disclaimer, i have some rather complexes projects with android, none using
Eclipse or IDE. vim and the android cli stuff. So, not a clueles beginer
clicking away on the IDE, but maybe the oposite, maybe i tried to mess up with
the details more than the IDE was confortable with

~~~
biafra
There is no Version 1.0 of Android Studio. The newest version is 0.2.2.

What did you install?

~~~
gcb0
Replace 1.0 and 1.1 with whatever actual versions it was first announced and
the subsequent update two or three days later.

~~~
venomsnake
I would say it has moved great deal from there. And even if it is not good
enough yet keep an eye on it - the pace of improvement is incredible from what
I see.

(only hobbyist android development here)

------
enrmarc
More than 20,000 lines of code. In my opinion that's a lot of code for this
kind of apps. What a pain to maintain such a codebase.

------
bradshaw1965
I think it's likely that a particular community, language, tooling combination
is likely to resonate with a particular person. Although reading a few well
reasoned articles might give you a hunch of which one to choose, it's likely,
barring external forces like occupation or marketplace requirements that
you'll know until you plunge in and try it for yourself. I appreciate the
article, seems well written and reasoned, but I wouldn't want to read too many
more like it before I just dove in and found out for myself where I felt most
happy, efficient and expressive.

------
tluyben2
For the float:left and such wouldn't
[http://www.pixate.com/](http://www.pixate.com/) be a solution? I haven't
tried it yet, but will do for my next app.

------
hnrandom
> I finally ended the pain by taking all layouts out of IB and simple wrote
> them long-hand with pages of boiler-plate code.

Mother of god. Simply using layout constraints instead of auto layout would
have saved > 1000 lines of code I would estimate.

