Named Watch Faces

It’s starting to look as though it will be common with watchOS 3 to configure multiple watch faces for different life contexts. It will now be easier than ever to swipe between watch faces, and multiple faces of the same base kind can even be configured with different complications suitable to a particular context.

To drive this home and aid in reminding users the intention for each face, it would be useful to apply our own names to them:

“Exercise”
“Work”
“Weekend”
“School”
“Relaxing”
“Childcare”

Best yet, giving names to the configured watch faces provides Siri with a handle for affording seamless integration, such that you could easily switch between the named faces with phrases like:

“Hey Siri, put on your Game face.”

Anything I expect to do frequently on my Watch, I will value being able to do hands-free with Siri. In order to achieve that, everything I would like to switch to, activate, or deactivate, needs to have a name. I wrote previously about this in Labeled Siri Alarms, so I guess my head is in a place where I’m looking for every opportunity to enlist Siri’s help. This is one area where I think I would use such help many times per day.

(Radar #26883175)

Labeled Siri Alarms

I’ve written before that Siri, in spite of its flaws, is improving quickly. To that end, I occasionally challenge myself to think of ways that it might make my repeated tasks even more effortless.

I alternate mornings with my wife, taking either our 4-year-old, Matthew, to school, or our 7-year-old, Henry, to a different school. The responsibilities come with a different wake-up time, so I have two pre-set alarms in my phone: one for 7:00AM, and one for 7:45AM.

On a typical weeknight I set one or the other, either by tapping into the Clock app and toggling it on, or by asking Siri to for example “wake me up at 7:45AM.” It’s smart enough at least to notice the existing alarm, and doesn’t set a redundant one. Today I thought it would be nice to add labels to my alarms, so that when I’m awakened, any doubt about what my responsibilities are will be quickly clarified:

Image of Clock app configured with labeled alarm

Having labeled the alarms, I thought I’d test Siri’s prowess: “Hey Siri, set my Henry School Day alarm.” Sigh. No dice:

Image of Siri interface with request to set an alarm not understood.

Here’s an example where Siri is frustratingly dense about something that seems so obvious, at least in retrospect. All is not lost, though. It turns out that although it doesn’t have a clue what “my Henry School Day alarm” is, it knows full well what “the Henry School Day alarm” is:

Image of Siri interface accepting request to set an alarm by label name.

I’ve filed Radar #26696594 requesting that “Siri should recognize MY alarms as readily as THE alarms”.

Not Perfected Here

Almost two years ago, Apple announced Swift, their next-generation language. Politically, it seems poised to imminently succeed Objective-C as the de facto standard language for Apple platforms. Practically, there are many questions.

Since the language’s debut, people have been pointing out the impedance mismatches between Swift, a type-safe and statically compiled language, and Objective-C, an unusually dynamic, almost “anything goes” language in which objects can be magically bound to do one another’s bidding at run time as opposed to compile time.

Brent Simmons recently ignited a round of (mostly) thoughtful analysis about the dynamic shortcomings of Swift, and whether Apple will eventually fill the dynamic void left by Swift, when they inevitably update their core frameworks to accommodate the new language.

Paul Kim, a long-time Mac developer, whose experience with AppKit goes back to the NeXT days, wrote a balanced defense of Objective-C’s dynamism. He concludes with an acknowledgement that many of the people who might contribute practical feedback to the Swift team about how it would best serve app developers, are too busy shipping apps:

What I do see makes me worry that it’s not the experienced app-writers that are being heard. Unfortunately, many of us are too busy to sit in the various mailing lists and forums. Yes, ok, we lose. But we all lose if those creating the platform don’t draw from the experience of those who have built upon it successfully.

It would be OK that a majority of established 3rd party app developers can’t embrace and offer feedback about Swift, so long as Apple were buying into the language internally and ironing out all the kinks on their own. But how can they? Apple is in all likelihood the single largest owner of valuable, time-tested, customer-pleasing Objective-C code. Thus they face, as a company, the same challenges that Paul Kim and many other developers do: they can’t afford to put everything on the line, divert all their attention from Objective C, just to embrace a language that is not completely mature, and which doesn’t offer the same features as its predecessor.

If Apple’s long-time Mac and iOS developers, and the company’s own internal framework developers, are not yet empowered to dive head-long into Swift development, who is? Early adopters. Very early adopters. God bless them. Unfortunately, Swift’s early adopters will become experts in precisely the techniques that the language currently affords, as they aren’t motivated to push the language in the direction it needs to move to accommodate long-time Objective C developers, and … Apple itself.

I have to imagine Apple is stewing on this problem internally. Hopefully they have some brilliant thinking on the subject, some of which will come to light at WWDC in June. In the mean time, Apple faces an unenviable conundrum: the growing number of Swift experts in the world are predominantly neither employed by Apple, nor familiar with the design patterns that have set Apple’s frameworks apart from the competition for at least 15 years.

Swift is a fascinating, beautiful language. How will it evolve to prove superior, in the long-run to Objective-C? By providing a suite of impedance-matched frameworks that fulfill all the needs of current iOS and Mac developers. How will those frameworks come to be in an environment where Apple’s most experienced framework developers, and Apple’s most experienced 3rd-party developers are steeped in a tradition that favors patterns not supported by Swift? I’ll be very eager to see how that plays out.

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.

Untrusted

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:

Keyboard

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.