Twitter Optimism

Since its debut in 2006, Twitter has been free to use. As with so many other successful social networks, the strategy seems to have been to first attract a massive number of users, and then set to work figuring out how survive financially off of them.

After being conditioned over years to not pay a dime directly to the company, I don’t know that Twitter’s customers would have accepted a business plan that forced them to overtly pay for the service. Ads seem like a perfect fit, and we’re all so accustomed to trading our attention for free, or heavily subsidized services, that hardly any of us have complained.

Still, ads are obnoxious. They range from the merely obnoxious interruption of your personal timeline’s flow, graduate to the insidious obnoxiousness of ridiculous products you’re not interested in, and peak with the repulsive obnoxiousness of forcing the slogans of despised political candidates or other anathema concepts into your brain, by way of your ever-so valuable eyeballs.

What if Twitter adopted a business model that allowed them to maximize financial gain from advertising, while minimizing the obnoxious intrusion into the sanctity of your personal timeline? In fact, I think they could be on to just such a model.

On the latest episode of Core Intuition, Manton and I chatted about rumors that Twitter might soon be acquired by a larger company such as Salesforce, Google, or Disney. We agreed that each company would bring its own advantages, and threats, to the company. On the whole, though, we also agreed that Disney would be the best of the three with respect to maintaining the status quo.

Disney is a media company, through and through. Coincidentally, Twitter has aligned itself with media outlets over the years, offering high-profile integrations with major events ranging from awards shows, to sporting events, to political debates and beyond.

I suspect that as Twitter focuses more and more on these kinds of enhanced event-based Twitter streams, they will find that advertisers are keenly interested to pay a premium price for ads that target that same audience. Just as many companies will pay a massive amount of money to target the Super Bowl audience, they should expect to pay a significant markup to target the Twitter-based Super Bowl “moment.”

I’m optimistic that Twitter will recognize that the massive advertising potential of sponsored events leaves them free to leave boring, everyday social Twitter relatively, or completely ad-free. This approach would take will: it’s hard to say no to advertising dollars, and there will always be somebody willing to pay a few cents to pop and ad into Joe Public’s private Twitter feed. But selling out private timelines may be a poor investment, when Twitter could capitalize on the user trust and loyalty that will come from having their own “personal” spaces on the service treated with respect.

There are parallels in other media. For example, on television there are a few channels that are left unscathed by the blight of advertising. I don’t know whether it’s by force of Federal laws, local cable contracts, un-marketability, or some combination of the three, but for example you don’t see ads on local cable access stations or C-Span, do you? The cable industry chalks up these losses and nonetheless makes a healthy living selling ads on all the other stations that viewers inevitably opt in to watching, because they value the content.

I think Twitter’s users will continue to opt-in to their special events, because they value the content. And this self-selection is part of what makes the advertising opportunity so valuable. Finally, I don’t think users mind nearly so much when ads junk up the timeline of a public “moment,” because that content doesn’t feel, and isn’t meant to be personal. It’s mass media. We are used to advertising on our mass media, but tend to get really annoyed when it shows up on our personal chats and feeds.

Hopefully Twitter will recognize the opportunity they have to satisfy both their financial needs, and the wishes of their customers, by focusing their advertising where it really counts.

App Store Maturity

Apple announced that they will be taking steps to improve the quality of apps available in the App Store:

We are implementing an ongoing process of evaluating apps, removing apps that no longer function as intended, don’t follow current review guidelines, or are outdated.

Developers have known since early in the App Store’s history that Apple may retroactively decide that a particular app no longer merits inclusion in the store. Because of the large number of apps in the store, it has widely been thought that such reconsideration would only occur when and if a new version of an app is submitted, and thus reviewed again. This announcement, however, hints at a much larger-scale procedure, that would potentially cull thousands of products from the store.

Several months ago, developers noticed that the average review time for apps had dropped dramatically. Instead of taking several days, sometimes a week, or more, it is now common for apps to be reviewed in only one or two days. Many wondered whether some technical breakthrough made it easier to blaze through reviews. For example, improved static analysis, an automated fuzz-testing suite, or some combination of these and other techniques could reduce the need for stringent human involvement in some aspects of the review process.

There are over 2 million apps in the App Store, and Apple has effectively announced that they are prepared to re-review all of them in the name of improving overall quality in the store. This hints strongly that there has been some systematic improvement to the review process. It boggles the mind to imagine that all 2 million of those apps were in fact reviewed by humans, but that happened over the course of almost 10 years. Whatever process Apple is gearing up to apply, they claim apps will start dropping from the store as early as September 7.

It’s interesting to me that Apple feels comfortable dropping a potentially massive number of apps from the store. They have never shied away from boasting about the impact of the App Store, often focusing on the sheer size of it. They make a point in every WWDC keynote to talk about the vast numbers of developers, apps, downloads, and yes, dollars flowing through the store. Yes, if they measured success purely by number of apps in the store, they would have made their review criteria much more lenient from the start. But if they cut the number of apps for sale by a significant degree, it will be the first time in the App Store era that I remember the company emphasizing “quality, not quantity.”

I see both the decision to ratchet up quality control, and the willingness to live with the consequences of smaller bragging numbers in the store, as signs of the App Store’s maturity. When Apple debuted the iOS App Store, one of its main challenges was in justifying the very idea of an app store. Every enthusiastic update on the number of apps or amount of revenue generated by them seemed almost paranoiacally intent on proving the concept of the App Store correct.

Apple’s willingness to now intentionally deflate those metrics strikes me as a sign of cool confidence. The App Store concept has been proven valid. It was proven valid years ago, but Apple’s famous paranoia may not have allowed the defensive posture to relax until now. I’m optimistic that this change is only the first of many, in which Apple will focus less on arguing that the idea of an App Store is good enough, and more on the possibility that such an App Store can be insanely great. Hey, a guy can dream, right?

The Apple

MacRumors pointed out that Apple seems to be dropping “Store” from its store branding. The new flagship store in San Francisco, for example, is “Apple Union Square.” This has led to some criticism and guffawing from friends who now jokingly refer to any Apple Store as simply “The Apple.”

John Gruber thinks it makes sense to drop “Store” from branding, and compares Apple with other major brands whose stores do sound ridiculous with the appendage:

The “Store” branding only made sense when the concept was novel. Now that Apple’s stores are well established, it makes sense to drop the “Store”.

And:

No one goes to the Tiffany Store or Gucci Store, they just go to Tiffany or Gucci. It’s not even just a premium thing — you say Target and Walmart, not Target Store and Walmart Store.

The difference between these brands and Apple is that Apple’s identity has long been independent from the notion of a store. Calling it the “Apple Store” was not only important because the stores were a novelty, but because Apple is a brand that transcends retail. This may be true as well for Tiffany or Gucci, but when you think about these brands, I suspect you think of them in their retail context. Target and Walmart? They’re stores to the core of their being, so of course it would sounds strange to brand them as such.

Apple is a company whose products, hardware and software, have historically been sold separately from its own retail presence. Going to “Apple” will never make sense the way it does to go to “Target” or even to “Tiffany’s.” Where “Store” has been dropped, it’s essential that some other qualifier takes it place. Going to “Apple Union Square” makes sense. Asking a hotel concierge whether there is “an Apple nearby” makes as much sense as asking where the nearest “Ford” or “Honda” is.

Of course, the vast majority of people will probably still refer to any of Apple’s stores as “the iPhone store.”

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)