All Articles Tagged gruber

We recently covered the new OpenClip project, and expansion of what was first demonstrated with MagicPad, and we liked both their implementation and their moxy in trying to pip Apple to the cut and paste post. Not everyone was as entirely impressed as us, however. John Gruber of Daring Fireball questioned whether or not the developers were really respecting the App Store SDK agreement. Since OpenClip aware applications write to their own sandbox’d Documents directory, but read the last-modified chunk from other applications Documents directory, Gruber considers it more of a loophole, and cites Apple’s iPhone OS Programming Guide:

Not simply that no other application can write to, but which no other application can access. That this restriction is not yet enforced at a technical level (such as is the case with an app attempting to write outside its own sandbox) does not mean it’s permitted.

Worse yet, Gruber points out that the current Beta 4 of the upcoming 2.1 firmware DOES enforce complete denial-of-access to other application’s Documents directory:

The OpenClip demo apps, which work as advertised on iPhone OS 2.0.2, do not work in the current 2.1 beta, because apps are no longer able to read or even see other apps’ sandboxes.3 To be clear, this change is clearly not in response to OpenClip; Apple began seeding the 2.1 betas with these tightened sandbox restrictions before OpenClip debuted, and the iPhone OS Programming Guide has stated all along that apps can’t “access” the contents of other sandboxes.

However, I’m not entirely certain any of that matters. OpenClip, based on my understanding, was never intended to be a long-term solution, merely a proof-of-concept to show that cut, copy, and paste could be done in an elegant manner on the iPhone, to keep a spotlight on the continued lack of cut, copy, and paste support from Apple, and to encourage the discussion of the issue and implementation.

In that regard, I think they’ve already succeeded.

C’mon. A day without a MobileMe post is like a day without rain. Or something. So after yesterday’s John Gruber vs. Om Malik showdown, former Apple insider Chuq Von Rospach has strapped on the gloves and joined the fray — in impressive fashion.

Says Chuq, after joking that Jobs is likely walking the MobileMe halls with a flame thrower round about now:

Gruber nails this (see below). MobileMe is a tiny thing compared to iTunes. Apple gets it, and executes it amazingly well. That this release was botched isn’t about Apple not having a clue, but about the MobileMe people either blowing it (I can think of any number of scenarios — scaling it hard). The ultimate failure seemed to be more capacity planning mistakes than anything else, if I’m guessing right. but the ultimate failure was not being willing to tell Steve “we aren’t ready” and taking that heat. They thought they could release and make it work, and guessed very wrong (or thought they were in good shape, which is worse).

The entire post is a fascinating read — chock full of insights, especially about new Apple VP of Internet Services (iTunes + MobileMe + App Store) Eddy Cue, whom comes off looking like a boss just a little to the right of Darkseid…

Om Malik says Apple is clueless about scaling MobileMe:

There is no-unified IT plan vis-a-vis applications; each has their own set of servers, IT practices and release scenarios. Developers do testing, load testing and infrastructure planning, all of which is implemented by someone else. There’s no unified monitoring system. They use Oracle on Sun servers for the databases and everything has its own SAN storage. They do not use active Oracle RAC; it is all single-instance, on one box, with a secondary failover. Apparently they are putting web servers and app servers on the same machines, which causes performance problems.

John Gruber retorts, with the US’ #1 online music retailer firmly in his corner:

But the iTunes Store does gangbuster traffic and has a terrific track record for uptime. The message I read from yesterday’s reorg that put MobileMe under Eddy Cue (Apple’s VP for iTunes) is that MobileMe could and should be as responsive and reliable as the iTunes Store.

The crazy thing is, MobileMe should have been an iTunes-learned breeze for Apple in terms of meeting service levels, given their pedigree. But then iTunes uses WebObjects (which I believe is old school Java-based) and MobileMe uses SproutCore (which is all dressed up in Ajax-y 2.0 objectivity), and the pretty much disastrous July 11th launch, which took down both iTunes iPhone activation, and slammed the MobileMe servers into weeks of problems, show something clearly is different with the new kit on the block.

Hopefully Cue will bring some of the iTunes luster to MobileMe, but only time will tell. What do you think? Which blog wins this round?

Mac nerdery stalwart John Gruber over at DaringFireball has put together a very interesting essay about how iPhone Calendar syncing has evolved from firmware 1.x (1.0 – 1.4) to firmware 2.0, and how the current iTunes syncing differs in functionality from syncing via Apple’s MobileMe service.

From welcome improvements to frustrating choices, from new methods of use to evolving work-arounds, Gruber ultimately comes to the ultimate question:

Whither the “digital hub”?

While iTunes originally served as the one-stop location for all syncing and sync settings, MobileMe now works outside the iTunes universe, but does not offer the options (e.g. selecting individual rather than all calendars to sync) iTunes does, nor does the MobileMe pref pane.

Is there a way for Apple to cleanly present a unified place to manage all iPhone syncing, with a robust set of options?

My vote remains iTunes. When MobileMe is in use, keep the settings enabled, and pass the preferences along to the “cloud”. That keeps data, media, and commerce all in one place, with one interface, in a familiar context. Just “push” choices of calendars, contact groups, etc. back up to MobileMe.

Like a moth to a flame or a Blackberry addict to email, I am drawn once again into the train wreck that is Flash on the iPhone. This time it’s courtesy one Robert X. Cringely, and it’s a brain bender!

Cringely says:

It seems obvious to me, however, that there is only one real reason why [rumors circulating the National Association of Broadcasters show suggested] Apple would sell off its professional applications [like Final Cut Pro, Logic Pro, Shake, and Aperture] and that’s to avoid antitrust problems when/if Apple buys Adobe Systems as I predicted at the beginning of the year.

Gruber responds:

I Think Cringely Is Off His Meds Again

Daring Fireball’s John Gruber goes on to say that while Apple may (or may not) sell off its Pro Apps, it would only do so to downsize and maintain focus, something buying Adobe would pretty much be the opposite of.

Personally, I think Apple stands to benefit immensely one day from controlling the media pipe end-to-end, and part of that control is the high end content creation tools, the Pro Apps. That’s Apple end game, the media hub and all its satellites. And if you want that, you don’t go selling off your launch vehicles.

What do you think?

While the interwebs stroke themselves into a furor over rumors that AT&T might just subsidize the iPhone 3G down to $200, Daring Fireball’s John Gruber once again asks that he be allowed to retort:

So says one report, using one anonymous source, from Scott Moritz, a “reporter” with an appalling track record regarding Apple and the iPhone. The same Scott Moritz who reported in July last year that Apple had cut back its production order on iPhones based on a “trading note” from Miller Tabak, a note which, it ends up, didn’t actually exist. And, as we know now, Apple went on to sell more iPhones than expected in 2007, not fewer.

Speculation ensues as to whether or not the AT&T exclusivity extends only to the current iPhone, and not the so-called iPhone 3G, and whether or not AT&T may want to take a price hit to keep Apple close. Gruber, however, quickly points out:

This comes so close to uncovering the obvious and glaring problem with a $200 AT&T iPhone subsidy, but, alas, Hesseldahl and his keen economic mind walk right past it. The problem is this: why would Apple allow AT&T to sell iPhones for half the price of what iPhones cost in Apple’s own stores (including this one)?

What do you think?

John Gruber and the Macalope have made an artful science out of reasonably, logically, and methodically skewering the most pathetic punditry and junky journalism surrounding Apple and the iPhone.

Case in point is Gruber’s recent and rather succinct dismantling of Simon Brocklehurst’s complaint that Apple chose Objective C as the language behind the SDK. And while he certainly doesn’t need my help, there are a few points I’d like to add.

First, anyone (but especially Simon) who thinks Apple just now (or even recently) decided to create an SDK for the iPhone knows little about SDKs and less about the polish and maturity easily observed in even the beta SDK Apple released at their special Roadmap event. The briefest look at actual developer blogs and tweets — including developers with substantial experience in jailbroken iPhone apps — would see the flood of remarks on the maturity of the beta SDK. Bottom line, if Apple hadn’t been planning the SDK for a long time (perhaps since the launch itself) they have a hidden supply of killer engineers capable of truly mind-boggling delivery.

Second, I’m going to go out on a limb and guess that, while I don’t know anything about Brocklehurst’s background, quoting Jonathan Schwartz indicates some level of Java-centricity. By serendipitous contrast, I just this week had a conversation with a developer at work who was being brought onto a new project. Since he’d recently done a lot of C++ and PHP, he was looking for a new language with which to stretch his skills. He wanted to try Ruby or Python, wanted to see what Rails could do. Gruber’s right, good programmers can (and want to) program and can (and want to) stretch themselves to do it (even when it’s not so far a stretch). Good programers who want to make good iPhone apps won’t think twice about adding Objective C to their skill set.

Third, the iPhone/iPod halo is clearly helping Apple gain traction in their Mac market, and there’s no reason to think the iPhone SDK won’t help Apple gain traction for Objective C and Cocoa via Cocoa Touch. Apple has shown time and time again — to the point of frustration on some occasions — that it is a future thinking company. Getting a bunch of convenience-oriented programmers now by putting out a Java or C++ iPhone SDK pales to insignificance when compared to the mindshare Apple could gain by delivering a powerful, delightful Object C/Cocoa Touch development environment (and experience) to the uber-keen developers of the next generation, whose newfound skills — and more importantly, tastes — will flow right back into the Mac and future Apple products.

While Apple certainly fumbles the ball on occasion, this time they look to be smashing their way clear to a touchdown.

Sorry Simon.

As part of his piece on the continuing confusion surrounding the $99 iPhone SDK program acceptance/pending/rejection letters, Daring Fireball’s John Gruber also dropped this very interesting nugget about the equally continuing and confusing situation surrounding the apparent Apple ban on multitasking and background apps:

[A] source confirmed to me that the iPhone AIM client AOL demoed during the iPhone Roadmap event does not cheat by continuing to run in the background — it quits when you switch to another app, but doesn’t log you out of AIM automatically. Such a client can’t notify you of IM messages from the background (a la the way the iPhone notifies of you SMS messages), but when you switch back to the AIM app, messages you missed should appear. Be wary of claims that “An app that does X is impossible without background processing.”

If accurate then that, as they say, is that in terms of any hope for multitasking apps before June. If Apple didn’t grant AOL “special dispensation”, they certainly won’t give any to Johnny “Next Big Social Perpetual Ping App”.

But is a non-background running AIM of any use to you? A welcome break from the constant connection demands of IM? A way to keep AIM second class to an eventual Mobile-iChat Touch app? Smart thinking on Apple’s part or just a train wreck in the making?

Following up on the cryptic “I Hate You – Don’t Leave Me” letters Apple sent out last week to many (all?) would-be iPhone developers who had coughed up the $99 for a certificate all signed and legal, Daring Fireball reports on whether or not anybody has made it in already:

I believe there are a small handful of developers who are sort of “in” already, but they were hand-selected by Apple. Perhaps, as with the ones who came on stage during the event to demo their “two weeks worth of work” apps, they were involved before the SDK was even officially announced.

But everything I’ve heard suggests that last week’s email from Apple was sent to everyone who applied for the program. I.e., there are developers who’ve been let in through the back door, but no one has gotten in through the front door yet.

John Gruber goes on to quote two sources who’ve told him that Apple has received over 10,000 applications alone for the $99 package and couldn’t meet demand for certificates this fast if it wanted to (and no one seems sure whether they do or not, nor how badly).

Massive over-reaction by the Twitterati? Yet another example of Apple’s dwindling communications skills? And will we have to wait until the June (30th at 11:59pm?) release to know for sure?!

Developers want them their multitasking. They want them popping up, one after the other, like Agent Smith replicants in the Matrix sequels. What? Viruses incarnate from poorly conceived follow-up movies is a bad analogy?

Not according to some leading Apple pundits.

Witness Daniel Eran Dilger’s iPhone 2.0 SDK: The No Multitasking Myth from Roughly Drafted Magazine:

By limiting the amount of background processes running, the iPhone’s OS X can offer more of that available RAM to the foreground application, along with a less distracted processor. The iPhone is not a general purpose computer; it is primarily a phone, browser, and iPod. Due to the restrictions imposed by the SDK, it will also be a credible gaming platform and pack the power to run significant productivity applications, all without giving up the ability to be a responsive phone, browser, and iPod. Other devices can’t make that claim.

Sure, Dilger is sometimes considered on the extreme-end of Mac’tivism. Let’s see what Daring Fireball’s John Gruber has to say when he takes on One App at a Time:

Why has Apple imposed this limitation? Easy: the iPhone is severely resource constrained. Battery, RAM, and CPU cycles are all severely limited. If third-party apps could run in the background, all three could suffer. RAM would suffer for sure; all running apps consume memory. The iPhone has just 128 MB of RAM, and no swap space. CPU performance and battery life would suffer when background apps do something — and if they’re not doing anything, what’s the point of keeping them running? I noticed a significant increase in battery life after I switched the Mail app’s auto-checking interval from 15 minutes to 60 minutes. That’s just one app.

Okay, but they’re not developers. They don’t understand the needs, the passion. But then developers aren’t pure consumers either and developers don’t always understand consumer needs. Sometimes developers are so busy with the abstract coolness of what they can do, they don’t always stop and consider the colder reality of whether they should.

For every OS-changing Switcher app, there are dozens of buggy, crash-inducing WinMob and Palm fetishware. (As I can personally attest to, when even major apps from major developers rendered my Treo unusable).

No developer goes out there with ill-intent (malware aside), but their concern is app-level, not device or OS level. That’s where Apple comes in. The overall user experience isn’t the developers concern, nor should it be. It’s Apple’s concern, and right now Apple is imposing that concern via no-multitasking guidelines.

Note: John Gruber, quoting Hank Williams, also gives us The Flip Side of the Multitasking Argument. (Hit up the Roughly Drafted link above for some excellent back-and-forth between Williams and Dilger in the comment section as well.)

UPDATE: Gruber follows up in Foot, Meet Bullet, a point-counterpoint with Ian Betteridge.

What do you think? Is the ban on multitasking good or bad for the general user-base (i.e., our moms!)? For power users? Will Apple make exceptions for certain big developers (like AOL for AIM)? Will they relax the policy after the initial development rush is over, the space shakes out, and only cooler, more seasoned and reasoned heads remain in the game? Will some crafty devs will figure ways around the rules? (creativity thrives under constraint!). Or will things just stay the way they are?