Should third party apps be relied on to fix a smartphone?

Published by at

I want to take a little break away from the major Nokia X6 review I'm doing just now to directly address one of the issues that I'm seeing in the comments both of the X6 review and in other products that are reviewed both here on AAS and on other tech sites: the use of third party software to compensate for a manufacturer's omissions.

Let's stick with the X6 in this post – but the principle applies all over. I have a number of design complaints around this smartphone, points that I think are serious flaws in the device. Gapless playback of music is one of them. This is where a music track plays right after the previous, with no interruption. It's a big problem when listening to ambient tracks, new age music or live recordings. 

Nokia's Music Player application does not have this facility (and neither does it support a number of less popular music file formats). “But that shouldn't matter”, write the many commentators... “there's an app for that.” (Yes, they actually ape Steve Jobs).

The problem is that basic device functionality should not be something that is left to third party developers. It is something that the handset manufacturer should be providing as part of the service. Nokia, by relying on people discovering these hacks and tweaks through forums and general knowledge are placing a huge onus on the community. Are they so sure that people can find the app for a certain function, and that developers will make them?

More to my point, are they sure that they want to be pushing everyone to third party solutions that in the mind of the buyers, will “fix” the faults of Nokia's handsets?


N97 and Notting Hillbillies

But the problem I want to talk about here is not one of Nokia's (I'm leaving that broadside for the reviews) but for the attitude that is starting to pervade not just S60 device supporters, but smartphone supporters of all platforms. The notion that deficiencies by a manufacturer are easily fixed because a developer has hacked something in the background is a poor excuse when defending a phone.

Yes, defending a phone. Everyone does it for their favourite device, be it the iPhone, Blackberry, Windows Mobile or Symbian. When person A finds a flaw, person B will hit back with a “don't you know about MysticHack87's KeylockCaptureGuard?”, as if this little bit of code is known to everyone who writes about the phone.

Newsflash, we don't know every bit of software – and even if we did, I doubt that the presumed millions of users of the devices would know about these hacks either. It's hard enough to convince them to install a third party application pushed on them via box material and marketing, how they would be expected to pick up some obscure tweak to how the UI works?

There is a great place for third party software out there; to create new applications for productivity, to deliver brilliant games, to provide software in areas that do not have a populist or global appeal. Making up for the faults in a handset isn't (ideally) the place. Some of my first work was in software on the Psion machines of the late nineties, so I know how great it is to be in an ecosystem where fans are happy to support developers.

Unless the Symbian Foundation were to ship the next build of the OS with a bare system screen and no other applications (which is unlikely, not even the popular desktop operating systems ship with no applications pre-loaded), then both Symbian and the manufacturers between them have a responsibility with the software they ship on the machine. If they ship a poor product with missing features, then by all means have the third party developers step in, but noone should gloss over this with a blasé re-direction to a mystery SIS on an obscure web site.

The responsibility, ultimately, lies with the manufacturer to come up with a product that does not only what it says in the spec sheet, but what the modern customer expects. And to deliver it out the box – something that,  worryingly, does not seem to be happening.

-- Ewan Spence, Jan 2010.