Twenty Years

Ten years ago, I reflected on having been hired by Apple ten years before, when I was just twenty years old. “The Start Date“:

The day you start at Apple, be it as an administrative assistant or the CFO, you’re joining a proud legacy, and you know it. I still remember the thrill of receiving that offer letter. I grinned wide, stared down at the relatively meager salary I’d be earning, and signed away my agreement to start in two weeks.

That makes twenty years. Today, in fact.

Many of my colleagues from Apple in the mid-1990’s have moved on, as I did. But a very significant number of them remain. In a world where jumping from job to job has become expected of almost everybody, Apple maintains a curious lifelong employment appeal to many people.

Apple has always possessed ineffable uniqueness among its corporate peers. From the moment of its founding as a scrappy, barely funded home-made computer manufacturer, to forty years later when its value and influence are almost impossible to comprehend.

This year, many new young people will stare down at the relatively meager salary they’ll be earning, sign away their agreement to start in two weeks, and be in for the twenty-year ride of their lives.

When Worse Is Better

On the latest episode of John Gruber’s The Talk Show, guest Ben Thompson tries to identify the ways in which Amazon’s Alexa speech recognition is better than Apple’s Siri.

One of his key points was that Alexa, by being theoretically less capable than Siri, manages to avoid the heightened expectations and subsequent disappointment that users feel when Siri fails to listen as well as it promises to. It may be less competent overall, but what it does do it does predictably and well.

A comparison that came immediately to my mind was Apple’s mid-1990’s failure with the Newton handheld computer. The ambitious handwriting recognition was pure magic when it worked, but failed to work a significant amount of the time. Meanwhile, Palm took a more pragmatic approach with Graffiti, an overtly limited interpretation of the Roman alphabet, Arabic numerals, and a few other widely used symbols. By dramatically diminishing the magic of its handwriting recognition technology, Palm dramatically increased its reliability. Users seemed to appreciate this compromise, as Newton sputtered, and Palm Pilots went on to define the whole genre of hand-held digital assistants.

As much as I like this comparison, I don’t think Siri is doomed in the same way Newton was. Handwriting recognition was a primary interface on Newton, while with iOS devices it’s usually considered an augmenting interface. You can, and many people do, get plenty of use out of an iPhone without ever relying upon Siri. Siri is also nowhere near as unreliable, in my opinion, as Newton handwriting was. I use Siri on a daily basis and, perhaps because I’ve rarely tried anything better, I still find it an overall boon to productivity.

I think we are still in the early days of speech recognition, which feels funny to write because back in the mid-1990’s when Apple was failing to perfect handwriting recognition, they were doing the very same thing with speech recognition. But as John and Ben said on the show, none of the existing technologies, whether from Apple, Amazon, Microsoft, Google, Nuance, or others, is even close to perfect. There is so much interest now in the technology, that it’s possible to at least imagine extremely fast, reliable, predictable speech recognition becoming the norm. Whether the standard ends up being a shorthand-based approach such as Amazon is taking with Alexa, or a more ambitious artificial intelligence, may depend on which company can close the gap faster using one approach or the other.

Paid App Store Search

Bloomberg set off a wave of fear, uncertainty, doubt, and skepticism with their report alleging Apple’s plans to offer paid placement in App Store search results:

Apple is considering paid search, a Google-like model in which companies would pay to have their app shown at the top of search results based on what a customer is seeking.

Putting aside the fact that such a move seems un-Apple-like, I don’t see how it would benefit Apple, either.

Google sells placement in search results because that is the core of their business model. When a user finds and clicks a non-sponsored link in search results, it may serve Google’s ambition to collect information about users, but it doesn’t earn them any money. Without paid placement in Google search results, Google probably wouldn’t exist.

Apple’s overall business model is selling hardware with high profit margins. The business justification for the App Store is multi-faceted: its purpose is first to enrich Apple’s hardware products with novel third-party functionality, and second to generate revenue in the form of that 30% cut that developers love to complain about.

To this end, it’s in Apple’s best interests to ensure that the intersection of the best and the most profitable software is presented to users in the App Store. This is probably why the tired old high-level charts are broken down by “Free,” “Top Paid,” and “Top Grossing.” Items that rise to the tops of of those categories are most likely to serve Apple’s business justification for the store.

Allowing third parties to pay for placement in the App Store would not contribute to Apple’s justifications for the App Store in any way. Who benefits from such a change? The businesses paying for the placement, presumably. It’s hard to see how paid placement would consistently benefit either Apple or its direct customers. It’s unlikely that paid listings would be used to highlight apps that are in line with Apple’s other goals for the store.

I hope that Bloomberg’s report indicates that Apple is indeed brainstorming many ideas for improving search and inventory presentation in the App Store, but count me among the very skeptical that paid placement will be among the ideas that the company actually follows through with.

Distance Based Reminders

You’re driving down the highway, across the desert, on a long road trip. You see a sign:

Gas 16 Miles

Next Gas 203 Miles

You glance at the fuel gauge and observe that the tank is running low. Your first thought is: “Dang! I better not miss that exit, or I’m hosed.” So you activate your nearest Siri device and speak:

Hey Siri, remind me in 15 miles to get gas.

Okay, I’ll remind you.

Ahh, you relax back into your chair, crank up the Apple Music, rest assured that all will be taken care of. My, isn’t the future great?

45 miles later you’re stuck in the middle of the desert with no gas, no cell coverage, and limited battery life on your stockpile of iOS devices. You look at your Reminders list to figure out what went wrong:

In 15 miles to get gas.

There it is, on the list. Ungrammatical, uncompleted, unhelpful, uncool.

How would this be solved? By introducing a notion of distance-relative reminders in iOS and by extension in Siri. In the same way that Siri allows you set a reminder for a specific time or for a relative time from now, it should offer the same functionality for distance.

There are other scenarios where this kind of position-relative reminder would be helpful, and it sort of plays into the same kinds of reminders currently offered by e.g. “Arriving Home”, etc.

Imagine you’ve headed out for a run, for example, and intend to cover 6 miles. Just lift your watch and speak:

Hey Siri, remind me in 3 miles to turn around and head home.

In any event, Apple could amend Siri so that it recognizes phrases of relative distance, and cops to not being able to help:

Remind me in 3 miles to turn around

I’m sorry, I’m afraid I can’t help you with distance based reminders… (YET!)

I love Siri, and I’m pretty happy with most of what it does. But the possibilities for improvement are literally limitless. (Radar #25728339).

Bad Preference Gatekeeper

With the release of OS X 10.11.4, developers of standalone preference panes face a new challenge with respect to users installing their software.

Apparently, the validation process that Apple applies to downloaded software, Gatekeeper, fails to validate OS X preference panes, even if they are signed with a legitimate Developer ID code signature.

The upshot of this is when users download a bona fide 3rd party preference pane such as Noodlesoft’s excellent Hazel, instead of having the software install as expected, a scary warning is displayed indicating the purported untrustworthiness of the software.

According to Paul Kim of Noodlesoft, the problem affects every preference pane he’s tested, including a freshly built, completely plain preference pane built with Apple’s latest tools. I put this to the test in Xcode 7.3, running on 10.11.4, by creating a new Preference Pane project from Apple’s template, setting it to sign with my Developer ID, and creating a release build of the project.

Running Apple’s “spctl” tool on a binary is a reasonably approximate way of determining whether Gatekeeper would reject the binary after downloading it from the web. Here’s the result for all the affected preference panes:

% spctl -av ./TestPanel.prefPane
./TestPanel.prefPane: rejected
source=obsolete resource envelope

Ah, that pesky “obsolete resource enveloped” message. Those of us who survived the transition from Version 1 to Version 2 code signing remember it well. But it’s not an accurate assessment in this case:

 % codesign -dv ./TestPanel.prefPane              
Executable=/Volumes/Data/daniel/Desktop/TestPanel 2016-03-31 14-03-51/Products/
Sealed Resources version=2 rules=12 files=2
Internal requirements count=1 size=220

The “version=2” indicates we are using an appropriate version for the signed resources. It would be hard, perhaps impossible, to do otherwise on a modern system with a modern Xcode toolchain.

The “spctl” tools supports a command line option to ask for more and more verbose results by adding “v”s to the command line. Unfortunately “spctl -avvvvvvv” doesn’t yield anything more informative than the seemingly inaccurate “obsolete resource envelope.”

I wondered if there was some magic flag that preference panes must now exhibit, or some new requirement that internals be signed in a different way than before. Surely, if anybody could get this right, it would be Apple! Their “Network Link Conditioner” is the only downloadable preference pane I could think of, and what do you know, it was updated as part of the Hardware I/O Tools for Xcode 7.3 download package, released on March 20. I downloaded a fresh copy to be sure I had the best that Apple could offer, located the preference pane, and double-clicked it.


You know it’s bad when even Apple’s own downloads are portrayed as untrustworthy.

This is a minor annoyance for folks trying to install an obscure development tool, but it’s a major issue for developers like Noodlesoft whose entire livelihood is built on the distribution of software packaged as a preference pane. The scary wording in the dialog casts doubt on the reputation of the developer, and for the more savvy, on the reputation of Apple’s ability to properly assess the trustworthiness of software that we download.

Let’s hope Apple can address this problem soon. Although it doesn’t pose a security risk, it seems appropriate that they could include this in a security update. After all, it has everything to do with preserving trust between users, developers, and Apple.

Update: According to Paul Kim, it’s not just preference panes that are affected, but any standalone non-app code bundle. So, for example, color palettes, screensaver modules, and, if anybody ever used them anymore, Dashboard widgets, are all affected. Pretty, pretty, pretty, pretty bad.

(Radar #25468728)

iPhone SE: No Room For Doubt

Last week, Apple announced the iPhone SE, a long-awaited update to the 4-inch class of iPhone. After the release of larger iPhone 6 and iPhone 6 Plus models, many fans of the smaller form factor worried that Apple might be abandoning it for good. Their fears have now been assuaged.

Even though I was worried and skeptical about the transition to iPhone 6, I have to admit I have mostly gotten used to it. I don’t know that I will return to the 4-inch sized phones, but the iPhone SE sure makes a compelling argument to do so.

What’s great about the iPhone SE isn’t just its smaller size. It’s great because it also lacks many of the design shortcomings, petty as they may be, that its grander siblings possess. The so-called “camera bump” that breaks the perfectly smooth surface of the iPhone 6? Not there on the SE. The reviled movement of the lock button to the side of the phone, where it’s easier to press accidentally? Not an issue. Even the fact that the SE allegedly has a slower touch ID processor will not be viewed as a flaw by people who are tired of accidentally unlocking their phones when they wake them to view their lock screens.

The iPhone SE is great because it doesn’t cast doubt on Apple’s design sense.

I am sure that all the design changes in iPhone 6 were done with good reason. The camera bump affords a higher-quality camera. Moving the lock switch may have been necessary to accommodate a slimmer profile. And the phone unlocking accidentally while you hold it is the tradeoff for the freaking amazing, gloriously fast intentional unlocking.

But the iPhone SE will be viewed by many as, and in fact it may be, a better phone. It’s great not because it’s as fast as, or can take as great pictures as, or can be unlocked as easily as the iPhone 6. It’s great because it leaves no room for doubt as to what it’s designed to do, and how it does it.

New Apple products never fail to offer enticing new functionality, but these amazing new features increasingly come with a “but.” Apple’s user base has grown accustomed over years to expect the great design. Design choices that have to be explained to be understood cannot be considered great. They are good, possibly even “best under the circumstances.” But a great design leaves no rough edge to be scrutinized, no accident-prone switch to be suffered, no “so good it hurts” performance optimization. Great design leaves no room for doubt that every detail was considered, and that every compromise was somehow, delightfully avoided.

Make Wooden Toys

Like many developers struggling to make a living in the increasingly price-sensitive, App Store-influenced market, I was somewhat discouraged by Rene Ritchie’s excellent “What no indie developer wants to hear about the App Store.”

Rene argues that the app economy is moving towards cheap, mass produced, bargain-priced software that is simply not suitable for sustaining small-time indie software businesses. He adopts a beautiful metaphor, borrowed from his own childhood: the classic wooden toy.

When I was a child, all my favorite toys were wooden, painstakingly carved by artisans who ran the store near my home. I cherished them. Today those kinds of toys are all but gone, and that business model is no longer viable in the mass market.

Ugh. He’s right. Everything is cheap plastic, nowadays. Or is it?

If I pull up a mental inventory of my own kids’ playroom, there are indeed a ton of cheap, plastic toys. But there are also a good number of, wait for it, quality wooden toys.

Wooden toys are still being made! Shout it from rooftops, my indie brothers and sisters! If your inspirations and ambitions were flayed by Rene’s dose of reality, perhaps this will serve as an inspiring salve: do a Google image search for “wooden toys“. Those aren’t antiques…

I remember when my kids were younger, marveling at the powerhouse of wooden infant toys, Melissa & Doug. If you have a baby and are part of a socioeconomic culture that can sustain it, you have seen these toys. They are everywhere. And they are far from cheap.

So? Make wooden toys. Metaphorically speaking, I mean. (Unless, like Gus Mueller, woodworking has been your backup plan all along.) Make software that is inspired by wooden toys. Although the market is dominated by cheap plastic, there is real money for thoughtful, careful developers in the market that favors charming, slightly overpriced throwbacks to another era. Make wooden toys.

Selectively Smart Typography

OS X offers a system-wide feature to “Use smart quotes and dashes” when typing text. The option can be enabled or disabled in the System Preferences “Keyboard” pane, inside the “Text” tab:


This essentially ensures that when you rattle off a bit of prose, any quotation marks will be “smartened” so that they curl inwards towards the quoted phrase, and sequences of double-hyphens will be converted to typographic dashes.

It’s a good thing.

However, the feature can be vexing when typing in contexts where typographic beauty is clearly not the priority. For example the behavior would not make sense in a code editor like Xcode or BBEdit. These apps are more often used to write text that will please a programming language compiler or interpreter, where a string for example must be enclosed by "straight quotes", and “smart quotes” would only lead to a syntax error.

Apple actually makes it possible for developers to control the behavior of this smart typography on a very fine-grained basis. For example, my own app MarsEdit features an HTML text editor in which it makes sense to support smart quotes and dashes, but not within markup tags. Because the app is aware of when the user is typing within a tag or not, it simply disables the functionality as appropriate for the context.

Depending on the apps you use, and what you use them for, you might find yourself vexed by the unwanted conversion of quotes and dashes. You could turn the feature off at the System Preferences level, but what if you want to keep it in all the other apps where it works just as you want it to?

Thanks to the flexibility of Apple’s “user defaults” system for registering preferences on a system-wide and app-specific basis, you can impose override preferences for these options on the specific apps of your choosing. I was inspired to write this article by Jesse Atkinson, who complained on Twitter that the behavior was meddling with his code snippets in Slack:

So, here’s a general recipe for overriding the settings in any app:

  1. Quit the app.
  2. Determine the “bundle identifier” for the app. Slack’s, for example, is “com.tinyspeck.slackmacgap”.
  3. Open the OS X Terminal app.
  4. Type the following commands to impose overriding defaults for the pertinent features:
    defaults write com.tinyspeck.slackmacgap NSAutomaticDashSubstitutionEnabled -bool NO
    defaults write com.tinyspeck.slackmacgap NSAutomaticQuoteSubstitutionEnabled -bool NO
  5. Reopen the app.

You should now find that this specific app behaves as though the system-wide setting for these features were turned off.

If you want to undo your handiwork, just delete the overrides you put into place:

  1. Quit the app.
  2. Open the OS X Terminal app.
  3. Type the following commands to delete the overriding defaults:
    defaults delete com.tinyspeck.slackmacgap NSAutomaticDashSubstitutionEnabled
    defaults delete com.tinyspeck.slackmacgap NSAutomaticQuoteSubstitutionEnabled
  4. Reopen the app.

If you’re a Slack user who has also been annoyed by the smart quotes and dashes functionality, the above may prove helpful to you. If you’re not, maybe a similar situation will arise where you can use the power of OS X’s default registration system to fine-tune the behavior of your favorite apps.

Update: My old friend Chris DeSalvo, who also happens to work at Slack on the Mac Slack app points out that there is a much simpler solution for Slack in particular:

I just confirmed that this seems to work well with Slack! So was this whole article for naught? In my experience, toggling the Substitutions flags as Chris describes only changes the setting temporarily. This is because those menu items within an app are usually configured to communicate directly with the text field you are focused on. A developer has to go out of her way to intercept and persist such a toggle, to ensure that it “sticks” the next time the app launches.

So! If you have this problem with Slack, just toggle the setting in the Edit -> Substitutions menu. With most other apps? Perhaps the technique outlined above will help.

Call To Action

Twitter just announced two new features aimed at facilitating customer service across the service:

      A custom link format for inviting customers to initiate a direct message.
      A method for soliciting feedback from customers about quality of service.

Of the new features, only the first is available immediately to all Twitter users. I was intrigued by the feature because I imagined it eliminating the uncomfortable process of businesses either having to ask customers to follow, or setting their direct messages to be “open” to anybody. Unfortunately, the feature does nothing to empower direct messaging between two consenting parties. It serves only as a shortcut for initiating a DM that would already be permitted:

Using this new feature is easy. It requires that your Twitter account settings are set to “Receive Direct Messages from Anyone”…

I guess being open to “direct messages from anyone” is a viable approach for some businesses, and maybe it is even the right choice for any business wanting to remain completely accessible to customers. But my experience turning the feature on for my private account was that it led to unwanted solicitations. Although I generally want to remain accessible to people, it was an invitation for nuisance inquiries.

I hoped upon seeing the news of this feature, that it might have been a feature that allowed a temporary, targeted permission to DM. This would be useful for businesses but also for individuals who are hesitant to either follow a person or open up DMs completely, but nonetheless wish to communicate privately for a short time.

My vision for the feature is close to what Twitter has announced: you would still tweet a “magic URL” to somebody empowering them to open up a DM conversation, but the very act of sending that URL to a person’s (@-messaged) account would open a hole in your DM permissions allowing them to reach you even if you neither followed them nor had completely open DMs turned on.

I imagine a scenario where the presence of such a link implied consent to DM for 48 hours or so, and where every response by DM to that user would extend the consent for another interval of time.

This would facilitate more direct, nuanced conversation between Twitter users, without forcing them to choose whether to be completely vulnerable to the world, to establish unwanted, short-term follower connections, or else more likely, avoid the interaction altogether.


I have been an ardent Apple fan since 1993, when I got my first Mac: a PowerBook Duo 210. From then, to the day I joined Apple in 1996, to the day I left in 2002, to present day, one thing has always been true about Apple: they are not a typical tech company. Pushing against the status quo has in many respects been a defining characteristic of the company, through down times and up times. Apple does what it thinks is right for itself, for its customers, and to some significant extent, for the world at large.

Tim Cook shared yesterday in A Message to Our Customers one example of Apple’s atypical attitude rearing its beautiful head. In response to the FBI’s demand that Apple supply custom software that would allow the agency to unlock an iPhone held as evidence, Apple tendered its refusal:

Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.

The news has split public sentiment in predictable ways. There will always be a contingent that believes law enforcement should be aided in any feasible manner, regardless of long-term implications for individual privacy or civil liberties. And there will also be people so cynical about government and the police, that even Apple’s cooperation thus far, handing over information that it does possess, is viewed as a betrayal of customer rights. And of course, there is a massive group of folks in the middle, who aren’t sure where the line should be drawn.

Apple has a clear sense of where the line should be drawn, and they have stated it: they will not weaken the security of their products for the benefit of the FBI or (presumably) any other agency. Although the current request from the FBI only applies to an older iPhone model, whose security is easier to circumvent than later ones, the point Apple emphasizes is that complying with the order would be a terrible precedent for putting the needs of government ahead of the personal security of end-uers.

To my mind, this is a fine place for Apple to draw a line.

Other tech companies with huge investments in the consumer market should be lining up behind Apple in defiance of the FBI. To do otherwise, whether by explicitly defending the FBI’s demands, or by implicitly approving in silence, would be a betrayal of their own customers. It would be wrong both from an ethical perspective with respect to their duty to protect customer data, and from a PR perspective with respect to the public’s perception of their managing that duty.

If a couple other large companies, say Facebook and Google, come to Apple’s side, it will send a powerful message to the FBI and the rest of government. If a dozen large companies do, it will create a firewall that will be difficult for government to dismantle without very publicly reiterating and reaffirming its disdain for personal privacy.

I think it’s best for all parties if the “firewall” scenario comes to pass. The stage is set for a civil rights showdown, and while we need to speak out as individuals, we can also benefit enormously from the powerful voices of these tech giants.

But if other companies don’t step up, I’m not sure all is lost. Apple, as the largest American tech company, which also has the largest cash reserves, is well-suited on many fronts to fight this battle. Alone, if necessary.

People have criticized Apple for amassing a giant pile of money while never giving completely convincing explanations for what it plans to do with it. When your modus operandi is not only to push the leading edge of personal technology, but also to defend your customers’ personal data, and to possibly help establish the legal precedent that will defend the customers of all tech companies for decades to come, you never know when having $200B to “spare” might come in handy.

As a stockholder I don’t relish the idea of Apple burning through all that money just to defend their right to protect customer data. Although it’s arguable that it would be money well spent, it’s not an obvious, ideal use of shareholder equity in a public company. Luckily, I don’t think the cash will be spent. The $200B serves mainly to fortify Apple’s resolve in defying the FBI. Apple’s courage in the face of threats to its pro-consumer security policies is bolstered by the strength of those massive cash reserves.

Some may see this confrontation between Apple and the FBI as an industry vs. government dispute, but it’s far more than that. As personal technology and the internet permeate almost every aspect of wider society, the “tech industry” is indistinguishable from society as a whole. The right to defend our personal information, and the rights of companies to act on our behalf in that pursuit, are completely and inexorably tied to our rights as members of society. Eventually, we must win the right to protect our data from government. Apple, Google, Facebook, and other tech giants can step up to help us secure these rights today, or we’ll have a longer, harder fight ahead of us in years to come.

Lazy Password Storage

When you run an app on your Mac that connects to a secure web service, how confident are you that the password will be treated with care, and protected from prying eyes?

As a rule, Mac developers are pretty responsible about storing passwords and other private data in the OS X system keychain but, of course, there are exceptions.

I found a handy trick for uncovering passwords stored insecurely by applications directly to their preferences storage. The trick takes advantage of a cool functionality of the OS X “defaults” command line tool, which you can run from the “Terminal” app:

'defaults' [-currentHost | -host ] followed by one of the following:
  find <word>     lists all entries containing word

How convenient: a simple command line tool to search the entirety of all the preferences stored by all of your apps. So, a good first step would be to simply search for “password”:

defaults find password

On my Mac, this yields an overwhelming number of matches that includes a lot of false positives such as, for example, the preferences pertaining to 1Password, preferences pertaining to apps’ password dialog windows, and other innocuous uses of the term.

It occurred to me that most developers storing passwords insecurely in preferences would probably store the value either under the key “password,” or some variation such as “twitterPassword”. So I tweaked the command line to try to filter out these results. The “defaults find” command doesn’t take any options, but I can winnow the results using grep:

defaults find password | grep -i -E "password\"? ="

This grep invocation searches for case insensitive matches for “password”, optionally followed by a quotation mark, then a space and an equal sign. In other words, examples where a key that ends in “password” is being assigned a value.

This actually did reveal some problematic password storage on my Mac, but the grep is so good at filtering out the results, I can’t see which app to blame. I need to match ALL the lines that pinpoint the app, and all the lines that looks like they store a value into a password. Add an | (or) case to the grep expression to match for the tell-tale signs of the lines that summarize findings per-app:

defaults find password | grep -i -E "password\"? =|keys in domain"

Here I find a neat summary of potentially problematic password storages. Some of them remain false positives, but the list is now small enough to easily interpret. Any example where the app is something I plan to use again, I’ll be in touch with the developer to encourage them to improve the password storage security. Any example where the app is nothing I’ll ever run again?

defaults delete com.example.lazyapp

And the insecurely stored password is obliterated from my preferences.

Obviously this trick won’t match all the careless password storage that apps on your Mac may be committing, but I suspect it will root out a good number of them. Experiment with the grep commands to filter out based on different, less restrictive matches. You might also have some luck searching for examples of apps that store other sensitive information such as credit card numbers, secret questions and answers, etc.