Category Archives: iOS

Mobile Is A Fad

Christopher Mims of the Wall Street Journal published a story this week with the sensational headline “Why Apple Should Kill Off the Mac.” In it, Mims argues that Apple doesn’t have the resources to focus on the Mac, which is clearly less important to the company than its growing lineup of mobile devices.

Long-time, Mac-savvy journalist Glenn Fleishman couldn’t resist rebutting the argument for Macworld. His take boils down to the Mac remaining too vital a part of Apple’s spiritual core, and it being important to Apple to control the devices used for the very development work that makes the other devices so valuable.

John Gruber unleashed his coveted “Jackass of the Week” award for Sims, dismissing the argument as nonsensical, and proclaiming “the end of the Mac is not in sight.”

The assumption that mobile devices will rise to the occasion of obsoleting desktop computers has run rampant for years. I responded to the sentiment nearly five years ago in a Macworld article: “Why I’m Sticking with the Mac.” The Mac is a general-purpose computer, which makes it a little boring in some respects, but its role as the hub for many customers’ computing needs remains valuable. “Apple’s strength on the desktop permits it to take risks with other products,” I wrote in 2010, and I believe that remains true today.

One sensational headline deserves another, so let’s get to mine: “Mobile is a Fad.” Why have people been so convinced, for years, that mobile is the future, while desktop computers are on the way out? What if mobile devices only fill the variety of temporary needs that arise from how we live today?

Product genres proliferate because they meet a need. In the 1970s when oil supplies were scarce, tiny economy cars began to dominate the market. It probably seemed reasonable at the time to assume that gas-guzzling trucks and off-road vehicles were on the way out, yet as soon as the world became flush with cheap oil again, car sizes ballooned and fuel economy plummeted. For many the demand for utility and power, even in the absence of justifiable need, outshines the specialized economy of smaller cars.

Why are people so excited about mobile? Because they go places. What if people stopped going places? Mobile devices are a godsend for people who are expected to wake up every morning, commute to work, run a variety of errands, and possibly stop for a drink with friends on the way home, expecting the battery life on their pocket and wrist-bound devices to stay at least above 20%.

In the future, your errands will all be handled by a low-paid army of Postmates and Taskrabbits. Your friends, geographically distributed around the world, will be selected from among the group of loyal comrades that chooses to live in your virtual reality: Facebook or Google. And you won’t ever be found rushing out the door at dawn, unless you’ve just woken from a nightmare flashback to the days before everybody worked from home. And now that we’re all at home most of the time, we might as well use powerful, multi-purpose computers with full-sized tactile keyboards. We deserve it.

Hopefully that’s all far-fetched, but I indulge in the dystopian fantasy to draw focus on my contention that neither the proliferation of mobile devices nor the extinction of desktop computers is a foregone conclusion. Each of the computing devices Apple in particular sells today, from the tank-like Mac Pro to the butterfly-light Apple Watch, has its own unique set of advantages and compromises. Most likely, the vast majority of us will find uses for several or all of these classes of products, as we engage in the aspects of our lives that favor either mobility or stability.

Years from now, I suppose it’s possible desktop computers will become obsolete, supplanted by mobile devices. But given the unpredictability of progress, I suspect we’ll look back at both classes of computing devices and chuckle about how silly it all seemed, before the advent of ______. On a long enough time scale, everything is a fad.

Whose Phone Is This?

On the latest episode of Core Intuition, my co-host Manton Reece described the experience his wife had of leaving her iPhone behind on an airplane, only to have the airline thankfully announce over the airport loudspeakers that the phone had been found.

When they returned to claim it, they asked how they had been able to determine the name of the owner from the locked phone? The answer? They “just asked Siri whose phone it was.”

Apparently this is common knowledge to the airline employees, and to no doubt countless iPhone users, but it was news to Manton and me. You can try it yourself: if you have an iPhone, and have set a contact card as “My Info” in Siri’s preferences, lock your phone and then ask Siri: “Whose phone is this?”

On the face of it, it seems like a great feature. Who wouldn’t want to empower the well-intentioned finder of one’s lost phone to make an effort of returning it?

The problem to my mind is not that Siri shares my name and contact information, but that it goes a step further, showing not only my main telephone number, but my physical address, all my telephone numbers, email addresses, as well as my AIM, Twitter, and Facebook accounts. It also happily provides my birthdate, the names of my wife, mom, dad, brother, heck, the names of any person I have assigned a relationship to.

When my friend Dan Moren gave me a ride to Çingleton last year, we killed time in the car playing with Siri’s abundant personalization features. Anybody with access to my locked phone will soon learn that Dan is in fact more than just a friend to me:

Screen capture showing personal details revealed via Siri

Of course, you don’t have to share all this information with whatever stranger manages to pick up your phone. Simply disable Siri access from the lock screen, and nobody will be able to access your private information using it. Of course, this means no airline employee who finds your phone tucked between the seats will be able to easily return your phone to you, either.

Alternatively, you could change the information on your “My Info” contact card. For example I could add an entry “Daniel Minimal” to my Contacts list, and only include a telephone number or email address. The problem here is much of Siri’s usefulness (as we discussed on the podcast) is rooted in it knowing specific details about you. Requests such as “give me directions home,” “call my mom,” or heck, “text my sweet, sweet ride to Montréal,” will fall upon deaf ears if you don’t include this information in the card that you associate with Siri’s “My Info.”

Depending on how paranoid you are about what happens when a stranger gets ahold of your phone, you might read this and decide to do nothing, to delete all the personal information from your “Me” contact card, or to forbid Siri from being accessed when the phone is locked. Personally, I don’t think any of these solutions is ideal. I’d like to be able to ask Siri to share some of my personal information from the lock screen, to increase the odds of my lost phone being returned. But I’d like to draw the line somewhere reasonable, without having to share every last detail about myself with the stranger who is holding the device.

Fingerprints As Access Tokens

Everybody seems to have an opinion about the new TouchID fingerprint sensor on Apple’s iPhone 5S. I suppose I do, as well.

Critics object to the idea that a fingerprint sensor, no matter how good, should be used to safeguard critical data. Dustin Kirkland makes the case (via John Moltz) that biometric information is inherently bad as a substitute for a password, because it cannot be “independently chosen, changed, and rotated.”

I take his points seriously, and they seem well reasoned from a security point of view, but they are based upon the premise that passwords are the end-all be-all of security, when in fact common sense proves they are not. The oldest, most trusted, and most widely deployed method of authentication on the planet is in fact “biometric”: the human ability to recognize a familiar face. The fact that my appearance could technically be spoofed does not change the fact that arriving at the home of a childhood friend after 20 years of separation will still earn me an invitation to the dinner table, if not a bed for the night.

So fingerprints make lousy passwords. Who cares? Their use in practice need not replace other authentication schemes, it only needs to augment other schemes in a manner that increases overall security.

Most authentication systems in society are scaled appropriately for the context in which they are deployed. When I travel by airplane, I am asked to show a government ID to get through the security gate, but thereafter, a simple piece of printed paper will get me on a plane. The government takes it for granted that once I’m in the boarding area, the odds of somebody getting hold of my scrap of paper, or my getting hold of theirs, and neither one of us subsequently complaining, are marginally small. Furthermore, if the two of us mutually agree to swap tickets and travel to the other’s destination, we haven’t really caused any significant harm, except perhaps to the egos of the folks in charge at the TSA.

Boarding passes are little scraps of paper that make lousy identification cards. I can’t use them to reserve a hotel, file a police report, or obtain a marriage license. Yet in the right context, I can use one to travel from Boston to Shanghai without a single person batting an eye or thinking twice about verifying my identity.

In this sense the airline boarding pass is like an access token. On the web, an access token is something obtained by stronger authentication that permits continued access with weaker authentication. For example when I allow a Twitter client to connect to my Twitter account, I must first visit Twitter.com and possibly enter my full account credentials. After the access token has been vended however, it serves much like a boarding pass, allowing free access until and unless I or Twitter registers a complaint.

There’s another sort of abstract access token that has been available to users iOS devices since day one: your continuous use of the device. If you have in your possession an iOS device and you abstain from turning it off or letting it sit idle, you retain free access to the various data on the phone. From a security point of view, this token is even worse than a fingerprint: anybody, including the family cat, can sustain it if they are so inclined. Leave a phone on a table for 5 seconds, somebody else picks it up, they have your “activity token,” and they didn’t even need to scan your fingerprint.

I view the fingerprint sensor on the iPhone 5S and other devices as an opportunity for extending this kind of implicit authentication. It’s not a substitute for a password, but rather a convenient token for obtaining streamlined, continued access to protected resources. It’s the boarding pass that prevents you needing to take out your ID, and go through a body scanner or pat-down again, just to get on the damned plane.

We can argue about whether Apple has chosen the right boundaries for where a fingerprint should be traded for full authentication, but as a technology it stands to fill that gap between the frighteningly insecure “unlocked while active,” and frustratingly unusable “full authentication required when inactive.”

In short, I would like to see fingerprint authentication deployed in a way that pays respect both to the relative convenience and the relative insecurity of a fingerprint. If I can for example configure my phone to require a fingerprint unlock after 1 minute of inactivity, but to require a passcode unlock after 30 minutes of inactivity, my concerns about fingerprint security would be effectively put to rest. Could a malicious person steal a high quality impression of my thumb print, construct a prosthetic, fleshy representation of it, and use it to unlock my phone? Perhaps. But if they can’t do it within half an hour of stealing my phone, they better get to work on cracking the passcode.

Screenshot Lightning

Apple recently changed their policy regarding screenshots for iOS applications in the App Store: you must supply any changes to your screenshots by the time of approval, or the existing screenshots will be locked down until the next time you submit and are approved.

Long story short: you better have those screenshots ready at submission time or very shortly after. And the screenshots had better be something you are willing to live with for a good long while.

This is a dramatic change from the old policy, under which developers could update screenshots at their leisure. This afforded a workflow where a developer might put all of their effort into the actual development of the app, submit it, and then get to work fine-tuning their screenshots for the marketing aspect of selling in the App Store.

One reason for putting off the job of creating screenshots is that creating them is time-consuming and tedious, even with a relatively simple app. For a more complex app, or one that is localized into many languages, the challenge is that much greater.

Last night, at our local Boston CocoaHeads meeting, I learned about a well-timed solution for this problem. Kent Sutherland, the programmer for Flexibits, showed off how he uses an automated screenshot-capture procedure to tame the task of generating Fantastical’s many screenshots, in many languages.

His approach uses a novel technique in which the target app itself is built with customized screen-capturing code compiled right in. Then the app can be driven through the iOS Simulator with WaxSim, a command-line tool for launching the simulator with various options. He was kind enough to share a sample project in which he applies the same technique to Apple’s UICatalog sample app:

Click to download Kent’s UICatalog sample.

After downloading the sample, navigate to the “Screenshots” folder to find the real goodies. The Readme.txt in that folder has simple instructions for kicking off the process. In a nutshell: just open the Screenshots folder in the Terminal, and type “python make_screenshots.py output”. Then watch as the iOS simulator cranks through the process of generating 12 screenshots for UICatalog before you’ve had a chance to wipe that tear of joy from the corner of your eye.

I plan to build more iOS software in the future, and something like this will undoubtedly be a lifesaver when I have significant screenshots to generate. My only existing iOS app, Shush, only has 4 screenshots in one language, and I still found it tedious enough to re-generate screenshots that I hesitated to improve the UI because of the work of another round of, ahem, bitsplitting.

The same approach is also applicable to Mac apps. Currently I go through a similarly tedious procedure of manually navigating and cajoling the app into a specific state before taking a screenshot by hand. This could all be driven by automated capture code built into a custom version of the app, where I could also imagine other niceness such as adding annotations to illustrative screenshots, being added to the process.

If you’re selling apps on the iOS App Store, Apple’s policy change makes it imperative that you come up with a workflow for effortlessly and quickly generating screenshots. Thanks to Kent’s generous sharing of his approach, your work is mostly done for you.