It seems a lot of people conflate form and function. This is happening with recent Apple designs being ripped off by Samsung and other manufacturers.
People typically cite prior art such as previous generation laptops or phones and say Apple copied those.
You will find however that in most (but likely not all) cases this is a class error. Often they think that the functional elements of a design (flip open screen, integral keyboard, touch screen, or home button) represent the total design aesthetic.
Trade dress disputes are about form. People who say Apple just built on phones or laptops of the past are often missing the nuance of design. Angles. Texture. Finish. Materials. Weight. Volume. Proportions. These add up together to create an end result – the design.
Users and particularly developers of Palm’s old line of PalmOS devices will keenly remember that Palm were the only people to get syncing right at the time.
Aside from all the basics, they allowed 3rd party applications on the device AND the desktop to talk to each other directly to sync custom data. I’ve bitched about this before.
As an avid Mac, iPhone, MobileMe and soon to be iPad user, I have to wonder what is happening with this at Apple. My real-world gripe is this:
I was just about to open OmniFocus on my iPhone specifically so that it would sync with the latest data on my MacBook Pro, which is set to sync via MobileMe (using a pretty ugly file based solution). Why am I even doing this? Why isn’t this data synced (a) when I dock my iPhone to sync all the other iTunes stuff, and (b) why can’t it automatically sync wirelessly
Well part (b) is easier to answer, although it is a three-fold answer. First, there’s no background app support to allow automatic sync of the OmniFocus app on the phone. That should be addressed by the Push API functionality except that OmniFocus doesn’t support Push API (server cost to them to do so) and even if they did support Push, iPhone SDK Push is not able to automatically pass the data to the application to force it to sync – the user must acknowledge the event and run the app on the phone manually. It’s a pile of suck, surprisingly, with a real feel of “disconnected device”.
Part (a) is more tricky to answer. It must be trivial for Apple to add this kind of support for direct-to-app syncing. They already have/had Sync APIs for OS X for a long time. Lack of support for this apparently makes no sense.
In conclusion I am very surprised that Apple has not updated the OS X Sync APIs so that:
- Third party apps can sync any data they like to/from the iPhone/iPod/iPad with iTunes as the conduit (that was the concept’s name in PalmOS if I recall)
- The transport for sync is completely hidden from the applications such that sync will happen transparently via Dock, Wifi (direct between devices on local Wifi network), and via MobileMe cloud if the device is not on the same Wifi network.
This is not rocket science after all. And yet we still have to know / think about what networks our devices are connected to, manually make sure we run them frequently etc. It is pretty lame, Mr. Jobs.
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.
I love the iPhone. However there are some shocking failings that persist even after several software revisions. They have particularly managed to completely miss out very basic features of SMS (texting) that every phone under the sun has. I don’t care about MMS and picture message crap – its the basics that matter.
Notable omissions include:
- You cannot forward an SMS you have received to another person
- You cannot send a number/vCARD from your address book to somebody else via SMS. Even my 9 year old Nokia 6100 did that.
- You cannot send an SMS to a group in your Contacts book, without adding each person from the group manually. They added group SMS in an early firmware revision, but didn’t add a way to select just the group and have all members added. Sending a message to 20 people in a group is very boring.
- When choosing the “Text Message” option in address book it does not automatically select their mobile number
- SMS is treated as a separate feature from Phone where dialing, contacts, voicemail are. This is a bizarre and false separation. Contacts appear in the main home screen and in Phone – SMS should be the same.
- There is no “mark all read” option on the main SMS summary screen – so even for short messages you’ve already read in the preview/alert screen, you have to go and view each manually.
This functionality is so basic and fundamentally affects the usefulness of SMS on iPhone.
Come on Steve, give us SMS we can be proud of!
Having just installed the latest firmware I find that Apple still have not fixed the bugs related to updating apps.
Basically when I try to update apps on the phone itself it tries installing it as a new icon instead of replacing the old one, and then fails at the end leaving 2 icons.
If I try to update from iTunes as the phone tells me to, it fails with a hex error code. The only solution is to delete the apps on the phone and in iTunes and use the store to ‘purchase’ them again which now requires an extra step of running ‘Check for purchases’.
Thankfully the SMS and contacts performance improvements are working really well.