All about the APIs

Posted by: on Mar 20, 2013 | No Comments

For the big “global market” apps at least, it really is all about the APIs. Listening to the latest “Critical Path” podcast with Horace Dedieu, there are some great and compelling speculations. Episode 76 Google vs. Android is really worth listening all the way through for observations about the current state of Android and Google.

The web is doomed. Native will rule. I’m not alone.

Posted by: on Sep 27, 2011 | 5 Comments

A great piece by Joe Hewitt, who writes far better than I. This is pure killer:

The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.

As those of you who read my previous post on the possibility native could eclipse web on the desktop will know, I could not agree more. It’s not something I want, but I believe it may be inevitable. Even if Joe’s mooted guardians/CEOs of “the web” materialised, there’s no guarantee they would produce something compelling enough for the average user to use in preference to native apps.

Joe’s piece is bang on, in that the web geeks of the world are in complete denial of this and the dead weight of design-by-committee that will forever drag the core web technologies down.

Also ties into a tweet that I saw today:

@hnshah: “As far as the customer is concerned, the interface is the product.” Jef Raskin

There are a couple of ways to interpret this, but mine is “customers don’t give a shit how you implemented this or what your constraints are”.

What they see, feel and experience in front of them is what they care about.

Web devs who deny this is the case are just sticking with what they know, and companies sticking to web development are doing this purely for cost reasons that make not one jot of difference to the customer. Seriously, who wants to learn Objective-C, code Android, or Windows or OS X when they can already do HTML + JS? You can see the logic – it’s “cross platform”. It is however self-interest, and this does not drive the software market. The customer does, and the customer is rarely happy in the long term with lowest-common-denominator UX and functionality.

The web offers no gain for the customer whatsoever vs native. The converse is true for native vs web.

Yes I make a living from making web app stuff. For now at least.

The web does not a mobile app make.

Posted by: on Jun 13, 2011 | 4 Comments

This is a rant about the Web vs. Native debate in mobile.

I’m very squarely on the “Native is best” side. Obviously if you don’t have the funds/expertise to make a native app then you’ll choose web – but I would wager this is only viable if you don’t actually want to make money out of the app. Unless you have some amazingly compelling content (like pictures of naked people) that can not be got at by native means.

How Android is just going to be J2ME hell all over again

Posted by: on Nov 20, 2009 | 3 Comments

I’m lucky to be out of mobile phone development now. I spent about 2 years coding J2ME games for a wide range of handsets and as anybody who has done it knows, its really shitty. This is because J2ME has standard APIs, but implementations vary in quality, nuance and in some cases downright fail to meet spec. Not to mention all the phones have different API sets and hardware abilities, input methods, screen sizes that vary wildly¬†etc. Oh and I forgot – bugs across different firmware versions of the same handset – users without iPhones being unlikely to upgrade firmware as it is likely non-trivial / not handed to them on a plate.

I’m an iPhone fan, because iPhone makes mobile phones not suck. That’s all I cared about when I got one.

If I was an active phone developer now, I’d be very happy to dev exclusively for iPhone because of the tools and APIs and low variance in standard hardware. Issues about app store review policy notwithstanding (that’s a serious problem that has to be, and I think will be resolved). If you write good apps there’s easily a big enough market size already to make some good money.

Anyway last night I read this Fake Steve Jobs piece – ever sharp: Developers only now realising that Android is not a platform

You see when writing mobile apps the number of handsets you have to port to and test with (requires owning the phone typically) is key to your financial bottom line. Mobile operators want/force you to make sure your app supports a wide range of their crappy handsets, even if you will sell 1 copy of your app per year on that handset.

Because it is a phone there are few apps for or it has their logo on the phone, you have to support it.

You have to waste days debugging memory use issues – often across many different handsets

You have to waste days working out why your colours are coming out wrong on a crappy handset that has sold in high volumes and has a CPU so slow your game is barely playable.

You have to test every feature of your game/app to completion, with lengthy usage tests, incoming call issues etc to be sure it will not fall over / frustrate the user after a while. A quick flick through = poor QA.

The cost and effort behind this is immense and in many cases a complete waste of time. Generally speaking as a mobile dev you want to target the smallest number of phones that give you the biggest market share of people who actually pay for downloaded apps.

Now even with a unified “app store” for Android, you’ll still have to pander to these same requirements even if there is no network operator standing in your way. Because to make money, you have to follow the high volume handsets. Earth to those new to mobile dev: the highest volume handsets are very rarely the most capable or attractive from a development perspective. After the market matures, the highest volume will be in the cheapest/most subsidized handsets. This will likely be operator-badged “plastic-extruded turd with calculator buttons on” handsets.

This is why the FSJ post is right on the money. The higher iPhone market share grows – and the more global it becomes, because this is a double whammy compared to j2me dev with no mainsteam cross-phone app marketplace – the more attractive iPhone dev becomes. It is just easier to make more money there.

You have effectively one target device (ipod touch may not have mic and no phone but that’s it, 3gs has… compass oooh) and a clean reliable platform. Even firmware issues are almost removed because Apple/iTunes make it so trivial for people to update.

Contrast this with Android. From what I have read, it seems the O/S is not a rigid guaranteed platform like iPhone OS, and of course it is targetted at the mass market of phones. This will mean that the capabilities and APIs and quality of implementations will vary across all the handsets – just like in your old enemy J2ME.

High volume phone makers will try to shoehorn Android into as little RAM and CPU as they can, with the cheapest acceptable screen they can (who cares if everything looks a bit yellow!), to hit the lowest price point to make their handset the most attractive to the network operators so they can hit high subsidised sale volumes. If there’s some problem with a part of an API – maybe the CPU is too slow to do it, or the GPU can’t handle it, or the screen is “4.5-bit CMYK” colour as opposed to 24-bit RGB, they will just cut a corner/break compromise that API and almost certainly not document this. It is commercial reality. It is the classic design down to a price, not up to a standard.

J2ME suffered exactly this problem and Sun couldn’t fix it even though they had a licensing scheme for the VM. Because Google has open sourced Android, I don’t see how they’re going to be able to introduce a “Google Certified Android” standard that requires complete TCK success for all Android deployments.

As such, mobile devs on Android are doomed to the same existence they’ve had for a decade on J2ME.

Each new Android handset means another target to test, often requiring you to buy the handset contract free (ouch!), and the diminishing returns as the market is flooded with new handsets each garnering less of the market for your app.

Of course you’ll still be coding Android apps because manufacturers will be running to unite under an “iPhone beating OS”. Really, all that’s changed is you’re coding to Android APIs instead of J2ME.

I don’t mean to say Android won’t be successful. iPhone OS will not be “the” dominant OS in the mobile phone market any time soon, maybe never.

The thing Android devs have to fear is this: the mass market success of Android. Why? Because the mass market success = high volume = cheap crap phone, not a smartphone. That is where the money will be for Android apps, and guess what – its going to be really pretty ugly. You’ll make a “reference port” on your high end Android handset with touch and lots of RAM and great performance, and then have to downshift everything to the shitsville high volume ones.

So in terms of small developers making money off their apps, I’m very confident the ROI on iPhone will be far more favourable.

Let the big guys deal with the horror of porting and QA teams for all the Android stuff.

Oh, and wait it remains to be proven that Android users will actually pay for apps in any quantity. Apple creates an environment of value where people understand that, generally speaking, you get what you pay for. As FSJ often says… “freetards” don’t get this.

UPDATE: Oh look what just hit the news… one of (if not the) biggest J2ME game devs is scaling back their Android efforts. “It is not as neatly done as on the iPhone. Google has not been very good to entice customers to actually buy products. On Android nobody is making significant revenue,” AKA “freetard” attitude = no money for developers.