Android vs. iOS: Comparing the Development Process of the GQueues Mobile Apps | Hacker News Reader

Android vs. iOS: Comparing the Development Process of the GQueues Mobile Apps

blog.gqueues.com

112 pointsjrignacio66 comments

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

[2] First Time User Experience

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.

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.

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 from Matt Thompson (of AFNetworking).

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.

While there is a license for commercial use, db4o[1] might be a good alternative on Android. I'm not sure what CoreData is personally (sounds ORMie), but this tool is an embedded object database. Fairly quick. The con is it will increase your app install size.

1 - http://www.db4o.com/android/

I was able to pick up SQLite much faster than CoreData.

This is what we did, but then we ran into growing pains of stale objects etc... with SQLite and moved to CD. CD is so much nicer to use and it's something I miss when working on the Android version of our app.

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.

How do you feel about MagicalRecord for alleviating CoreData pain?

I love MagicalRecord. Not only it makes working with Core Data much easier, it makes writing Core Data unit tests a joy.

For those who don't know Magical Record, here's basic a tutorial:

http://ablfx.com/blog/article/2

It's worth checking mogenerator as well:

https://github.com/rentzsch/mogenerator

http://raptureinvenice.com/getting-started-with-mogenerator/

I love the helpers for fetching and creating records that MagicalRecord gives you. But MagicalRecord also has ideas about how you should structure your ManagedObjectContext hierarchy. In the older versions (which we're still using) it was simple with just a separate context per thread which is connected directly to your persistent store. But the latest version (at least last time I checked) is much more complex with multiple child contexts rolling up to your persistent store.

I would prefer to just use the helpers and setup my MOCs and persistent store myself.

There are a few open source libraries for managing CoreData from a higher level now (like NSOperation for GCD).

This post by Mattt Thompson (of course) on NSHipster has links to wrappers, adapters, synchronizers and utilities for working with CoreData: http://nshipster.com/core-data-libraries-and-utilities/

I highly recommend reading that before starting any CoreData project, and reading over that whole site in general to add new tools/concepts to the Objective-C and iOS Framework toolbelt.

    >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

As I start to get into mobile development I've been trying to figure out using backend services like Parse or Azure Mobile Services are feasible for about 99.9% of the apps out there over the long term.

Skipping native storage in favor of a cloud provider ties you to a recurring cost (albeit probably small) and if your app fails to monetize, assume free with in app purchases, at the level required in which to sustain the costs of the overall cloud costs incurred by the apps' users then at some point down the road everybody may get cut off if the developer decides to stop paying for the cloud infrastructure.

This has made me feel like single purchase apps with a cloud based back end data piece are ultimately a ponzi scheme as the recurring costs for the early adopters are consuming the revenue from later purchasers.

Could there be a possible Parse-pocalypse in the not too distant future?

I'm still working on my first app so my concerns maybe totally off base, I'd love to hear from more experienced developers.

At this point, unless I'm going to be dealing with large (n>5000) data sets, I just use NSKeyedArchiver and serialize/deserialize all my objects to a file.

Might not be as fast as CoreData, but is sure a lot easier to code and it's fast enough that the user never even notices.

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

As for me Android emulator could not even start in >30 mins. I always tested on real device.

If your emulator takes more than 30mins to start i would suspect there are different problems than the speed of the emulator. For me even the slow (non Intel X86) emulators never take more than a minute or two to load.

Me too, and once it's open just leave it open and just start and stop the actual app. No need to reopen the emulator each time.

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

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.

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.

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.

An useful tool for android emulation was http://androvm.org/blog/download/ now genymotion http://www.genymotion.com/

If you feel comfortable installing an Intel hypervisor on your Mac. I do not.

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.

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

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.

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

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.

AutoLayout in IB in Xcode 4 was an absolute nightmare. Easily one of my most frustrating dev tool experiences ever.

It's much better in Xcode 5.

A UICollection view is complex solution compared to the CSS equivalent of "float:left", or "display:inline-block".

Furthermore, you will be responsible for resizing the collection view and its sibling views or getting auto-layout working correctly to do part of this for you.

In the tag layout, it would be about as easy to just write line-wrapping code by hand, than to use a UICollectionView.

> In the tag layout, it would be about as easy to just write line-wrapping code by hand, than to use a UICollectionView.

Possibly but the code you would be writing for UICollectionView would be mostly boiler plate. All the layout would be handled for you. Updating a few parameters would be quite easy and you could do it via IB or via code. Once you wrote this once it would also be quite portable.

> All the layout would be handled for you.

No it won't. The tags are variable width, you have to implement something like sizeForItemAtIndexPath. You also must monitor the height of scrollable content region, so you have to monkey patch the collectionViewContent size (or KVO a non-public property), so you can resize the collection view and have the outer controller layout the subviews.

Collection Views don't really make sense when the collection view shouldn't scroll.

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.

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

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.

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.

I just keep trying some combination of deleting and adding new certificates until it starts working. Most of the time I'm unable to tell the difference between what wasn't working and what for seem reason has begun working.

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.

Using XCode will probably fix all your issues for development. For a build server look around for a ruby script that can pull down the provisioning profiles on every build. Very useful.

This is my certificate/profiling debugging workflow - most of which Xcode does for you, btw:

1. Is your certificate expired? Yes - renew it obviously.

2. Is your provisioning profile a wildcard (com.company.*) or specific to an identifier (com.company.id)? If it's specific to an id, and your app isn't using that id change it to use it or use the wildcard provisioning profile (really just do this anyways).

3. Does the provisioning profile list your Certificate under Teams? If not, make a new provisioning profile that is wildcard and lists the dev certificate under Teams.

4. Does your provisioning profile have the device you're trying to build to listed under it? If no move on.

4a. Is your device added to the Portal? Do this through Xcode's Organizer, there's a little plus button to add to the provisioning portal. If yes, move on.

4b. Edit the provisioning profile to also account for your device (use the checkboxes), download the new version of the profile and add it back to Xcode.

Voila! You should be free to build to your device.

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

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

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/

[2] http://mobiruby.org/

If that amount of money saves half of your time...

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.

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.

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

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.

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

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

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

I imagine this is more in reference to his experience with the languages, not programming. Taking a guess, I imagine most of his time wasn't spent writing Obj-C, but rather C. In this case, there was very little he could carry over when developing the iOS app with Cocoa.

The games he wrote were a bluetooth enabled card game and simon says. (check the link) These would use different iOS APIs but are not complex and do not require low-level graphics programming skills.

The bluetooth card game is actually a tutorial level kind of thing. Ray Wenderlich and Apple's own docs have a version of it.

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.

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.

Android Studio is amazing. Easy to install and get running and its a great IDE. I can't imagine going back to Eclipse or a regular editor.

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

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

What did you install?

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

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)

I've been switching from Eclipse to intellij/ android studio recently - the difference is amazing. It's so much faster (like way faster), and still far more powerful, and even looks nicer. A few things are a bit harder to find, but that's just because I've been using eclipse for longer.

Now they just need to add NDK support and I'll be able to switch to it full-time :)

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.

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.

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

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

Reply on news.ycombinator.com