iPhone

John Gruber has posted a really interesting and insightful piece on BlackBerry vs. iPhone, and why he thinks that RIM is, fundamentally, in a very very bad place indeed.

However, there’s one point that I have to disagree with John on:

“In broad terms, BlackBerrys are optimized first for email; the iPhone for the web. What’s more important, an email client or a web browser? For most people, and perhaps even most current BlackBerry users, the answer is clearly the web.”

For the majority of business users, I think John has got this completely wrong. For them, the ability to send and receive emails, and view the attachments which come with them, is far more important than web browsing. Witness the number of users who spend their time in meetings thumbing their BlackBerry.

That’s not to say that John is necessarily wrong in his overall point that iPhone is going to eat RIM’s lunch. But in optimising for email, as John acknowledges, RIM are actually delivering something that’s far more desirable for business than a device that’s optimised for web.

I’m really enjoying using Brightkite at the moment (I’m ianbetteridge if you want to friend me), and I’m pleased to see that the iPhone web application has now been released in alpha form.

But I was even more pleased to see this comment from one of the developers on the Brightkite blog:

“The native iPhone application with core location (cell triangulation, GPS) is in the works. Checking in will become much easier. We will be releasing it in June through Apple. There are no plans to release a jail broken version as of right now.”

With Jaiku effectively stalled, Brightkite looks a nice solution for location awareness. Plus, it integrates with Fire Eagle, which is great.

Apple Adds Chinese Handwriting Recognition in 2.0?:

“A sign of things to come? Or just another in a long list of iPhone rumors? It appears
that Apple has included Chinese Handwriting Recognition in the iPhone 2.0 Firmware
Beta according to MacRumors.com.
Chinese users can apparently draw a character on the screen with their finger and
then choose from among options for the recognition.”

(Via GottaBeMobile.com.)

Now this is worth looking forward to:

“As mentioned toward the tail end of this morning’s liveblog chat with Rogue Amoeba’s development team, there is a version of RadioShift in the works for the iPhone and iPod touch; the proof is in the (video) pudding. You can see the full-res QuickTime here.”

TJ makes a point which is well worth making in the discussion over whether Apple should loosen the restrictions on background processes in the SDK:

“With these restrictions, Apple continues to do its best to protect itself against one of the iPhone’s biggest drawbacks, the lack of a removable battery. The lack of 3G, true GPS, and now background mode have all been explained away (largely, but not exclusively) on the basis of ‘They would be hell on battery life.’ Curiously, I haven’t seen a lot of push-back pointing out that the battery restrictions are only necessary because of the way that Apple designed the iPhone.”

There is no ease-of-use case for having a non-replaceable battery in the iPhone. It’s an aesthetic choice which actually reduces the usability of the product. And this fact undermines the case of people who claim that Apple only cares about the welfare of the user and should do everything to protect it.

As TJ also points out, there are other ways of protecting users from the potential of installing applications which reduce battery life:

“For example, apps can be run in “Background Mode” could be required to ship with preference turned off, and turning it on could pop up a warning message:

“Running in the background will decrease battery life. Do you want to enable Background Mode? [Cancel] [[Enable]]”

Apple could adapt a notice from AIM on Windows (please, contain your shock and horror). When you go to close the AIM window on Windows, it alerts you that the app is still running in the background. Given that the iPhone only has one button to pull you away from your app, it wouldn’t be too difficult to trap a button push and have a notice pop up:

“Leaving iChat will prevent you from receiving instant messages unless you enable background mode. However, background mode will increase battery usage. [Cancel] [Enable Background Mode] [[Quit iChat Anyway]]”

Are these brilliant UI ideas? Certainly not. I’m sure Real Mac Developers are still recovering from the idea that we might adapt anything that Windows does. Others might recoil at the idea that pressing the iPhone button would do anything but immediately bring up the Springboard.

My point isn’t that Apple should do any of these things; however, the idea that background mode would necessarily have to be done completely without any communication to the user is bunk.”

The comments on my earlier posts about this show that people aren’t really thinking creatively about the problem. Instead, they’re taking the line that “either Apple bans background processes or battery life shrinks to nothing”.

And TJ sums things up better than I could have:

“There are ways of addressing these potential problems that go beyond Apple’s blanket “No, You Can’t” and we, as customers and users, are perfectly within our rights to expect Apple to listen to us. Sticking their fingers in their ears and pretending not to hear us, or nodding and smiling while patting us on the head and saying “Trust us, you really don’t want what you think you want, because that non-swappable battery we gave you can’t handle it” is not for us.”

[Moderator] No iPhone SDK discussion here please:

“Reposting this just to be crystal clear.

iPhone 2.0 SDK is entirely covered by NDA, including the documentation. All of it requires login to access it at the iPhone Dev Center.

Items specifically discussed in the announcement are public. But even still, they’re not appropriate for discussion on this list.

Please stay tuned for more details.

Comments, complaints, etc to email@hidden

Thanks for you cooperation.

Scott
Tech Pubs
Apple Inc.”

Can someone explain to me what the justification of this is? Competitors getting hold of it? Like Microsoft, say - which is undoubtedly a registered Apple developer? Or Nokia? Because of course it would be completely beyond them to get hold of a copy - they’d rely on public discussion of it for all their info.

This just smacks of “we don’t want you guys talking about the limitations of this SDK until it’s released, please, so we can control the PR around it.”

John Gruber responds to my earlier response on the iPhone and background tasks:

“What’s wrong with ‘since now’? A new platform can’t be innovative if it isn’t different.”

To which the correct answer, of course, is “nothing”. Apple can, indeed, decide that it’s now going to take responsibility for the behaviour of all applications on my machine. And, if Mike Ash of Rogue Amoeba is right about where Apple’s going with code signing then it may well do the same thing for the Mac going forward.

But if that’s the future, then I’m going to have to be excused from it. I am responsible for what gets installed on my machine, and I don’t want to be protected from the consequences of my occasional stupidity if the price is to hand all control over to Apple.

John goes on to my second point:

Imagine a scenario where background apps are allowed on the iPhone this summer. Some typical user buys and installs 10 apps from the App Store. Three of them are background-capable apps, and two of those three are so resource hungry that they have a noticeable drag on battery life. How are typical users — not Ian Betteridge, not me, and probably not you, but typical users — supposed to know which apps are causing the problem? How are they even going to know which apps do continue to run in the background? They won’t. A likely reaction would simply be to regret ever having junked up their iPhone with any third-party apps at all.

The problem is that me, John and his readers are far more typical of the kinds of user who will go crazy and install ten applications all at once than is the average non-geek phone user. The average non-smartphone user is going to install a game or two, maybe an IM application, and that’s probably it - partly because they’ll want to save much of that 8Gb memory for their photos, music and video, which is what they bought the phone for in the first place. He or she is not likely to install ten massive memory-hungry applications which constantly run in the background.

Or imagine a situation where a user installs five background-capable apps, none of which, on their own, significantly affect system-wide performance or battery life, but which in combination all running simultaneously, do. They’re all using RAM, all using the CPU, and all periodically using the network. What’s the advice for the typical user supposed to be? ‘Have fun with the App Store, but don’t install too much crap’?

Yes, that’s exactly what the advice should be. But, and this is the interesting bit, of course Apple can’t give that advice - because the response would be “What the hell is Apple doing selling crap on its store?”

But that’s down the decision that Apple has made not to allow third party applications to be sold elsewhere - so it’s hardly blameless here.

John continues:

“If you truly demand the right to be able to shoot yourself in the foot with the software you install on your phone — which is a perfectly reasonable desire, and is how things work on the Mac — then the non-jailbroken iPhone isn’t for you.”

Let me paraphrase that passage:

“If you truly demand the right to be able to shoot yourself in the foot with the software you install on your Mac, then the non-jailbroken Mac isn’t for you.”

Will John be making the same argument in a couple of years time, should Apple decide that it will “protect” Mac users in this way too?

The Flip Side of the Multitasking Argument:

“As I wrote this morning, I don’t think the ‘no background’ policy implies any spite or shortsightedness on Apple’s part. It’s simply the result of Apple’s decision to focus first and foremost on maximizing battery life and performance. Other mobile platforms, such as Android, may well have different priorities”

This may indeed be why Apple is blocking background processes, although there could be other potential reasons. But more importantly, since when was it the responsibility of the maker of an operating system to prevent poorly-written applications?

Of course, you could argue that the phone is a “mission-critical” piece of equipment and you can’t afford for it to perform badly. But that argument is bunk: all you need to do is allow users to uninstall applications if they find them slowing things down.

And, of course, the same argument could be made for my laptop, which is a mobile device that’s highly mission-critical for me. Will Apple be making that argument in the future, too?

Paul Thurrot (yes, that Paul Thurrot) gives a solid and well-written overview of iPhone 2.0. The bit on enterprise is, as you might expect, the best bit. As he puts it, “this is a seriously impressive platform.”

Steve Jobs says that the Flash player performs too slowly on the iPhone, and the tech press swallows it without question.

So how come the Nokie N800, which uses a similar processor at a slower clock speed than the iPhone, runs the full desktop Flash player at perfectly-good speeds?

I’m not annoyed at Jobs bending the truth - if you’ve been around the Mac market for as long as I have, you get used to taking Steve’s statements with a pinch of salt. But as far as I can see, no technical publication took Jobs up on this. The only person that I’ve come across that’s even questioned Jobs’ statement is Robert Scoble.

If the tech press is now simply publishing the statements of CEOs without question, then it’s going to be dead a lot quicker than anyone thinks. If you can’t even do the basics of reporting right, then you have no business being in business.