John Gruber – On the Behavior of the iPhone Mute Switch
Andy Ihnatko – Unmuting on The Mute Question
Marco Arment – Designing “Mute”
Guy English – Mute This

Both sides of the argument have valid points-of-view. This really is a situation with no right answer given the current mechanisms.

That got me thinking that there might be something missing that’s causing this ambiguity. I’ve come to the realization that this is a problem bigger than just alarms going off at inopportune moments. What we really want is for the devices in our pocket to behave differently depending on where they’re physically located.

Let’s imagine a new feature in iOS called “Homebase”. A user would be presented with a simple UI that lets them select a location that’s a “safe” environment. After the setup is complete, your Homebase would be recognized by GPS coordinates and/or available Wi-Fi networks. The important thing here is that the user gets to define where they feel safe with their device.

With that information developers can make smarter decisions:

• Alarms that go off while the mute switch is on make noise at Homebase and just vibrate elsewhere. There’s no need to worry about alarms going off in public places (such as concert halls) and you won’t oversleep when you go to bed with a mute switch on.
• The lock screen doesn’t need to display a Passcode lock at Homebase. People who use the Remote app with their Apple TV will no longer be annoyed by an unnecessary security precaution, nor will folks forget to turn their Passcode lock back on when they leave for the local bar (where they’re certain to get a Poopin’ tweet.)
• Apps, like Find My Friends, could use cached Apple ID credentials at Homebase and avoid asking the user for them over and over and over and over again.

Of course, this feature is needed most by people who don’t even know the Settings app exists. It’s my opinion that if developers are careful with this additional knowledge about the user and device, default behavior can be adjusted appropriately without additional confusion. It’s analogous to the Energy Saver on the Mac: people don’t question why the screen dims when the power cord is removed because it just “makes sense”.

The examples above use Apple’s own apps, but the Homebase status would be useful for third-party developers, too.

If you’d like to see something like Homebase in iOS, please be sure to file a duplicate Radar.

The first warning sign was after starting the Installer: I was prompted for an administrator password indicating that this software wanted to run from protected areas of my system. Being a developer, I immediately dug into the installer scripts and configuration files to see that the app is placing items in the Rapport/bin, PreferencePanes, LaunchDaemons and LaunchAgents folders of the main system Library folder. The launch folders indicate that the software will be run whenever my Mac is restarted and will be able to do things a normal user would not (because of elevated permissions.)

I placed my security concerns aside as I need to access my bank website, so I went ahead with the installation. Afterwards, I was directed to a web page describing the new software.

Again, as a developer, my first thoughts were suspicious ones. From experience, I know that it’s not easy to modify Safari’s user interface in the way that Trusteer was doing. My guess that there would be a new, always active, background process was confirmed by the presence of “rooksd” in my process list.

However what happened next really opened my eyes. Safari crashed.

Of course that, in and of itself, isn’t the end of the world. But I was surprised to see a new library named RapportUtil1 while looking at the Safari crash report. It was pretty clear that the new Trusteer software caused the crash. But how?

As a longtime Objective-C developer, I know a thing or two about “method swizzling“. In a nutshell, this allows a developer to replace the functionality of code they don’t have direct access to (typically in the system or other frameworks.)

Seeing “_nsapplication_sendEvent_override” tells me that Trusteer is using this technique to change the behavior of Safari. The function that is being affected is -sendEvent: — the part of every Cocoa application where mouse, keyboard and other input is routed.

Method swizzling is a dangerous activity. You have to make assumptions about how some other code, that you’ve never seen, is behaving. You also need to think about how that code might change in future versions. There are extreme cases where this technique can be effective: overriding the default behavior of my web browser is not one of them.

It’s clear that the folks taking control of my browser aren’t as clever as they think. Do you see a common theme when you search Apple’s discussion forums for “RapportUtil1“?

Even more troubling is the method being overridden: every key press or mouse movement is first being sent to Rapport and then forwarded onto Safari. Since this happens often, the intruding software can do pretty much whatever it wants, whenever it wants. And remember that part of this package is running with elevated permissions in the background.

After mentioning my findings on Twitter, I got back some very interesting replies. Graham Lee (@iamleeg) pointed out that I’m not the first developer to question the technical merits of this software. But then Peter Hosey (@boredzo) dropped the real bomb. Trusteer tacitly admits to recording my password. That’s easy to do when you take control of -sendEvent:.

Essentially, my bank is asking me to install is a keylogger. Just so they can warn me not to use the same password on suntrust.com and playboy.com.

Hopefully, the engineers behind Rapport are smart enough to be using hashed passwords rather than clear text. And hopefully none of the personal information Safari has access to is being forwarded to the Trusteer servers. And hopefully they’re not recording how many times I visited playboy.com last month. But that’s beside the point, because as a closed source product, no one can audit their activity. That’s not true with Safari.

Oh, and there’s one other thing: the Rapport software isn’t supported on Lion. One of the tenets of method swizzling is to test your software early and often with any new release of the system or framework that it’s modifying. As a developer, you need to be proactive about fixing any problems that pop up in the code you are overriding. Not doing so is irresponsible and puts your users at risk. The last update for Rapport was in 2009.

(One could speculate that the new privilege separation architecture for Safari in Lion is causing Trusteer’s developers a lot of headaches. The other tenet of method swizzling is to remember that it’s not a matter of if your hack will break in the future, but rather when it will break and how painful it will be to fix.)

Needless to say, I have uninstalled this software and will never be installing it again. I would recommend this course of action to any end user.

But that leaves me with a problem: how do I access my bank’s website? I have three options:

1) Find another bank. This is a difficult choice, as there are many systems that are hooked up to this account: ACH transactions for sales via iTunes, bi-weekly payroll, automatic payments for services, etc. I’d also like to give SunTrust a chance to reconsider their position in requiring this software (they will be getting a copy of this report.)

2) Use the telephone. I can call the bank when I need the information. Sure they’ll get tired of hearing from me, and it will cost them more for customer service, but it’s their choice to require Trusteer Rapport.

3) Run the Trusteer Rapport software in locked down environment. Once it’s supported on Lion, it should be possible to create a virtual machine that that will only be used to access the bank website. Needless to say this is inconvenient, a waste of resources, and severely limits my ability take advantage of my bank’s services.

In closing, I’ll leave you with one final irony: I will never be able to access my bank’s website from what is arguably the most secure computing device in existence today. That’s because the iPad is not a supported platform. Apple only allows third-party applications to run in a secure sandbox where they can’t affect other applications or the operating system. What you’ve seen above is exactly the reason they’ve done this.

I’m one of the developers that is affected by the Lodsys patent infringement claim. I’m writing not to beg for your support, but rather to give you a better idea of how this legal action affects the average iOS developer.

We’re a small company. We have 12 employees that have created 14 products for Mac and iOS. We have been incorporated in the state of North Carolina since 1999. We won an Apple Design Award in 2008.

We’ve been doing product development long enough to know that legal expenses are just a part of doing business. But as we both know, the costs of patent litigation can be staggering. As a small company, we don’t have the resources to defend ourselves, so that leaves us with one option: to pay a licensing fee.

And that worries us and every other iOS developer we know.

In and of itself, paying half of a percent of our App Store sales to Lodsys isn’t going to put us out of business. The fear we have is that this is the first step on a very slippery slope.

It’s well known that the top titles in the App Store can earn tens of thousands of dollars per day. There are many predators with dubious patents who see dollar signs when they look at the flock of iOS developers.

What these predators don’t realize is that for every developer who’s earning millions, there are many thousands who are earning much less. This backbone of the iOS ecosystem is doing well with work we love, but that is very much at risk with increased legal costs. We wonder what happens when these predators discover that the earnings from these apps are much lower than they expect. Will the licensing fees increase as a result? Will our next infringement be 5%, 10%, or more?

Of course, this is also a slippery slope for Apple. Taking on a legal burden for an entire platform is not something we would want to do, especially when the root of the problem is a screwed up patent system.

We love developing products for iOS and the Mac, but this legal mess has already started killing that enthusiasm. Apple has revolutionized the distribution of software via the App Store and that has been a great boon for smaller developers. It makes us furious that these greedy predators can put all of that at risk with patents.

Thanks for your time,

Craig Hockenberry

On your desktop, multitasking means that any application or process can run at the same time as another. Technically, there’s no reason why the same can’t be done on a mobile device. However, from a more practical point-of-view, there is one good reason why you don’t want this: a running app uses energy that decreases your battery life. Running fewer apps means you can listen to music longer, make more phone calls, or call up Maps at the end of the day to find a place for dinner.

At the same time, there are certain types of app that must run in the background in order to be useful. Apple has identified three categories of apps:

• Audio – Apps that plays audible content while in the background. The poster child for this type of application is Pandora.
• VOIP – When you’re making or receiving phone calls over an Internet connection, you’re using a “Voice Over Internet Protocol” app that runs in the background. Skype is a good example.
• Location – Some applications need to run in the background so they can keep track of your current location. An app that logs GPS coordinates while you take a walk or run would need to do this.

Additionally, apps can tell iOS 4 that they need additional time to complete a task or want the user to be notified at a specific time. This lets apps finish a long download or pop up the little blue window like an incoming SMS message.

These simple rules cover a wide variety of situations, but there are still some cases that aren’t covered. The main shortcoming is with apps that need to periodically refresh data. Social networking apps, chat programs, news readers, and other utilities that check the Internet for changing data don’t fit into any of the above categories. Developers have proposed solutions to these problems, but there’s no solution for today’s software.

Part of the confusion with multitasking comes from Apple’s excellent implementation of “task switching”. When you double-tap on the home button and start another application, the previous application is “frozen” and put into a state where it’s not running but can be restarted quickly. A part of the freezing process also reduces the amount of memory being used: allowing more applications to fit in freezer.

The next time you tap on the app’s icon, it is “thawed out” and put back on your iPhone’s screen while the previous app is frozen. This process is repeated each time you launch an app.

This sleight of hand makes it feel like you’re running many more applications than you actually are. It also explains how your iPhone can continue to have great battery life while you interact with many different apps. Most of your apps will be frozen and not using power: only the app on your screen is active. And even with audio, phone or GPS apps that are running in the background, you won’t be using more than one of those at a time (go ahead and try to listen to Pandora and the iPod apps at the same time!)

Hopefully this short explanation helps you understand that the developer of your favorite app isn’t being lazy about doing refreshing in the background! If you feel strongly about this situation, the best thing you can do is give Apple some feedback.

Updated July 1st, 2010: Matt Neuburg has written an in-depth explanation of fast app switching at TidBITS.

APR 23 SO THIS GUY @MACGUITAR GETS IN THE HOT TUB AND SAYS HE WANTS TO SHOW ME HIS THINGS WHAT A WEIRDO MADE @GRUBER JEALOUS TO

APR 24 @jsnell BE CAREFUL OR I WILL MAKE YOU GET IN THE HOT TUB WHAT KIND OF WHINE DO YOU LIKE

MAY 8 WELL LOOK WHOS SHOWN UP AND HE BROUGHT SOME READING MATERIAL COULD IT GET ANY HOTTER IN THIS TUB I HOPE SO

MAY 9 NOW THAT @SIRACUSA HAS FINALLY SHUTUP ABOUT HIS DEEP FEELINGS FOR LARRY WALL WERE GOING TO LEARN ABOUT THE BLINK TAG FROM JEFFRAY PARTY ON

MAY 13 OK WHO LET THE CHICKS IN I TELL YOU WHAT IF SHE STARTS UP WITH THE POETRY SHELL BE LOOKING FOR A WORD THAT RHYMES WITH PALM

MAY 16 WHO THE HELL LET THE KID INTO THE HOT TUB BOY BE CAREFUL OF THE GUY BEHIND YOU HELL WANT TO SHOW YOU HIS THINGS YOU CAN LEAVE YOUR HAT ON TO

MAY 19 I THOUGHT CATS DIDNT LIKE WATER THAT SNEEKY BASTARD @SOCKINGTON IS PROBABLY GOING AFTER MY WHINE

May 21st Looks like Twitter’s avatar uploading is broken. Again.

MAY 21 OR MAYBE IT WAS JUST THAT @ATEBITS AND ME BEING IN THE SAME TUB WAS TO HOTT TO HANDLE

MAY 21 IN MORE IMPORTANT NEWS TWITTER FIXED THERE SERVER SO THE CACTUS FITS IN THE HOTT TUB AND @GRUBER THOUGHT SITTING IN MY LAP WAS PRICKLY

MAY 29 SO ITS BIKINIS ON MONDAY AND WOLFS SHIRTS ON TUESDAYS WHAT ARE WE GOING TO WEAR THE REST OF THE WWDC WHEN WERE NOT IN THE HOTT TUB

MAY 29 AN IMPORTANT AVATER UPDATE IS NOT WORKING AND NO IM NOT WEARING A BIKINI IN IT BUT ITS BETTER

MAY 31 HEY HEY IT LOOKS LIKE THAT FOXY @TJW DUDE LOST HIS HAT ON THE WAY TO THE HOTT TUB AND WHAT THE HELL DOES INMO MEAN http://twitpic.com/59r88

JUN 3 WHO LET THE DOGS OUT THIS HOTT TUBB IS FULL OF PARTY ANIMALS NOW MOOF MOOF MOOF MOOF http://bit.ly/QNz2G AND DONT SPILL MY WHINE

JUN 4 I LOVE TO CUDDLE WITH TEDDY BEARS ESPECIALLY IN THE HOTT TUBB WONDER WHO LET HIM OFF THE FARM IN THAT KEEWEE COUNTRY

JUN 4 OH CRAP ANOTHER BEAR SHOWED UP BUT THIS ONES CANADAIAN AND HES GOT HIS EYES ON MY DRINK HES ALMOST A FRENCHIE TO

JUN 5 WHOA SOMEONE AND THERE ROCK HARD ASS JUST SHOWED UP IN THE HOTT TUBB NEVER SEEN SUCH FANCY SWIM TRUNKS EITHER WHAT AN PARTY ANIMAL

JUN 5 THE HOTT TUBB IS GETTING SO FULL WERE ONLY ALLOWING SUBATOMIC PARTICLES FROM THE HARDON COLLIDER MAYBE HIS EXISTENCE PROOFS THE THEORY

JUN 5 @Curvyboom YOU CHICKS SPEND ALL YOUR TIME ON FACEBOOK PLANNING LUNCH AND WAITING IN LINE FOR THE TOILET NO TIME TO PARTY WITH US ANIMALS

JUN 6 WITH ALL THE CHICKS SHOWING UP FOR WWDC I KNEW ONE OF THEM WOULD TRY TO SNEAK INTO THE HOTT TUBB GOOTEN MORGEN MINE FRAULINE ICH HABEN CHOCK

JUN 6 IT LOOKS LIKE SOMEONE WITH A TELETYPE SHOWED UP TO THE HOTT TUBB ID KICK HIM OUT BUT HIS PALMS LOOK DELICIOUSLY FLESHY

JUN 6 @dsandler ITS EASY TO EXPLAIN JUST SAY THAT ITS PINK AND WARM

JUN 7 ANOTHER DAY ANOTHER CHICK IN THE HOTT TUBB SHES ALMOST AS PINK AS I AM AND I THINK SHES LAUGHING AT US NOT WITH US WONDER IF SHES MARRIED

JUN 7 @AmyJane ILL MAKE SURE TO WHISPER POPS IN HIS EAR WHEN WE HAVE OUR ANUAL SNUGGLE

JUN 8 YOU LOSERS WHO DIDNT COME OVER TO THE YERBO BUENO HOTT TUBB MISSED OUR SURPRIZE GUEST DURING THE KEYNOTE @GRUBER WAS SO EXCITED HE PEED

JUN 9 ITS GOT SO CROWDED IN THE HOTT TUBB LAST NIGHT I HAD SOME GOLDEN GATES INSTALLED SO YOU CAN ALL LEAVE NOW

JUN 10 SOMEONE TURNED UP THE HEAT ON THE HOTT TUBB LAST NIGHT AND IM STILL FEELING A BIT WOOZY ALSO SEEING GRUBER SWEAT IS NASTY

JUN 10 OOOOOOHHH FUZZY BALLS ARE TICKLING MY NOSE IN THE HOTT TUBB AFTER FREE BEER AT THE MAC WORLD

JUN 11 YEAH ITS TRUE I MAY BE GETTING OUT OF THE HOTT TUBB TO PERFORM AT A BASH WORKING OUT DETAILS WITH THE LAWYERS

JUN 11 FRICKEN LAWYERS WONT MEAT MY DEMANDS FOR THE YERBO BUENO SHOW MAY HAVE TO GET A FAMILY MEMBER TO DO IT STAY TUNED FOR OFFICIAL CHOCK ROCK

JUN 11 BTW DONT FOR GET TO USE CHOCKROCK WHEN LOCALIZING FOR JAPAN

JUN 11 IF YOUR LOOKING FOR THE HOTT TUBB ITS CONVENIENTLY LOCATED NEAR THE FOUNTAIN AND KEGS LOOK FOR GRUBER IN HOTT PANTS

JUN 11 YES I AM LIVE TWEETING THE BASH TURN OFF YOUR FRICKEN PHONE SO I GET SIGNAL LOOSER

JUN 11 HOTT TUBB http://yfrog.com/5hgdgtj

JUN 11 CAKE IS BEING SERVED IN THE HOTT TUBB BEER TO

June 12th For me, there will never be a beer bash as special as the one this evening.

JUN 24 AND YOU THOUGHT I WAS JOKING ABOUT MY BUDDY STEVE BEING IN THE HOTT TUBB http://bit.ly/Y8MCf A MAGIC MOMENT

For those of you asking for PDF or Ebook editions, you can order them now directly from O’Reilly. The printed version will be available in a couple of weeks. The “Look Inside” feature at Amazon.com will give you an idea of what the book covers. I’ve also written an overview of each chapter. (And for those of you who are dying to know, the CHOCKLOCK first appears on page ix.)

If you think you know everything about iPhone development, this book will probably prove you wrong. I learned a lot while writing it, and it’s my sincere hope that you’ll benefit from reading it.

First, let me congratulate you and everyone at Apple on the release of the iPad. From my dealings with your company, I know it wasn’t easy. Thanks to everyone for busting their asses: a lot of very complex puzzle pieces came together during those last 60 days!

I recently had an encounter with Bill Atkinson. I told him that “I haven’t had this much fun with a computer since 1984.” He laughed, said “Thanks!”, and went back to working on his iPad app. We, and many other developers like us, are completely smitten with this new device.

After owning an iPad for a little over three weeks, it feels like we’re dealing with something much bigger than that Mac we all got excited about over 25 years ago. I’ve been struggling to define exactly what that is: beyond the technical specifications like the beautiful screen with its large multi-touch surface. Those specifications define what the device can do, but not what it means in our lives. I want to understand the magic.

Last week, much of that meaning came into clearer focus at a birthday party for my brother, niece and nephew (April is birthday month in our family!) My wife had loaded our iPad with photos from a recent trip to see the desert wildflowers in Anza Borrego and my 50th birthday party from the week prior.

Predictably, people’s initial reaction was “Wow, that’s the new iPad!” But that quickly faded as I opened the Photos app and passed the device around. My family was more interested in sharing the photos than talking about the new technology.

I was particularly interested in how my mother, the quintessential technophobe, would react to the device. She picked up on things quickly and was flipping through photos in no time. It astonished me how the interface disappeared for her: at one point she subconsciously licked her finger before “flipping” to the next photo.

As interesting as it was to see someone non-technical use the device, the real eye opener was how several people could interact with the iPad at once. Much of my mother’s fear of computers was overcome because she was looking at the pictures alongside my sister-in-law who helped her out when she got stuck. Learning was organic.

My niece also discovered some of the games I had on the device. One, Abca, was a hit because many people could play it at once. I’ve always played the game by myself and was surprised at how much fun it was to have other people guessing words simultaneously. A group of people transformed the software into something no developer had ever expected.

All of this led to the revelation that we’ve begun a new age of “communal computing.” The desktop revolution centered around empowering individuals: this new revolution will extend that empowerment to groups of people.

The iPad was naturally passed around amongst the partygoers. Many people interacted with it during the evening, and I lost track of who had it at any given time. And therein lies a fundamental problem.

My iPad has a lot of personal information on it: email, business documents, and financial data. When you pass it around, you’re giving everyone who touches it the opportunity to mess with your private life, whether intentionally or not. That makes me uneasy.

It’s hard to fault Apple for this shortcoming. The secrecy of the project undoubtedly limited the amount of group interaction your designers and engineers would experience with their new creation. The social aspects of this device is probably just as much as revelation to them as it is to me.

I can envision several ways to solve this problem: either with a traditional login screen or with something new like folders that require a passcode to open. I have no doubt that your designers can find something elegant that gives me peace of mind as I share my iPad with friends and family.

Thanks for your time and consideration,

Craig Hockenberry

Updated April 30th, 2010: I filed Radar #7922808 for this issue and it was marked as a duplicate of Radar #7584426.

127.0.0.1	gizmodo.com
127.0.0.1	www.gizmodo.com
127.0.0.1	m.gizmodo.com
127.0.0.1	gawker.com
127.0.0.1	www.gawker.com
127.0.0.1	m.gawker.com

The person at fault is the shithead who stole the phone, not some overworked engineer drinking beer.

Please vote with your attention and do the same. Thanks!

(Thanks to @sebastianlewis for the idea.)

Update: I can’t believe there are some people defending Gizmodo’s actions. Let’s put the shoe on your foot:

1. You’re drinking beer with some friends.
2. You leave your wallet behind at the bar.
3. Some stranger finds your wallet and opens it up. Inside is a naked picture of your partner.
4. That stranger finds a website that wants to post the picture and they sell your wallet intact for $1.
5. Your partner finds their naked body on the Internet. Shit hits the fan. HARD.
6. The site that posted the pictures looks at the ID in the wallet and calls up with an offer to return the wallet. “Don’t worry, all the money’s still there!”
7. Then that website posts another article saying how dumb you were for leaving your wallet behind. And instantly millions of people associate your name with a stupid mistake.

How do you feel now?

Update: If you’re the kind of person who forgets that you edited your hosts file, use Marco Arment’s IP address of 66.135.33.106 instead of 127.0.0.1.

Update: For those of you who don’t feel comfortable with the Terminal, here’s a Cocoa application that runs an AppleScript to block Gizmodo. Thanks @digdog!

Native performance

This first benchmark compares the native performance of the iPad against the iPhone 3GS. The version of the iPhone OS is the one originally released with both devices (3.2 and 3.0, respectively.) The application used to test the devices was a release (optimized) build for ARM v7.

On average, the iPad is about twice as fast as the iPhone 3GS when executing native (Cocoa Touch) applications. Great news for developers, because it gives us much more flexibility when creating our apps.

JavaScript performance

Oddly, the same 2x improvement is not seen for the same benchmarks when executing JavaScript code in web pages. Again, the iPad with 3.2 is compared against the iPhone 3GS with 3.0. Things have definitely improved, but there was a wide variation in results when performing the tests. I suspect that just-in-time compilation or other similar types of caching are affecting the results.

The raw numbers really don’t matter anyway: the browser experience on the iPad is exceptional (and will only get better.)

Native performance: Original iPhone vs. iPad

The most remarkable change is when you compare the original iPhone to the iPad. Using the numbers from my original tests and the results above reveals an improvement of several orders of magnitude in just over 2½ years. I believe the technical term for this is “Holy crap!”

Note: I don’t remember if the original tests were optimized builds, or if it was even possible to get gcc to do them with a jailbreak toolchain. Even if they weren’t optimized like the current tests, the performance increases are still stunning.

All-in-all, a remarkable achievement by Apple’s engineers, especially when you consider that the battery life of these devices has gone up, rather than down.

iPad hardware

When using sysctl() to query the amount of memory available to the iPhone OS, the following values are reported:

Again, it’s likely that the device is using 256 MB memory chips with a portion of the total being used for other purposes, such as video memory. Also, developers have noted that all of the 200 MB of user memory is not available for use by apps. The OS and background apps make use of a large portion of that memory.

And last, and unfortunately least, we have the CPU speed reported by sysctl() using HW_CPU_FREQ. It’s zero: the A4 chip is truly magical. I guess that means we have to trust the spec sheet :-)

So hats off to the engineers in Cupertino: the iPad is an inspiring achievement no matter how you benchmark it!

P.S. Check out Twitterrific for iPad to see how we’re putting this processing power to use with our first app for this new platform.

P.S.S. If you’d like to perform these tests on your own, I invite you to download PantsTest.zip.

An important observation that I’ve made with the iPhone is that it’s perfect for “relaxed” computing. I use it while lying in bed, watching TV, waiting for my wife to try on a new outfit, driving through the middle of the desert, and a myriad of other situations where I’m not working.

There’s an inherent benefit to only doing one thing at a time: the load of worrying about other tasks is lifted. Knowing that there isn’t anything else competing for your attention is quite liberating.

Of course, the iPad is an extension of this.

What I find most interesting is the inclusion of the iWork applications. I suspect that we’ll all benefit from working in Pages, Numbers and Keynote without the distractions of the web, Twitter or chat. And in the long run, we’ll prefer it.