Forget the iPhone 6 Plus: It’s the 6 That’s Too Big

Since 2007, I’ve owned every iPhone except the 3G — six in all. The iPhone 6 would’ve been seven. Instead it’s the first one I’m returning.

The iPhone is so central to my relationship to the world at this point that I essentially think of it as a utility: I’ll happily pay $30 a month[1] for the best experience possible. All Apple really has to do every year is make the camera better, make everything a bit faster, and ideally add some additional sensor or chip that does something useful. The iPhone 6 did all of those things — improved auto-focus, faster CPU, NFC, elevation tracking — and more. I was initially skeptical of the increased size, but I figured that Apple, having stood firm against the deluge of massive (and popular) Android phones for so many years, had figured out a way to incorporate a larger screen without compromising the comfort and intimacy of the iPhone. After using an iPhone 6 for a couple days, I’ve concluded that they haven’t.

Nearly every review I’ve read of the iPhone 6 has taken as a given that an iPhone with a larger screen is simply a better iPhone. I don’t know if these reviewers all have larger hands than I do or are just used to handling larger phones, but for me the size is a dealbreaker. It’s simply unpleasant to hold. When people were making cardboard cutouts of the new iPhone sizes after the announcement, I joked on Twitter that the trick to making the 4.7-inch seem reasonable was to try the 5.5-inch first, but this seems to have been exactly what happened to most reviewers: in nearly every review that included both devices, the primary comparison was between the 6 and 6 Plus, which is roughly the iPhone equivalent of accepting a plea bargain for 5 years to avoid possible life in prison. For people who adore the size of the 5/5S, the 6 Plus is an irrelevant distraction, a concession to people with vastly different priorities and preferences — essentially a different product entirely. What matters isn’t how the 6 compares to the 6 Plus; it’s how the 6 compares to the iPhones we’ve been using for years.

The conventional wisdom is that, by making the iPhone 6 thinner and rounding off the edges, Apple has compensated for the larger size in ways that many Android manufacturers haven’t. But as impressive as the design and engineering of the iPhone 6 are, in my hands the extra width still makes it much less comfortable to hold, the added height makes it unsteady, and the rounded edges and slippery surface make it treacherously insecure. (By comparison, the move from a 3.5-inch screen to a 4-inch screen had no effect on how easily you could grip the phone.) A number of reviews have said that the iPhone 6 practically demands a case, but that seems like a pretty strong condemnation of a phone’s design. And for people who haven’t used cases on their iPhones previously, adding a case on the 6 would increase the size and weight even more.

As John Gruber said in his review — one of the few to question the size increase — a larger screen is a trade-off: more difficult to use one-handed, but great for content and easier to type on. For me the trade-off isn’t worth it, but one-handed use is also only part of the problem. Even if you’re using your other hand to actually touch the screen, you still have to hold the phone, and the very act of holding the iPhone 6 in one hand is, at least for me, less pleasant. While I enjoyed using the 6 while sitting on a couch, essentially as an iPad Nano, using it nearly everywhere else — walking outside, lying down, pulling it out of my pocket to check something, holding it up to my ear for the rare phone call — was an uncomfortable and often terrifying affair. It’s possible that I would get used to it (as Gruber suspects he will, though he hadn’t after a week of use), but, then, humans are pretty adaptable. I could probably get used to asking strangers for directions again if I had to.

In some ways, the issue is a philosophical one. I want my amazing mobile computers to get smaller and more natural, not bigger and more computer-like, and I don’t think I was alone in believing that Apple shared that philosophy.[2] The iPhone 6 feels like a screen I’m holding in my hand; the smaller iPhones have felt like extensions of my hand. There’s clearly a huge market for extra-large phones, and, sneering ads from Samsung aside, not introducing an iPhone 6 Plus would’ve been leaving money on the table. But replacing the 4.0-inch model with a 4.7-inch model feels like a betrayal of the principles that have guided the iPhone’s phenomenal success for the last 7 years.

Here’s hoping for an iPhone 6S Minus next year.


[1] ($750 unlocked middle model + $65 tax - $450 resale of previous phone) / 12 months = $30/month

[2] It’s actually more confounding in light of the Apple Watch. As Michael Tsai said during the Watch announcement, “So there’s a small(er) watch but no smaller phone?”

Disabling the Sent Message Sound in OS X Mavericks

In a bit of overzealous simplification, the Messages app in OS X 10.9 Mavericks removes the rather basic ability to turn off the sound effect played when sending a message, which has been possible in Messages/iChat as far back as I can remember. In Mavericks, you can choose whether to play all sound effects, and you can choose among the built-in alert sounds for receiving a message, but you can’t disable just the Sent Message “whoop”, as I’ve always done. (I know when I sent a message. I was there.)

The new limitation mirrors iOS, where turning off the sending sound has never been possible. Fortunately, unlike in (non-jailbroken) iOS, there’s an easy workaround. From Terminal, rename the relevant audio file:

sudo mv "/Applications/Messages.app/Contents/Resources/Sent Message.aiff" "/Applications/Messages.app/Contents/Resources/Sent Message.aiff.bak"

Then restart Messages and send messages in blissful silence.

The above command may have to be repeated after OS updates, at least until someone at Apple becomes sufficiently annoyed and restores the ability to turn off the “whoop”.

You can similarly change or disable the sound effects for other actions — all of which used to be configurable from the preferences (and could even be customized for specific people from the buddy list[1]) — by replacing or renaming the other .aiff files in that directory:

  • Buddy Logging In.aiff
  • Buddy Logging Out.aiff
  • Default.aiff
  • File Transfer Complete.aiff
  • Invitation Accepted.aiff
  • Invitation.aiff
  • Logged In.aiff
  • Received Message.aiff
  • Ringer.aiff

[1] I imagine it’s possible to have buddy-specific sound effects using the remarkably-still-present “AppleScript handler” functionality, but I haven’t tried it.

Touch ID and “Require Passcode: Immediately”

For people used to the iOS passcode lock, the fingerprint scanner on the iPhone 5S, which Apple calls Touch ID, comes with a significant drawback: with Touch ID enabled, it’s no longer possible to set the amount of time since the screen last turned off before the passcode — or, now, Touch ID — is required to unlock the device.

Going back to the very first iPhone, the “Require Passcode” setting has offered various options — “After 1 minute”, “After 5 minutes”, etc. — to control the passcode timeout, and nearly everyone I know who uses a passcode chooses a timeout of at least five minutes. I’ve generally set it to five minutes myself, which I feel provides a good balance between security and convenience: long enough so that I don’t have to reenter my passcode if I put my phone in my pocket for a minute while texting with someone or navigating somewhere, but short enough that, if I left my phone somewhere by accident, the passcode would likely be required before someone discovered it. Now, with Touch ID, “Immediately” is the only option. Waking the phone — every time — requires either scanning a fingerprint or swiping across the lock screen and entering a passcode manually.

The Require Passcode screen, with Touch ID disabledThe Require Passcode screen, with Touch ID enabled
On the left, with Touch ID disabled; on the right, with Touch ID enabled

Requiring authentication immediately is problematic for a number of reasons.

First, it greatly increases the number of times per day that Touch ID has to work. When functioning properly,[1] Touch ID is remarkably accurate and a delight to use. Yet it still occasionally fails to read my thumb on the first one or two tries, and it’s stymied by moisture or dirt. If I were only authenticating as often as I used to enter my passcode, it would easily be a net win — after all, I didn’t always get my passcode right on the first try either. Having to authenticate on every unlock, though, anything short of 100% accuracy for the scanner quickly becomes tedious.

Even when it’s working well, using Touch ID isn’t always the quickest or most convenient option. In iOS 7, it’s now possible to slide to unlock anywhere on the lock screen instead of just across the bottom — a great Fitts’s Law win. Among other things, this makes one-handed use much easier and more physically secure, since you can lock the phone with your index finger, wake it up the same way, and then slide your thumb across the top of the screen, without the finger acrobatics that were previously required to reach the bottom of the screen. Unfortunately, with Touch ID enabled, sliding to unlock is now never sufficient on its own, meaning that you have to either enter the passcode or adjust your grip to reach all the way to the home button each time. If you’re waking your phone repeatedly — say, to check your position on a map, or to return to something you’re reading — this gets annoying quickly.[2]

Requiring the passcode immediately also impairs basic iOS functionality: the ability to swipe across lock screen alerts in order to trigger actions. If you text someone via Messages, switch to Safari, lock the phone, and then receive a reply a few seconds later, unlocking via Touch ID will take you to Safari, not Messages. The same problem applies to any alert from an app that wasn’t the one you most recently used. The workaround is to slide across the lock screen alert to get to the passcode screen and then authenticate with Touch ID, but that’s an annoying extra step for people used to a passcode timeout, an unfortunate regression in usability for an action that people have done many times daily for years.

Finally, with Touch ID enabled, the passcode still remains an option: simply slide to unlock as before and enter the passcode. This is an important alternative when a registered finger isn’t clean/dry/free, and even before Touch ID I would occasionally find myself needing to use a lesser finger or knuckle to unlock the phone. Removing the timed options means that, when Touch ID is enabled, simply using the phone in exactly the same way as before is now significantly more onerous.

So if there are so many disadvantages to requiring the passcode immediately, why is it now the only option?

At first glance this might appear to simply be a bug,[3] but a perusal of Apple’s Touch ID documentation suggests otherwise:

Using Touch ID sets your Require Passcode setting to Immediately. You still have the option of entering your passcode simply by sliding to unlock.

While this doesn’t explicitly state that the other Require Passcode options are no longer available with Touch ID enabled, it strongly suggests it. Otherwise, why change the setting the user had assigned?

An alternative and more likely explanation is that the new restriction amounts to an opinionated view of how Touch ID should be used. Apple’s recommended technique for using Touch ID is to press and release the home button with a registered finger and leave it there until the phone unlocks. It seems plausible that, in Apple’s view, the new, correct way to start using an iPhone (except when simply interacting with Notification Center or Control Center) is always just to wake and unlock it in that manner.

Fortunately for those frustrated by this change, Apple has relented before on opinionated decisions that proved to be overly restrictive and/or optimistic. (See: apps.) Unfortunately, the fix isn’t as straightforward as simply restoring the missing timed options. Touch ID, as currently implemented, is a function of the passcode lock. If the passcode didn’t take effect for several minutes, it wouldn’t be possible to unlock the phone using Touch ID during that time. A solution in which Touch ID is only conditionally, unpredictably available is obviously a nonstarter.

The Fix

So what’s the solution, then? The Require Passcode setting should be separated from Touch ID. The previous timed options should be restored, but, true to the setting’s name, the timer should determine solely whether the passcode keypad appears or whether the phone unlocks immediately when the user slides to unlock. Touch ID, meanwhile, should remain operative on the lock screen at all times, even when sliding to unlock would be sufficient. This would allow people to continue to use the Apple-recommended unlock technique whenever they liked, but, when they knew they were within the passcode timeout period, to hastily wake the phone via either button and swipe across the screen — or, in the case of a lock screen alert, to swipe across the alert to trigger the associated action.

This isn’t a perfect solution. First, it would allow for the awkward — if harmless — situation of having Touch ID reject a fingerprint even when authentication wasn’t actually required. (The alternative, having it accept anything that seemed like a finger as long as the passcode timeout hadn’t expired, is probably too likely to produce accidental unlocks.) But if Touch ID is enforced before the passcode timeout, should three failed attempts still bring up the passcode entry screen, as happens now, even though simply swiping would have bypassed it? Should five failed attempts force passcode entry until the next unlock, again as happens now, even though the passcode itself wouldn’t yet have been required? The answer to both is probably yes, if only to avoid providing an unlimited, detection-free testing mode for CCC-style Touch ID hacks for anyone in temporary possession of a pre-timeout device.

Allowing a passcode timeout with Touch ID would also introduce a degree of unpredictibility into the unlock process, resulting in some unlocks that took longer than necessary because the user misjudged the timeout, tried to press-and-swipe, and ended up on the passcode entry screen, rather than simply using Touch ID from the outset. But since Touch ID can be used on the passcode entry screen as well, the penalty for misjudgments would be minimal. Furthermore, with “Require Passcode: Immediately”, swipes across lock screen alerts already always trigger the passcode entry screen, so in those cases an unexpected timeout would simply result in the current behavior.

Even if the timed options were restored, most people would continue to unlock their devices with Touch ID at all times, as Apple surely prefers. But for people who lock and unlock their devices constantly and still want to keep their data secure, the Require Passcode setting has always been a crucial time-saving feature, and it would remain so in conjunction with Touch ID. Touch ID is impressive technology, but it would be a shame if the only way to match the usability of the last six years of iOS was to turn it off.


[1] For the first week that I had the phone, Touch ID failed constantly with one of my thumbs, requiring one or two tries every time. Knowing that early reviews had touted the system’s near-perfect accuracy, I tried various things to improve its performance: giving it time to learn more of my thumbprint, deleting and retraining, even adding different parts of my thumb as separate fingers to try to increase the coverage. No luck. I had pretty much concluded that either the scanner or my thumb was defective. Finally, nearly ready to disable Touch ID for the passcode altogether, I wiped off the sensor and retrained my thumb once more, and since then, it’s worked nearly every time. [UPDATE: No, it hasn’t.] It seems possible to configure a finger with an inaccurate profile that the phone can’t learn its way out of.

[2] Also annoying? The glacial fade-in effect when waking the screen in iOS 7. It’s actually hard to compare the speed of Touch ID to the speed of pressing a button and sliding to unlock, since Touch ID begins processing immediately, whereas the screen doesn’t seem to register swipes until the effect completes. With the fade-in effect, Apple is essentially cheating a bit to make Touch ID seem faster, but it’s doing so at the expense of traditional unlocks.

[3] One theory I’ve seen is that the presence of the “Shorter times are more secure” message in the pane suggests that the other options were intended to be available. However, Exchange servers have always been able to restrict iOS passcode-lock policies, including limiting the available options to “Immediately”, and the same message has remained even in that case. There is a bug here, but it’s simply that the message appears even when “Immediately” is the only available option.