Marco.org • About ▾

I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Live with Phil

John Gruber’s live performance of The Talk Show at WWDC was unusually special this year.

It was announced and sold out without John specifying any guests. He didn’t hype it up or drop any enticing hints. Nobody knew who would be on stage until they walked through the curtains, but we all assumed it would be some of the developers, journalists, and friends who usually join John to give The Talk Show its great personality.

But after a brief introduction from Merlin Mann and Adam Lisagor, John introduced, “and I shit you not,” Apple’s senior vice president of marketing, Phil Schiller.

Being familiar with John’s dry humor, I’m not sure most of the audience believed him. Many cheered. Some hesitated. For a few seconds, nobody walked out, and people started laughing, thinking they got the joke.

And then Phil Schiller really walked on stage.

Apple doesn’t do this.

Apple executives rarely speak publicly outside of Apple events, especially for live interviews. One of the highest-ranking executives of the world’s highest-profile company being subjected to questions, unprepared and unedited, in front of a live audience full of recording devices, is rarely worth the PR risk: the potential downside is much larger than the likely upside. Do well, and a bunch of existing fans will like you a bit more; do poorly, and it’s front-page news worldwide.

Both Apple and Phil Schiller himself took a huge risk in doing this. That they agreed at all is a noteworthy gift to this community of long-time enthusiasts, many of whom have felt under-appreciated as the company has grown.

With the wrong interviewer, this could’ve been a recitation of PR-friendly softball questions with perfectly designed, talking-point responses that would’ve gone nowhere and benefitted no one. But Apple PR doesn’t want that any more than the audience does.

Or it could’ve been boring questions about hardware rumors that no Apple executive would ever answer. I’ve never seen another interviewer that didn’t waste time on these dead-ends that, in their wildest dreams, might answer questions relevant only for a few short months or years.

But John Gruber is better than that, and we all know it, including Apple.

John asked real questions on challenging subjects, including gender diversity, my alleged software-quality decline, discoveryd problems, thinness trade-offs with battery life, the new MacBook, continuing to sell 16 GB iOS devices, and whether the Apple Watch should have shipped without WatchKit 1.0 apps since the native SDK was so imminent.

And Phil gave real answers to each one. Apple iterates, argues, and evaluates trade-offs. Sometimes they don’t get it right. Sometimes they’re more aggressive pushing the tech forward than power users like us think they should be. Sometimes there are trade-offs in product design that we don’t consider, or that we prioritize differently than they do.

Phil made quick, smart, informed references to Apple-related podcasts and sites, including mine, that made it clear that he personally reads and listens to our community.

I’ve heard that this was the case for Phil and many other Apple higher-ups for a long time, but I’m not sure it has ever been made so clear publicly.

Apple is listening.

Between the serious and technical discussions, Phil and John lightly joked about typography and sports teams with each other and the audience.

They had the great rapport of professional acquaintances who’ve known each other for a while and clearly respect each other.

I’d listen to their podcast.

Apple is just people. Their usual communication style makes that hard to see and easy to forget.

Phil’s appearance on the show was warm, genuine, informative, and entertaining.

It was human.

And humanizing the company and its decisions, especially to developers — remember, developer relations is all under Phil — might be worth the PR risk.

Or maybe he just thought it would be cool. He’s a pretty cool guy. I’m glad we got to see that, and we got to see that because of the career, personality, and perspective that John Gruber has been building for over a decade.

John has always seemed to want The Talk Show’s annual live show at WWDC to resemble his fond childhood memories of the Johnny Carson late-night TV talk show. Past years have been closer to that format and pacing, but this was nothing like it at all.

John isn’t Johnny — John is better. And I’d much rather watch this show than anything on TV. Talk shows on TV must be liked by everyone; podcasts sell out live venues by being loved by a niche.

This meant a lot for both John and podcasting. Apple sent an executive to be interviewed on a podcast, and one of the highlights of John Gruber’s career as a writer didn’t involve writing at all.

I’m just hoping he can get Moltz for next year’s show, because I sure as hell wouldn’t want to follow this.

Special thanks to the App Documentary guys for lending me the camera to shoot these photos at the event.

Freemium is hard

In How I Killed App Sales By Going Freemium, Shuveb Hussain recounts switching his send-to-Kindle app from $1.99 up front to a free-with-in-app-purchase model:

This is what I came up with: A free app that allowed 10 free articles initially, enough for users to get a taste of the service. After these “article credits” ran out, users would still be able to send one article every day for free. To overcome the one article per day restriction and send articles anytime, users could buy “article credits” via in-app purchases and send articles anytime.

Actually, one article per day was enough for most users. […]

In the past 20 days, Comfy Read 2 has seen just 5 in-app purchases.

Freemium is hard. Its effectiveness depends on where you can put that purchase barrier in your app. Many app types simply don’t have a good place for it.

In this case, Shuveb faces the fatal combination of two major problems:

  1. His app is a lightly used utility, but he only stands to make money from heavy use. His free tier is good enough for most users.
  2. His purchase barrier — more than one article per day — discourages more frequent use, which hinders habit-building. When faced with a paywall, most people will try to avoid it unless there’s a compelling reason to pay. The few customers who hit Comfy Read’s paywall probably just think, “I guess I won’t send this article to my Kindle,” or “I guess I’ll use another app for this.” Users aren’t given the chance to let the app become a crucial part of their workflow or build any loyalty toward it, which would make them more willing to pay, before hitting a paywall.

These seem like opposites: the free tier is both good enough and not good enough. What makes freemium so tricky is that these can both be true simultaneously, and for many app types, this can’t be resolved. That’s why it’s so hard for many apps to succeed with a freemium model.

I spent months debating which features should be behind Overcast’s in-app purchase. If I limited the number of subscribed podcasts for free users, I’d be discouraging people from trying new podcasts. If I put Smart Speed, Voice Boost, and my smart playlists completely behind the paywall, most users would never experience my best features and wouldn’t think my app was very good. But if I kept the paywall too easy to avoid, like showing ads with a purchase to remove them, it wouldn’t sell well. (No-ads upgrades never sell well, by the way.) And whatever features I limited would be free in many competing apps, including the one Apple includes on every iPhone for free.

What I came up with — unlimited general usage and most features being free, with limited demo-like access to premium features before purchase — was a tricky balance and a compromise. Freemium always is.

Paid-up-front isn’t always easy and doesn’t always sell well, but it is much simpler.

Disabling Turbo Boost to get more MacBook Pro battery life

The best battery life in the 15-inch Retina MacBook Pro line is the base model (without the high-powered GPU), but Apple’s stated 8–9 hours of battery life is only achievable with very light use — if you’re using tools like Xcode, Logic, or Lightroom, you’re lucky to get more than 4 hours.

I used to eke more battery life out of my 2008 MacBook Air by underclocking and undervolting its CPU to a lower speed with CoolBook, but that’s no longer possible on modern Macs.

Modern Intel CPUs use Turbo Boost to dynamically increase CPU speed, depending on workload, up to their thermal limits. The advertised clock speed — 2.2 GHz for the base-model 15-inch — is only the guaranteed minimum.

Turbo Boost Switcher can temporarily disable Turbo Boost, and I was curious to see if disabling it would meaningfully affect battery life.

I devised a simple battery-testing script to simulate light and moderately heavy loads on my brand new, mid-2014-generation, base-model 15-inch Retina MacBook Pro: it loads some popular websites in Safari over Wi-Fi, spending some time scrolling down each one, while playing music in iTunes, then appends the time and battery status to a file in Dropbox, which promptly gets synced. This cycle repeats indefinitely. For the moderately heavy load, the cycle also includes a clean and full compile of Overcast’s iOS app using xcodebuild every few minutes.

I ran this test at 50% brightness (with auto-adjustment disabled), no keyboard illumination, and sound muted until the battery ran out and it shut down. Before running the test, the battery’s cycle count was just 2.

When plugged in and fully charged, I also ran the Geekbench 32-bit single- and multi-core benchmarks, and observed the power range drawn from the wall with a Kill A Watt.

Results

My “Heavy” numbers with Turbo Boost line up well with the very similar 2013 model in AnandTech’s “Heavy” battery test, which gives me confidence in my test. While AnandTech’s “Light” test appears lighter than mine, neither of us could reach Apple’s “8 hour” claim for this model, which is disappointing.

Turbo BoostOnOff
Idle power21W21W
Geekbench power58–75W36–45W
Peak CPU temp.90°C60°C
Geekbench single3,1302,143
Geekbench multi11,7668,369
Average Xcode build22 sec30 sec
Average web loop133 sec134 sec
Battery Life, Heavy4:025:10
Battery Life, Light5:407:07

Disabling Turbo Boost hurts performance of CPU-intensive tasks by about a third, but doesn’t significantly slow down lighter tasks. The MacBook Pro also runs noticeably cooler, and gains about 25% more battery life.

This won’t be worth doing all the time, but it’s nice to have the option.

And I’d still like to see higher battery capacity in normal operation. This is far from a solved problem, and far from any reasonable definition of “all-day” battery life. I hope Apple agrees.

Why not Google?

In Upgrade episode 38, Jason Snell and Myke Hurley had a great discussion about their use of Google products as Apple fans, and asked listeners to tell them why they do or don’t use Google products.

Their main argument was that both companies have flaws and sometimes do bad things, but Google’s services were the best, so any ethical differences were a worthwhile tradeoff to them.

We agree on the broad strokes, but the reason I choose to minimize Google’s access to me is that my balance of utility versus ethical comfort is different. Both companies do have flaws, but they’re different flaws, and I tolerate them differently:

How you feel about these companies depends on how much utility you get out of their respective products and how much you care about their flaws.

Simply put, Apple’s benefits are usually worth their flaws to me, and Google’s usually aren’t.

*   *   *

There’s a widespread assumption that heavy use of Google products is unavoidable and that they’re always the “best”. That hasn’t been my experience.

I’m still very happy with DuckDuckGo for search, and Apple Maps has been no worse than Google Maps for me recently. My standard IMAP email host, FastMail, works great, and the spam filtering is nearly perfect since I’ve put MailRoute in front of it — I’ve heard it’s better than Gmail’s.1

I suspect the ease of switching away from Google depends primarily on whether you use Gmail. I never have — it solves problems I don’t have, and I greatly prefer native IMAP email apps — so Google has never had deep integration with my data or a significant presence on my iPhone.

I didn’t set out to aggressively quit Google-everything, but once I changed my browsers’ default search engine to DuckDuckGo, that has mostly happened. The most surprising part was how easy it was for Google to mostly fall out of my life, how quickly it happened, and how little I missed it.

I don’t actively avoid Google today — I don’t hate them. I still participate in a shared Google Doc and calendar for ATP, and I still occasionally go to search and Maps for a second opinion. But Google has become far less relevant to me, I don’t depend on it for anything, and I feel better about that.


  1. MailRoute is a frequent sponsor of my podcast, although I started using them at a time when they weren’t, and I’ll keep using them even if they stop sponsoring. 

A Partial List of Questions About the Native Apple Watch SDK

Jeff Williams confirmed yesterday that Apple is releasing the SDK for native Watch apps at WWDC. This is a pleasant surprise a few months earlier than I expected. I have many questions, most of which I hope will be answered in two weeks:

This is very soon after Watch OS 1.0. Will it be stable but limited, powerful but immature, or the worst of both? (The best of both — stable and powerful — seems unrealistic this early for the platform.) I’m guessing it’ll be stable but limited.

The Apple Watch is much more constrained than any iPhone in screen size, battery life, connectivity, and practical interactivity. App interactions must be as fast and simple as possible, and the screen can’t be on for very long without a significant battery impact. I think designing Watch 1.0 software to be good, useful, and responsible with the most limited resources (battery power and user patience) will be harder than writing apps for the first iPhone.

Background operations and multitasking are significant battery drains. Will any be possible? If so, what new limitations will apply? (My guesses: No background refresh, no background URL sessions, aggressive termination of backgrounded apps after a brief task-completion window, and maybe continuous background operation for audio and GPS apps.)

Which Foundation APIs will be available? Will any of UIKit be available, even if it’s just the lower-level bits and pieces like UIColor and UIImage? (My guess: Most of Foundation and some of UIKit, but no stock iOS view controllers or UI controls, which will be replaced with Watch-native, simpler alternatives.)

AVFoundation, Core Image, and Core Audio are huge and complex, but required for lots of app types. Will any audio, video, or image APIs be available? Will they only be possible through limited, high-level interfaces?

WebKit appears to be missing from the Watch. What other major APIs are missing or will be unavailable in the public SDK?

Will apps be permitted that must leave the screen on for long periods, like video playback or action games?

How fast is the Watch? How much of the 512 MB of RAM will be available to apps? (My guess: A4-class performance, and maybe a third of the RAM available.)

How much storage can Watch apps use?

Presumably, Watch apps will be bundled with iOS apps. How can Watch apps communicate with their iOS counterparts? Will they be able to read shared containers, presumably only when the phone is within range? Will there be any built-in methods to sync data between an iPhone app and its Watch app?

How quickly can data be transferred to a Watch app? Can it transfer over Wi-Fi even within Bluetooth range to speed up large transfers, or will it be Bluetooth-only when possible to save power?

Will a Watch app be able to fetch data from its iPhone app whenever it wants, or only during user-initiated times such as Handoff? Will Watch apps be permitted to download large files or stream data continuously from the internet, their iPhone app, both, or neither?

I’m assuming native Watch apps can present all three current WatchKit views — apps, glances, and custom notifications. Can our glances have buttons and controls on them, like Apple’s, or not, like WatchKit glances?

Can we make third-party watch-face complications? (I assume we won’t be able to make faces.) If so, how will the many shapes, sizes, and colors be enforced for a consistent look? How often will they refresh their data? Can they make network requests?

Can Watch apps include in-app purchases?

Can our apps become locked as the “active” app that shows immediately on wake instead of the face, like Workout and Remote? (I assume not.)

Will most people’s battery life take a big hit after native apps are widespread, since more apps will likely be in frequent use, the screen will likely be on more often and for longer spans, and some background updating may be happening?

A new platform is an opportunity for Apple to advance internal political goals. Will Watch apps be required to be written in Swift? Will ads be allowed? Which app types and features that are allowed on the iPhone will be prohibited on the Watch?

On all of these, I have no idea. This will be an interesting summer.

Ads via The Deck