Having spent so much time now on our MazeCard loyalty program, I thought a "behind the scenes" blog entry would be most appropriate. MazeCard is all new age and hi-tech, and while humble as it may not sound, I think we've really cracked the nut when it comes to customer relationship management.

A lot of time and money has been invested, and a lot of technology has been poured into the cauldron. Our team has built applications using Java EE, JSF and smartphone apps for both Android and iPhone platforms.

You often see unsubstantiated blogs and articles on the web about X vs Y. More often then not, it involves a bunch of people with clearly too much time on their hands running some esoteric tests on things that have been lent to them for a day. But in order to do a true, objective review, you really need to get accustomed to the product, learn all of its idiosyncrasies, find its character, and then make your qualified judgement.

Getting on a first-name basis with some Apple and Samsung products, I thought, gave me the right to rekindle the Android vs iPhone debate, but this time on the developer front.

Documentation

Android and iOS are both mature, well-established technologies with a large following. Documentation is available on both products, but as it tends to be these days, be prepared to browse forums and (hats off) Stack Overflow to get the answers you're looking for. You'll be amazed at how little both Google and Apple have done to make their documentation gospel. Looking at the manufacturer's docs is just a way of getting started, and a poor one if that. You'll get your foot in the door sooner if you follow a tutorial or curl up with a decent intro-level book on the topic. When it comes to API documentation, their own mother couldn't pick them apart - both products are equally bad.

Interestingly, while the judgement seems equal, one defendant has a much better time serving their sentence. Because Android is built using the open, ubiquitous, Java technology, it enjoys large scale reuse of class libraries and 3rd party documentation resources. More on that later.

Development environment

No contest there; if tooling is important to you then Android is where you'd be. Compared to Eclipse, XCode is not mature enough and not nearly integrated enough to pass for an IDE, given that the letter 'I' stands for... well, you know. You often find that doing things in XCode requires interrupting your work flow and going off to other remote, less inhabited, corners of the IDE. Things in XCode seem bolted on, for want of a better term.

Eclipse, on the other hand, is a brilliant IDE. Syntax highlighting, incremental compilation and a proper debugger really slash the time to market by a very considerable amount.

Language

Android: Development is done using plain Java. Although it is not technically Java SE, because it is a knock off Oracle's APIs, it is as Java SE as it can be. Dalvik (Android's JVM) doesn't consume bytecode directly, but something very similar (albeit more compact) which is built automatically for you when using Eclipse. You can even reuse any of the existing class libraries without access to the source code: just take the library JAR file and stick it on your classpath, as you would with any other Java application. No cross-compilation required. In one word: neat.

iPhone: Taking ANSI C and tacking on some object-oriented enhancement would have been a clever move 20 years ago. Today it sounds more like an April fools joke and, what's more amazing, it is "not a joke" (to borrow a famous quote). Unless you feel nostalgic for header files and code-compile-wait-fix cycles, stay clear of Objective-C.

PhoneGap: Ah, the revelation! Why build a mobile app in a pagan language like Objective-C, or even a modern OO language like Java, when you can use a true ubiquitous, platform independent language and target all platforms at once? What's wrong with Javascript and HTML, the folks at PhoneGap have asked? Indeed, they were right, and despite working with Java for the last 11 years of my life I couldn't help but agree. So we abandoned both Java and Objective-C and never looked back.

Publishing

If you're an Apple fan reading this blog, you might subconsciously be hoping that somewhere there's consolation for Apple and that Apple might not have completely lost this bout, or at least not by a great margin. And here comes the knock-out blow. Apple's distribution process is 3rd world, bronze age or any other metaphor that could be used to indicate a complete and utter loss of touch with the modern way. As far as redemption goes, the buck really does stop here.

Joining the developer network

Both products require developers to officially (read: pay money) be part of a developer community before they can upload apps.

Google Play: 5 minutes and $25 later, you've got full access to the Android developer network, with the ability to sign and upload apps.

App Store: Start by faxing your company details to apply. Email won't do. If you're an established company, this might be a minor irritation. But if you're a startup, this is a real inconvenience. A week later your application is processed and you are admitted, but only after you part with $99.

Signing apps

Both products rely on a security model which requires apps to be signed before they are deployed to the device. This provides a fair degree of confidence with respect to the source of the app.

Android: Right-click in the Eclipse project and select 'Export signed application package'. The two-page wizard will take your through setting up your keystore and presto, the application is signed.

iPhone: It turns out that Apple didn't think that developers would be selling their apps, so they didn't build XCode to handle this extremely unlikely event. You have to change the build settings to allow for signing. Start by reading Apple's documentation. Then, stop reading it because it doesn't make sense. Some of the sentences were not grammatically correct, and overall the documentation lacked polish. Luckily, Stack Overflow will provide you with some answers. It took around an hour and a couple of passes with two people working on this to get it right.

Uploading the app

Uploading is a fairly crucial step, as one might imagine, to distributing the app.

Android: Create an application profile in Google Play and upload the APK file that was produced during the previous step.

iPhone: Create an application profile in iTunes Connect. Build a distribution archive in XCode. Expect to visit documentation on using the archive organiser because intuition won't help you.

Publishing the app to the public

Google Play: The app is available as soon as the APK file is uploaded.

App Store: The uploaded app is subject to review, which can take 5-10 working days.

While the amount of bureaucracy in Apple's processes is staggering, some of it can be mitigated by chasing Apple early in your project. Apply for a developer account on day one, and as soon as you've got a torch app, stick a 1.0 version on the app store. Hopefully, it will be accepted by the time the rest of your app is complete. Getting subsequent version releases approved won't take that long.

Finding your app

Both distribution networks require around 24 hours to re-index their apps, so don't expect your app to appear in search query results in the native application until the next day. Things are a little different in the web version of the store.

Google Play: the app is searchable in the online version of Google Play, as well as in the native version.

App Store: you must access the native version of the App Store (the one available on your device) in order to see your app. iTunes - app store's web equivalent - won't display your app unless it has been heavily downloaded. Amazingly, Google will still find your app in iTunes, even though iTunes' own search facility does not. Is this a tribute to Big G web crawling ability or a sucker punch to the fruit store? You be the judge.

Conclusion

Apple and Google are both commercial success stories, but the way they go about their business is radically different. Google attracts business through openness and maximising opportunity for people to participate. Apple is equally successful in sticking to a highly proprietary model which clearly pampers the consumer, and attracts developers through lack of choice. It's clever, I'll admit it. As it stands, it is not really up the developers to make a decision on whether to support or abandon iOS, because if it were, they would all migrate to Android in the blink of an eye. But as long as Apple keeps dazzling their followers with their marketing prowess, the developers will follow.

Focusing one on the end-users at the expense of the people that make it all happen is not a tactic that remains effective perpetually. The increase in competition in the smartphone market, with the introduction of products such as the Nokia Lumia and BlackBerry 10, as well as game-changing technology such as HTML 5 and PhoneGap will significantly erode Apple's stronghold on the market, which has already taken a pounding from Google. HTML 5 and PhoneGap allow apps to be written in a platform-neutral language and be ported from one platform to another in a matter of days, not months. Where the lack of apps used to be the biggest barrier to entry, now anyone with access to a fabrication plant can produce a smartphone, stick a Webkit browser in it, and take a stone out of the Great Wall of Apple.

P.S. While it may appear so, I am not prejudiced against Apple. I have four Apple products and wrote this entry on a MacBook Pro. If anything, I have a good acquaintance with a broad range of Apple's offerings and an understanding of Apple's philosophy when it comes to end-users and developers.

Like this blog? Support us publicly. Click the links below: