Overcast 3 is now available, and it’s a huge update, mostly in the design and flow of the interface. I’ve been working on it since last summer, informed by over two years of testing, usage, and customer feedback.
I designed Overcast 1.0 in 2014 for iOS 7, and it was a product of its time: it used ultra-thin text and lines against stark, sharp-edged, full-screen white sheets and translucent blur panes, with much of the basic functionality behind hidden gestures. That fundamental design carried through every update until today.
My design goals for 3.0 were:
Update the style from iOS 7 to today: More affordances, more curves, thicker fonts, less translucency, more tactility. App-design fashion doesn’t stand still, and many iOS 7-era designs now look dated.
Bring all functionality into the open: Add visible controls and affordances to anything that was previously hard to find or behind a hidden gesture, such as table-cell swipe actions and actions that first require tapping corner “Edit” buttons.
You wouldn’t believe how many customers have asked me to add features that were already there, or couldn’t find basic functions like deleting episodes, because they weren’t apparent enough in the design.
Adapt to larger phones: Enlarge touch targets and make one-handed use faster and easier, even when only part of the screen is within easy reach. I also wanted to reduce the potential for (and effects of) mis-tapping, especially around the lower left and right screen edges, which I believe will become increasingly important as future iPhones presumably get thinner side bezels.
Overcast 1.0 was designed for the iPhone 5S. Some fundamentals needed to be revisited now that the vast majority of my customers are on 4.7- and 5.5-inch screens.
Now Playing screen, card metaphor
I began by revamping the fundamental structure between the rest of the app and the Now Playing screen with a new card metaphor, which slides up from the bottom instead of pushing in from the right:
Most popular music and podcast apps have adopted slide-up methods for their Now Playing screens (including the iOS 10 Music app), so this matches what people are already accustomed to elsewhere.
It can be smoothly pulled up from the miniplayer (or just tap it), and can be smoothly dismissed by swiping down anywhere on the Now Playing screen (or tapping the “down” chevron).1
This card metaphor is carried throughout all other modal screens in the app, and they all work the same way, speeding up common tasks and greatly enhancing one-handed use.
I also redesigned the Now Playing screen itself. The old one revealed episode notes in a hidden scroll zone — you’d need to swipe up on the artwork to reveal them, which relatively few people ever discovered.
The new Now Playing screen can be swiped horizontally to reveal effects on the left or episode notes on the right, and — critically — this is indicated by a standard “page dots” indicator below the artwork.2
The Effects and Playback popovers have been consolidated into a single effects pane:3
Along with a tightening of the seek-back/forward tap zones, this moved critical controls away from the lower-left and lower-right screen edges, which are often mis-tapped when handling large phones.
Playlists, episode info, and podcast screens
Playlists have been manually reorderable since 1.0, but many iOS users never tap “Edit” buttons in navigation bars, so many people never even knew they could do it. Even for those who knew they could reorder episodes, the two-step process was cumbersome.
The new playlist screen has full-time reordering handles for faster access and better discoverability:
The old popover lacked contrast from its surroundings, had limited space, and required carefully tapping outside its bounds to dismiss, which was often clumsy when one-handed.
The new episode-info card behaves like all other Overcast 3 cards: slides up quickly, then easily dismissed by swiping down anywhere (or inward from the left edge). It can also be previewed with 3D Touch and swiped up for quick actions.
Playing, deleting, queueing
Previously, tapping an episode in the list would immediately begin playback. This is nice when you want it, but accidental input was always an issue: I found it too easy to accidentally begin playing something that I was trying to rearrange, delete, or see info about.
A lot of people also never swipe table cells (or tap Edit buttons), therefore never finding the Delete button. I’ve gotten literally hundreds of emails since Overcast 1.0’s launch asking how to delete episodes without playing them.
To address these, I’ve switched to a two-stage method: tap an episode to select it, which shows various action buttons, and tap the newly revealed Play button to play it.
I expect this to be the most controversial change in Overcast 3, as it does slow down playback, but I’ve found that it works far better and more consistently, most people accustomed to the old way get used to it in a couple of days, and it makes the app far more reliable and discoverable for everyone.
It also gave me a place to put a new button: Queue.
Some kind of “Up Next”-style fast queue management has been one of Overcast’s most-requested features since day one. It took me a long time to come around to the idea because I thought my playlists served the same role. And they mostly did, but they needed two big changes:
Easy access from around the interface to quickly add episodes to the queue.
Overcast 3’s new option for manual playlists, instead of just “smart” playlists, matching iTunes’ definitions: manual playlists only ever contain things you add explicitly to them, while “smart” playlists (previously the only kind in Overcast) are a set of rules that automatically include or exclude episodes. Many people want their queue/up-next to be a manual playlist.
The new queue features are simply Overcast playlists with special placement in the interface. If you already have a playlist named “Queue” or the default “All Episodes”, that’s used, and if not, it’s created as necessary. These show up everywhere and have full functionality just like every other playlist.
The podcast screen always had a huge design flaw. Quick: in the old screen, how do you reverse the sort order of the episodes so it plays oldest to newest?
There’s no standard for this on iOS, so I copied the desktop/web standard of a triangle indicator on the header that can be tapped to reverse the direction. Nobody ever found this, so I’ve added a clearly labeled option under each podcast’s Settings as well.
The old podcast-directory screen was filled with annoyances: podcasts you’d already subscribed to would be dimmed out and show an annoying alert if tapped, you could only add one podcast at a time, etc.
Now, everything’s visible from everywhere, the same actions show up wherever an episode is listed, and you can add multiple podcasts without having to go back into the directory for each one. (Finally.) And, of course, it’s a card, so it’s easy to dismiss by just dragging down.
Some other new stuff:
An all-new, much faster Watch app, finally natively running on watchOS 3! (The old one was watchOS 1. Really.)
And even some Swift! (This is why the app has grown from 7 MB to about 30 MB: since Swift is still young, all Swift apps still come with their own custom copy of the Swift libraries.)
Much nicer ads
When my patronage-only model effectively failed and I added Google ads last September, I had to swallow two bitter pills:
Bad ads: I had little control over the advertisers or the ad content, which could be offensive or reflect badly on my app without my knowledge. I thought I could set adequate limits, but in practice, it wasn’t good enough.
Google provides an extensive control panel that lets you block certain ad categories. Most are clearly placed in Sensitive Categories and were easily disabled before launch, like gambling, drugs, etc., but I kept hearing from customers who’d seen other ads that offended both of us. For instance, at least one listener was shown an ad for a gun, which I never even considered would be allowed with all of the “sensitive” categories turned off. But Guns & Firearms isn’t in Sensitive Categories next to drugs and gambling — it’s in Business & Industrial > Security Equipment & Services.
So I kept blocking more categories, but it was never enough to result in ads that were consistently acceptable to me.
Other ad networks exist, but they tend to be even worse, or they don’t make enough money, or both.
Mystery code in my app: I had to embed the closed-source Google ad library into my app, and accept all of its uncomfortable requirements (Advertising Identifier, permission dialogs to use things like Bluetooth or Contacts if an advertiser wanted it, etc.).
This made me a little uneasy in September, but then November happened, and by late January, I wasn’t comfortable embedding unnecessary closed-source code from a U.S advertising company in my app anymore.
I decided to do whatever it took to drop the Google ads and Fabric crash reports and analytics, which was recently acquired by Google.
No closed-source code will be embedded in Overcast anymore,4 and I won’t use any more third-party analytics services. I’m fairly confident that Apple has my back if a government pressures them to violate their customers’ rights and privacy, but it’s wise to minimize the number of companies that I’m making that assumption about.
Fortunately, the Google ads made relatively little — about 90% of Overcast’s revenue still comes from paid subscriptions, which are doing better now. The presence of ads for non-subscribers is currently more important than the ads themselves, so I can replace them with pretty much anything. So I rolled my own tasteful in-house ads with class-leading privacy, which show in the Now Playing and Add Podcast screens:
Now Playing can show ads for websites, podcasts, apps, or Overcast Premium, while the Add Podcast screen will only ever show ads for podcasts. (Want to buy an ad? Get in touch.)
That’s right, ads for podcasts. What better place to advertise a podcast successfully than in a podcast player? Tap one, and you get the standard Overcast subscription screen with a complete episode list and one-touch subscribing.
I hope I’ve succeeded in my design goals, and I hope you enjoy it.
Don’t worry, edge-swipers: you can also dismiss it by dragging in from the left screen edge, just like the old way, to fit your established muscle memory. ↩︎
Well, almost standard. I made my own so I could improve some of the built-in one’s behaviors and make my own custom little dot icons for Effects and Info. ↩︎
The continuous-play option previously in Playback, labeled “When Episode Ends: Play Next/Stop”, was frequently missed, misunderstood, or invoked accidentally. Many people have asked where the continuous-play option was, and many more asked why their app was suddenly broken and wouldn’t automatically advance between episodes. It’s now just a “Continuous Play” switch in Settings. ↩︎
Unfortunately, this precludes Chromecast support. I’d gladly reconsider if Google documents a way for apps to send audio to Chromecast devices without embedding their closed-source library. ↩︎
One of the issues of yesterday’s GitLab.com “database incident” is that most of their database backups weren’t being tested, and when they needed a restore, they discovered that most of the backup methods hadn’t been working.
Untested backup methods that turn out to be missing or broken are extremely common. I can’t fault them much because it’s a very easy mistake to make: most backups, by nature, never need to be restored from, so you never realize if something changes and they stop working… until it’s too late.
The solution is to frequently and automatically test backups by:
Regularly downloading the latest backup from S3 (or wherever) and performing a full restore onto a clean server.
Testing its validity in a way that a human is sure to notice if it stops working properly.
The first part sounds hard, but isn’t. For Overcast, I run an inexpensive Linode server devoted to automatically fetching, installing, and testing the latest backup every day and emailing me a report.1
The emailed report contains query results from multiple database tables that change regularly and are easy for me to mentally verify as I read it every day, such as the number of users and Premium subscribers, how long ago the latest user signed up, and the most recent episode titles of my own podcasts and other popular shows I listen to.
Automated backup testing isn’t difficult — it’s one simple shell script, called by cron every night, piping its results to mail. If you can run a server, you can do this.
The second part is the trick, though: it’d be too easy to start paying less attention to those daily emails over time, and if they stopped arriving, I may not notice for a while.
My solution is to tie backup tests to a task I do every week: stats collection.
I keep a running spreadsheet with pretty graphs to monitor the health and growth of my business, I update it once a week, and — critically — I pull almost all of the stats I need from the backup emails.
So if the backup ever stops working in a way that the script doesn’t detect or I fail to notice from the daily reports, I’ll still find out pretty quickly, because it’ll impact this other thing I always do that’s a high priority for me and involves important business and money things.
If the script detects any failures itself, it emails me with a very alarming subject line that a Mail.app rule highlights in red and shows an alert for. ↩︎
The quarterly results are in and Apple’s doing fine overall, but the iPad really isn’t, with another year-over-year decrease in sales.
Apple and commentators can keep saying the iPad is “the future of computing,” and it might still be. But we’re starting its seventh year in a few months, and sales peaked three years ago.
What if the iPad isn’t the future of computing?
What if, like so much in technology, it’s mostly just additive, rather than largely replacing PCs and Macs, and furthermore had a cooling-fad effect as initial enthusiasm wore off and customers came to this conclusion?
The moving-average unit sales graph would look something like this, right?
We appreciate the opportunity to work with Consumer Reports over the holidays to understand their battery test results. We learned that when testing battery life on Mac notebooks, Consumer Reports uses a hidden Safari setting for developing web sites which turns off the browser cache. This is not a setting used by customers and does not reflect real-world usage. Their use of this developer setting also triggered an obscure and intermittent bug reloading icons which created inconsistent results in their lab. After we asked Consumer Reports to run the same test using normal user settings, they told us their MacBook Pro systems consistently delivered the expected battery life. We have also fixed the bug uncovered in this test. This is the best pro notebook we’ve ever made, we respect Consumer Reports and we’re glad they decided to revisit their findings on the MacBook Pro.
Apple’s tone and framing here, and in most recent PR statements where they’re on the defensive, rubs me the wrong way.
Consumer Reports has a spotty history with calling Apple out on product flaws. They’re usually written overly sensationally, and they often overstate the importance of minor issues.
But almost every time, the problem they’re reporting is real — especially in retrospect, after everyone’s defensiveness has passed and we’ve lived with the products for a while. It’s just debatable how big of a deal it is in practice.
The iPhone 4 antenna design really was flawed. The iPad 3 really did get uncomfortably warm. And the 2016 MacBook Pro really did have poor, inconsistent battery life in their test.
Apple’s framing here is almost Trumpian, evading responsibility for the real problem — Apple’s bug — by attempting to insult the test (“does not reflect real-world usage”), discredit and imply malice by Consumer Reports (“a hidden setting”), and disregard the bug as irrelevant (“obscure and intermittent bug”).
It reframes the story to be about Consumer Reports’ own failings and Apple helping them see the right way forward.
But disabling the browser cache during a battery test to make results more consistent is reasonable, Apple’s browser offers that feature, and it’s neither very well hidden nor unused by any customers.1
Nothing about a battery-life test truly reflects “real-world usage.” Battery tests are approximations, designed to mimic the most common tasks but in an artificial, automated, repetitive way for hours on end to get reproducible results.
Real-world usage is so varied, with such wildly different software and usage patterns, that nobody’s battery test is relevant to much of anything except relative comparisons of its own results. A test that lasts 5 hours on a 13-inch and 6 hours on a 15-inch tells you that the 15-inch probably has better battery life than the 13-inch, but that’s about it — it certainly doesn’t mean that your 15-inch will get 6 hours the way you use it.
Reloading web pages without a browser cache is no more or less valid than whatever Apple uses to tell me that my laptop will get 10 hours of battery life when my actual workload usually gets about half of that.
The real story here is that Consumer Reports did get very poor and inconsistent results from their battery test, which was a reasonable and valid test, due to a real bug in Apple’s web browser.
With the bug now fixed (in beta, at least), the MacBook Pros deserve a retest, and Consumer Reports is conducting one.
But their previous results were real, and Apple’s bug was to blame.
There are a lot of web developers out there, and I bet a lot of them use MacBook Pros. Power users, geeks, and developers are Apple’s customers, too. ↩︎
It was a cold Tuesday afternoon in New York. My hair was still brown. We were supposed to be working, but even David had to suspend his usual workaholism for a few minutes in awe of what we were seeing.
Everything about the iPhone seemed impossible to the technology world of early 2007.
“You can’t make a good phone without buttons.” “You can’t fit a desktop-class OS on a phone.” “There’s no way that’s a full-blown web browser.” “That has to cost a thousand dollars.”
Yet over the course of an hour, Steve destroyed every rule we thought we knew.
Not only was it truly mind-blowing at the time, but in retrospect, so much of modern computing was invented for the first iPhone and revealed to the world in that hour. Just watch the software demos: most modern UI mechanics and behaviors, large and small, began that day.
When it shipped six months later, it was possibly the best 1.0 in tech history, followed by a decade of relentless hardware and software improvements with the highest success rate and fastest advancement of any product line I’ve ever seen.
I’ve seen a lot of major product launches and technology changes in my life and career so far, but nothing else I’ve seen has ever come close to the surprise, magic, and magnitude of the first iPhone, and I don’t expect it to be surpassed in my lifetime.
This was before Apple events were streamed, so “watching it live” really meant watching liveblog transcripts with occasional photos from people who were there. ↩︎
Hiya creepily requires access to all of my contacts, which I think they transmit to their servers for vaguely specified reasons.
Truecaller creepily requires my name, phone number, and email address to add to their directory, which I think might allow people to find my phone number under vaguely specified conditions.
Nomorobo isn’t creepy about anything, but costs $2/month with an in-app-purchase subscription.
I had Hiya installed for weeks and it never identified a single spam call, during which time I got about ten. I followed all of their voodoo troubleshooting steps, but it just never worked, so I deleted it. (Too bad I can’t un-send them my contacts. Thanks a lot.)
I had Truecaller installed for a few days, and it correctly identified two spam calls with no drama or voodoo required. It just works.
When I learned about Nomorobo from readers and saw how creepy it wasn’t, I deleted Truecaller immediately and subscribed to Nomorobo, and it works great.
A few days ago, after a 100% success rate for a couple of weeks — every spam call (and zero non-spam calls) identified before I answer — I enabled the option to send spam calls directly to voicemail.
Now, from my point of view, I just don’t get spam calls anymore.
We’ve lost something big. We’re all complicit, myself very much included.
We’ve all been pouring a lot more of our writing and attention into Twitter and Facebook than the rest of the web, and the diversity and decentralization of the web has suffered greatly. Far too much power now rests in far too few hands, and we’re starting to suffer tremendous consequences. (Bigly. A disaster.)1
Apathy and inaction lead to further entrenchment and concentration of power. It’s only going to get worse unless we take action.
My 15-inch 2016 MacBook Pro with Touch Bar is pretty good in most ways, but it’s a noticeable regression in battery life from the previous generation. Apple claims it lasts 10 hours, but I’ve never gotten that — in a fairly light web-productivity workload, I average around 5–7 hours, and if I’m using Xcode, I’m lucky to get 4–5 hours. This seems common — many other customers and reviewers have noted similarly disappointing battery life in the 5-hour range.
Apple issued a software update today to address this.
You see, the problem wasn’t that Apple’s brand new, flagship, “pro” laptop’s battery only lasts 5 hours for a lot of its customers’ actual usage. The real problem, according to Apple in a statement to Jim Dalrymple, is the estimated “time remaining” display:
You can still see the image on the top of the screen, and you can see the percentage, but you will no longer be able to see how much time is remaining before your battery dies.
The reason for removing it is very simple: it wasn’t accurate.
Apple said the percentage is accurate, but because of the dynamic ways we use the computer, the time remaining indicator couldn’t accurately keep up with what users were doing. Everything we do on the MacBook affects battery life in different ways and not having an accurate indicator is confusing.
Well, I’ve always found the time-remaining indicator pretty accurate. Just last night, I brought my 100%-charged laptop to the couch to order some nuts and browse the web for a while, and it reported about 5 hours remaining. After just over an hour, the battery was down to 77%, and it estimated that I had about 4 hours remaining.
I found it equally helpful when using Xcode normally at the start of a 5-hour flight, as it told me that I had about 4 hours of battery left. I ran it down to 8% before stopping — with about 30 minutes left in the flight — and it remained accurate the whole time.
Having used Apple laptops for over a decade, I’ve always found the time-remaining estimate to also be a good indicator of how much power I’m burning with my current activities so I can “budget” my battery usage when I’m going to need it.
At the start of a long flight, for instance, I can check the time estimate, and if it only says I have 2 hours left at 90%, I know something’s burning a ton of power and I can go do something about that. A percentage only tells you the current state, not the rate of change — it would take much longer to notice an unexpected power drain from the percentage alone. (Fortunately, I can still check the estimated time remaining with iStat Menus.)
Apparently, that’s all wrong, and my laptop really would’ve lasted for that full flight had I just let it discharge past 8%.
The strongest despair I’ve heard about this election has come from high school and college students. I don’t know if this will really help anyone, and I hope it’s not patronizing. But just in case it helps:
George W. Bush was elected during my freshman year of college. For the next 8 years — all of college, my first job, and the first two years of Tumblr — we suffered through that horrific administration. It was half of my adult life so far.
It felt hopeless. It felt like we’d never have a functional government again. It felt like the damage would be irreparable. It felt like the good side lost and would never win again.
But then, in 2008, the good side won, propelled into victory by Americans’ motivation after those regressive and destructive years, and we had our turn for 8 years. It wasn’t perfect, and Obama didn’t (and couldn’t) fix everything Bush broke. But we did fix most of it, and made a lot of progress in major new areas as well. Overall, we came out way ahead.
And we’ll do it again, because when you average it out over time, progress tends to only go in one direction: people being healthier, better educated, and better to each other. We have ups and downs, and we don’t end every year better than the last, but in the long run, we come out ahead.
Most people in the world are good, and want to be good to each other. Whether they vote that way or not, far more Americans believe in progressive, liberal, inclusive views than regressive, aggressive, conservative ones.
Young people know this better than anyone, because young people are overwhelmingly liberal, even more than older people. That’s not because you’re inexperienced — it’s because you’re right. Your generation is, by definition, further ahead on the march of progress than everyone else. It is literally you who cause the progress as older people die and you rise into power.
This is going to be difficult for everyone — some much more than others. It may seem like it’ll last forever, especially if you weren’t an adult during the Bush years.
But it won’t.
In the meantime, do everything you can to help, support, and stand up for the millions of people whose country just let them down, many of whom live in homes and communities that have just become unwelcoming or unsafe.
We’ll get our chance to repair the damage and move forward again, and you’ll bring us there.
It’s looking increasingly likely that there will never be another Mac Pro. Here’s why that would be a shame.
Pro buyers depend on Apple to make the hardware that satisfies our needs. And we’re flexible. We’ve adapted over the years to new CPU architectures, port changes, capability changes, price increases, and a slower update pace.
The 5K iMac is a truly great computer. It’s the best general-purpose desktop Apple has ever made. It almost replaces the need for the Mac Pro. Many of us can get by with the 5K iMac.
But there are some things that only a Mac Pro can deliver.
More than 4 cores. Per-core performance has been eking out diminishing returns for years, so today’s newest processors aren’t much faster than those from a few years ago. If you need more performance for parallel workloads — very common for video, photography, 3D, science, medicine, and software development — the only way to jump meaningfully ahead of mainstream CPUs is to add more cores.
Today’s Mac Pro-class Xeon CPUs easily pack 8 cores at pro-accessible prices, 10 or 16 for a bit more, and scale all the way up to 22 cores.1 It may take a decade for an iMac to match the speed of today’s 16-core Xeons.2
High-end GPU power. Only the Mac Pro has the space, budget, heat capacity, and PCIe bandwidth to offer high-performance desktop- and professional-grade GPUs. If gamers, game makers, visual effects workers, and OpenCL aren’t enough, the rapidly-emerging VR and AR markets should be — they’re the next wave of high-end pro buyers who need the fastest hardware money can buy, and Apple has nothing to offer them.
The most RAM. The brand-new MacBook Pro maxes out at 16 GB and the iMac maxes out at 32 GB from Apple or 64 GB with aftermarket RAM. The three-year-old Mac Pro can go to 64 GB from Apple, 128 GB aftermarket. Some pro workloads simply need more RAM than the consumer and mobile chips support.
The freedom of thickness and AC power. High-core-count CPUs and powerful GPUs need far more wattage and thermal management than the other Macs will ever have the thickness or battery capacity to accommodate. The Mac Pro doesn’t need to be small, thin, lightweight, or power-constrained — the rest of the lineup fills those roles well, freeing the Mac Pro to be as big as it needs to be.
Silence. Unlike every other Mac except the low-performance 12-inch MacBook, the Mac Pro remains inaudible in most rooms even under sustained heavy workloads — you don’t hear the fan spin up — because its size and clever thermal design allows for a massive heatsink, cooled by a huge, slow fan.
This isn’t only important for pro environments such as recording studios and video sets, but it’s nice for all of its users (and their officemates). The Mac Pro is the only Mac that handles heavy workloads gracefully.
Reliability and longevity. The Mac Pro’s workstation chipsets, Xeon CPUs, and ECC RAM are all designed with more strict tolerances, resilience, and error correction than the mainstream components in every other Mac. And the heavy-duty thermal design keeps components cooler, which prolongs their life and improves stability. Most Macs have long lives before they break or become outdated, but Mac Pros outclass every other model by starting with a huge performance lead, then working hard for years without breaking a sweat.
And by separating the computer from the display, either can be upgraded more freely, promoting customer investment in high-end displays and high-end computers as needs and technologies change.
Taking the burden off of the other Macs. Pros wouldn’t be as angry about the limitations of the new MacBook Pro line if there was an alternative that solved their needs. The Mac Pro sweeps up countless edge cases with one product at the top of the line — the only downside is cost, but many pros would rather spend money than compromise on their needs.
Current sales aren’t an indicator of future sales. Apple shouldn’t use the (presumably) low sales of the current Mac Pro to justify discontinuing the line entirely. The 2013 Mac Pro was introduced with a substantial price increase, far less internal expansion, fewer and more expensive processor options, and a forced dual-workstation-GPU configuration even for buyers who would’ve been fine with a single GPU. Then it was abandoned for three years, during which 5K displays finally came to market, but without a good option for Mac Pro buyers.
The 2013 Mac Pro was a victim of limited configuration options in a market that values versatility and edge-case handling, poor timing behind the 5K transition, and years-long neglect. A 2017 Mac Pro need not suffer from the same issues, and could sell far better.
Any Mac Pro is better than no Mac Pro. The 2013 Mac Pro is a great design, but its size and power constraints are self-imposed. Mac Pro buyers care little about form. If future Mac Xeon workstations must change their form to be practical or palatable to Apple — for instance, by becoming more of an “iMac Pro” with a built-in 5K screen but a large, thick thermal enclosure on the back — that would be less ideal, but we’d take that over the lack of any high-end workstation Macs. (The existing iMac is great, but it isn’t enough.)
Nobody else can make macOS hardware. If Apple doesn’t address someone’s hardware needs, there’s no alternative.3 We can’t just buy hideous Xeon workstations from Dell and install macOS on them. If we can’t do what we need on Mac hardware, our only choice is to leave the entire Mac platform.
But the competition isn’t even close.
Linux can solve some pro needs, but not most. It’s a fantastic server OS but a miserable desktop one, and that will probably never change.
Microsoft is boldly experimenting with PC hardware, but Windows and everything around Windows is woefully inferior to macOS and the Mac software ecosystem. Even if Microsoft did everything right, it would take Windows at least a decade to catch up — and they won’t do everything right.
Google’s trying something, I’m sure, but Google is both terrible at consumer software and deeply, profoundly creepy. General-purpose computing must not require us to compromise our privacy and data for advertising.
And just as nobody’s starting new general web search engines or mass-market online auction sites today, nobody else is going to make a viable general-purpose PC OS anymore. The minimum bar is too high. We’re stuck with the few we have for the long haul.
But if the one you’re stuck with is macOS, that’s a great thing.
We don’t want to leave the Mac. We came here, built here, and stayed here all of this time because Macs are truly awesome computers, and macOS is the best operating system in the world.
It’s the only pro-grade, workstation-class operating system that has ever been easy to use and nice enough that we wanted to spend more time at our workstations.
And hidden behind our pro apps and terminal windows are the shared photo streams we made last night, showing pictures of our children to their grandparents, who are running the exact same operating system.
Technology changes, markets change, and people change, but some moments in history are uniquely high points that are never quite matched.
The world has never seen anything like macOS, and nothing will truly replace it. If we’re forced to move to something else, it’ll be painfully, inescapably, perpetually worse.
Keep the Mac Pro alive, Apple, so none of us have to make that choice.
The rest of the lineup is great for almost everyone. Almost. But please don’t abandon those of us who truly want or need the best computers in the world, because if they’re not Macs, they’re not good enough.
That’s just with a single socket. If the Mac Pro offered dual-socket options like it did before the 2013 redesign, even higher-performance options open up, limited only by power consumption, heat, and money. ↩︎
And this is today, before Skylake’s improvements have come to the Xeon line. Next year’s Skylake-E Xeons and Purley platform are a major upgrade that will put them even further ahead of the consumer line. ↩︎
It’s hard to get anyone to agree on what constitutes “pro” use, but I’d say it has three core requirements:
Reliability: Pro gear absolutely must be dependable, even when used heavily or in demanding conditions.
Power: Pro apps usually need more of every hardware resource than consumer apps — at least CPU power and memory, and often GPU power or I/O bandwidth — and pros will often pay high costs for high-spec machines that won’t hold them back or leave them waiting.
Versatility: Pro gear is used in diverse environments, often with unpredictable needs. Many pros never know when they may suddenly need an obscure port or feature, or when they will unexpectedly need to keep working on battery for a few more hours, and the consequences of not handling these conditions could be expensive or very inconvenient.
The new MacBook Pro is probably great, and most of the initial skepticism probably won’t age well. But I want to pick on one aspect today.
Having four USB-C ports is awesome.
Having only four USB-C ports is going to hurt the versatility requirement of pro gear, because there’s a very real chance that you won’t have the right dongle when you need it.
This is going to happen a lot, because even though USB-C is the future, it’s definitely not the present. We’ve had the standard USB plug (USB-A) in widespread use for 18 years, and it’s going to take a few more years for USB-C to become so ubiquitous that we can get away without USB-A ports most of the time.
A pro laptop released today should definitely have USB-C ports — mostly USB-C ports, even — but it should also have at least one USB-A port.1
Including a port that’s still in extremely widespread use isn’t an admission of failure or holding onto the past — it’s making a pragmatic tradeoff for customers’ real-world needs. I worry when Apple falls on the wrong side of decisions like that, because it’s putting form (and profitability) over function.
Design for the future, but accommodate the reality of the present.
I’d also argue that removing the SD-card reader was premature. SD cards are ubiquitous on cameras (even recent high-end models), and card readers are by far the fastest and most versatile way to import a lot of photos from of a camera. A lot of other pro A/V gear uses SD cards as well, such as most audio and video recorders. Standalone card readers work well, but they’re yet one more dongle that you won’t always have with you. ↩︎
Y Combinator has apparently decided not to. President Sam Altman defended this position in a blog post, framed as a Clinton endorsement, that begins with a partial overview of how reprehensible and dangerous Trump is, but ends with a defense of continuing Thiel’s involvement in Y Combinator that’s effectively framed as a free-speech or tolerance issue:
Some have said that YC should terminate its relationship with Peter over this. But as repugnant as Trump is to many of us, we are not going to fire someone over his or her support of a political candidate. […]
The way we got into a situation with Trump as a major party nominee in the first place was by not talking to people who are very different than we are. […]
That kind of diversity is painful and unpopular, but it is critical to health of a democratic and pluralistic society. We shouldn’t start purging people for supporting the wrong political candidate. That’s not how things are done in this country.
Altman’s framing of Thiel’s Trump support as a diversity issue isn’t just incorrect — it’s a harmful distortion that reveals a deep misunderstanding of the tech industry’s actual diversity issues. (I don’t and can’t fully understand our diversity problem, but I at least won’t pretend to.)
To help illustrate why, here are some of Altman’s own words from the first half of that same post:
This election is exceptional. Donald Trump represents an unprecedented threat to America…
He represents a real threat to the safety of women, minorities, and immigrants…
Trump shows little respect for the Constitution, the Republic, or for human decency…
I do not understand how one continues to support someone who brags about sexual assault, calls for a total and complete shutdown of Muslims entering the US, or any number or other disqualifying statements.
Wrapping reprehensible statements or actions as “political beliefs” doesn’t protect them or exempt their supporters from consequences. Racism is racism. Sexual assault is sexual assault. Labeling reprehensible positions as “political beliefs” is a cowardly, meaningless shield.
But even if such protection existed (it still doesn’t), this isn’t calling for someone to lose their job because they merely voted Republican — the scale of Thiel’s support and the conditions of this particular candidate matter.
Thiel, a non-employee (a “part-time partner”), is directly supporting Donald Trump at a massive scale — over a million dollars! — after we’ve learned even more of Trump’s horrendous statements, positions, and past actions than we could’ve ever imagined.
This isn’t voting for an economic or social policy — this is literally paying a huge amount of money to directly support a racist, sexist bigot with rapidly mounting allegations of multiple sexual assaults.
One more quote from Altman:
If Peter said some of the things Trump says himself, he would no longer be part of Y Combinator.
Funding Trump, especially at this scale, represents general support of what Trump has said and done. If saying what Trump said would be enough to override Altman’s “diversity” argument and sever ties with Thiel, giving over a million dollars to Trump’s campaign should qualify as well.
Y Combinator should be especially sensitive to diversity and inclusion issues due to its public presence and large influence in the technology business. We have so many diversity and hostility problems (that the industry is finally working to fix) that Y Combinator should be leading the way toward inclusive, progressive solutions.
Instead, they’re defending the large-scale support of racism, bigotry, and sexual assault by an influential partner and advisor to their startups as its own form of “diversity”.
Last week, Apple terminated the developer account of one of my favorite Mac apps, the Dash documentation viewer for programmers, for alleged App Store review manipulation.
Dash is a great app that many Mac and iOS programmers use (and that needs no help getting positive reviews), and developer Bogdan Popescu insisted he’d never engaged in such fraud. Since Apple has a history of controversial App Store decisions that often get reversed after public scrutiny, many developers (including me) came to his defense last week, assuming that someone at Apple had made a mistake, and yelled on Twitter for Apple to reconsider or provide more concrete justification. Michael Tsai has a good overview with more links.
Almost 1,000 fraudulent reviews were detected across two accounts and 25 apps for this developer so we removed their apps and accounts from the App Store. Warning was given in advance of the termination and attempts were made to resolve the issue with the developer but they were unsuccessful. We will terminate developer accounts for ratings and review fraud, including actions designed to hurt other developers. This is a responsibility that we take very seriously, on behalf of all of our customers and developers.
This isn’t enough proof for some, but it’s enough for me. (Some quicksearches support Apple’s position, if you’re still unconvinced.)
Like any controversial decision involving people’s livelihoods, Apple probably needs to be careful to avoid potential legal issues, and it would be in poor taste for a huge company to sling more mud than necessary in public against a tiny opponent.
I’m glad our community assumed the best of another developer and pressured Apple to justify this severe action. We should now accept that they have.
The public often doesn’t get the full story behind decisions and changes they see, but it’s usually not for sinister reasons — it’s often just someone taking the high road and letting another party save face.
Bogdan Popescu responded with his side of the story and a recording of a phone call from Apple (without their consent, which is illegal in California, but apparently not in Romania). In summary, he bought another developer account for a relative with his credit card and using his old test devices, which made Apple’s fraud team consider them the same entity (seems reasonable), and that account engaged in the fraud.
His post makes Apple sound pretty bad. But if you listen to the call (which I was torn about whether to do), it’s clear that Apple was being incredibly reasonable and going above and beyond to help him get reinstated and clarify what happened in a public statement, but Popescu didn’t seem to agree with Apple regarding the wording of key facts.
We don’t know what happened between that call and Apple’s statements tonight. I’m guessing Popescu and Apple couldn’t reach an agreement over the wording of the public story, but I think what Apple asked for in that phone call was extremely reasonable.
It’s also notable that Apple investigated this and tried to resolve it as well as they did. If it were any other company — say, Google for a suspended AdSense or YouTube account — I suspect the amount of effort devoted to it would be much lower.
Year one: Free up front, but with many limits and missing features unless you bought the $4.99 (one-time) in-app purchase to unlock them.
This brought in good money up front, but income slowly declined, as all paid-once purchases do, and it restricted the app’s best and most compelling features to the very small percentage of people who paid. Everyone else got a sub-par app.
Year two: Free for all features that were previously locked behind the purchase, with an optional $1/month patronage, to deliver the best app to the most people and hopefully change the direction of the downward revenue curve by replacing one-time purchases with recurring income.
This simply hasn’t brought in enough money, which I’ll get into below.
Starting today, I’m trying a third:
Year three: Free for almost everything, with simple ads on some screens, and everyone now gets the dark theme. Patronage is now Overcast Premium, now just $9.99 per year, for ad-free use, file uploads, and some future features.
Existing patrons become Premium accounts of the same duration, with all Premium benefits. At the end of your patronage, you’ll be asked to renew as Premium.
Buyers of the old $4.99 unlock from year one: Restore Purchases from the Premium screen, and you won’t see the normal ads, but you may see occasional promos for Premium to support further development.
How patronage performed
Patronage was a big risk, both in finance and reputation. I took a lot of heat for it, and it initially made much less money than the previous model. But I knew that if I could convince 5—10% of the userbase to pay, I’d come out ahead.
Here’s how that went:
Patronage initially brought no new exclusive features, based solely on goodwill, which only convinced about 1.9% of people to pay. This wouldn’t be sustainable, so I had to add perks to patronage that some people would want enough to pay for. But to prevent the year-one problem of most people using an inferior or annoying app by not paying, the absence of the patron-only features needed to be inconsequential or unnecessary for typical usage.
In March, I added the two new features only for patrons: a niche file-upload feature that required ongoing hosting costs, and a dark theme that was highly demanded but purely cosmetic.
It worked fantastically at first. The patronage rate jumped from 1.9% to 2.6% in one week, and slowly rose to just under 3%. But growth has stalled there, and it’s clear that I’m not going to reach my 5–10% goal.
And keeping the dark theme behind a subscription has been extremely unpopular, even among those generous enough to pay. People really don’t want to pay a monthly fee for what seems like a basic app feature, even if it’s purely cosmetic, and many patrons have been getting very angry when they stop paying and the dark theme goes away.
Faced with these problems, I came up with a few solutions, all of which were terrible:
No change: The status quo brings in enough money to keep the service running and fund basic maintenance and occasional updates, but I want to do more: more frequent updates, more cool features, more server capacity, more users, and higher quality.
Lock existing free features behind patronage: This would anger pretty much everyone, and once it settled down, I’d be stuck with the same problem as year one: most users never get the best parts of the app.
Add new patron-only features: If any new patron-only features are widely demanded, I’ll be stuck with the year-one problem again. If not, they won’t bring in enough money. The latter is more likely: what most people want (and will pay for) is pretty well covered by Overcast’s current features.
Change to pure subscription pricing for the entire app: This may work for other types of apps, but probably not general consumer entertainment apps in highly competitive environments full of free alternatives, one of which comes installed on the phone. This would severely harm Overcast’s ability to get new users, hurting my political goal of protecting the awesome, open, decentralized world of podcasting with app diversity.
Change to a paid-up-front app, or year one’s one-time unlock: A smooth transition from the status quo to this would be impossible, and I’ve been down this road enough times to know that pay-once revenue curves only go downward. The App Store never made this easy, and the market is only getting more challenging over time.
It felt hopeless, but my initial thinking was restricted by trying to wedge traditional software business models into the realities of today’s App Store. It’s hard to make older revenue models work today because the market is completely different.
Charging money only works in scarcity, but most kinds of software are no longer scarce, especially on iPhone. Whatever I charge money for, someone else can give away, and vice versa. For instance, most of my competitors now offer a dark theme at no additional charge, but if I give mine away without any other changes, I’ll go out of business.
There’s still money in some software, especially if it helps people get their work done, but the market for most consumer apps is much more like music, video, news, opinion, and web services than traditional indie software: an overwhelming supply of free choices, many of which are great or good enough, making it hard for anyone with a paywall to succeed.
The content industries figured out the solution a long time ago. If 97% of my users can’t or would rather not pay, but they spend substantial time in the app every day, the solution is probably ads.
Ads are the great compromise: money needs to come from somewhere, and the vast majority of people choose free-with-ads over direct payment. Ads need not be a bad thing: when implemented respectfully, all parties can get what they want.
Most podcasts played in Overcast are funded by ads for this reason, and as a podcaster and (occasional) blogger myself, I already make most of my income from ads.
So I’m trying ads in Overcast: simple, non-animated, mostly-text banners on the main list screens that unobtrusively scroll with the content.
In exchange for ads, I’m giving everyone dark mode for free. If you’d rather not see ads, a Premium subscription (or restoring the old 1.0 unlock if you bought it) will hide them.
In today’s app environment, for a daily-use consumer app like this, ads make a lot of sense for both users and developers. Ads align incentives toward making a high-quality app that you’ll actually want to use long-term, rather than just struggling to get your money up front or toying with psychology so you’ll buy more gems.
A lot of indie developers struggle to make sustainable income in the App Store. I’ve experimented with many models over the years, and I’ll be happy to share the results of this change to hopefully be useful to other developers.
I honestly don’t know if this will work long-term, but I think it probably will. If it does, it will solve a lot of problems and let me do quite a bit more, better and faster than before, and truly make the best app for everyone, rather than only 3% of my customers.
Filed as Apple bug (Radar) 27848317. The problem, in short:
AVFoundation, the low-level audio/video framework in iOS and macOS, does not accurately seek within VBR MP3s, making VBR impractical to use for long files such as podcasts. Jumping to a timestamp in an hour-long VBR podcast can result in an error of over a minute, without the listener even knowing because the displayed timecode shows the expected time.
VBR encoding is far more space-efficient and better-sounding than constant-bitrate (CBR) encoding. It’s especially pronounced in podcasts, where VBR makes most podcasts 20–50% smaller AND better-sounding than the 64 kbps CBR encoding that most podcasters are forced to use today.
VBR could save podcast listeners massive amounts of data transfer over time. (And therefore money, and battery life, and precious storage space on phones.)
Without accurate seeking, streaming and web audio players don’t work properly, including share-at-timestamp links that are becoming key drivers of the sharing and spreading of podcasts.
Why can’t podcasters use it?
I explained how MP3s work, and why this is a problem, on Accidental Tech Podcast last week — see that? That’s a share-at-timestamp link, and if that file was VBR, it wouldn’t seek to the correct time.
See for yourself: here’s that same podcast in VBR. Note that the file is 25% smaller and the theme song (at 1:22:47 in the original file) sounds way nicer in the VBR version. But if you seek to the same timestamp as the above share link — 1:24:30 — you’ll hear the wrong audio. The player will say 1:24:30, but you’re actually hearing the audio at 1:25:16.
That’s 46 seconds off, and that’s enough to break timestamp sharing, and that’s enough to ensure that nobody ever uses VBR files, and podcasts keep transferring more bytes to sound worse for the foreseeable future.
We fixed this in the same year the Backstreet Boys released “I Want It That Way”
Three simple solutions to accurate VBR stream-seeking have existed for almost twenty years to embed seek-offset tables at the start of VBR MP3s for precise seeking:
But AVFoundation supports none of them. VBRI and legacy Xing frames are read, but only the duration is used from each, not the seek table. MLLT tags are seemingly ignored.
It appears that AVFoundation simply estimates byte offsets with the simple ratio of (timestamp / duration) × totalBytes, but that assumes a constant average bitrate over the file, which is incorrect and an unsafe assumption for VBR encoding. (ABR maintains an average bitrate over the whole file, but doesn’t achieve a better enough size-to-quality ratio than CBR for most podcasts.)
Supporting either MLLT or VBRI at the AVFoundation level (therefore affecting Safari, HTML5 <audio>, Apple’s Podcasts app, and more) would instantly make VBR podcasts practical, allowing much smaller files and better sound without sacrificing shareability and stream-seeking.
I’ll be adding MLLT support to Overcast, but without a way to embed podcasts in the web player to preserve share-at-timestamp links, VBR files will continue to be practically unusable for podcasters.
Know anyone in engineering at Apple? I’d appreciate any attention you can draw to this issue, which I’ve filed as bug 27848317.
This week: why ARM Macs aren’t imminent, a huge rant on the ancient Mac lineup (especially the neglect of the Mac Pro and Mac Mini), dog rental, and my algorithm for syncing audio tracks and correcting drift.
Government guidelines for LED manufacturers require these control circuits to operate on frequencies between 30 and 300 MHz. By coincidence, most garage door opener remotes have been assigned frequencies between 288 and 360 MHz.
I was using a mediocre, no-name LED light bulb in my (very old) garage-door opener, so I switched it to an incandescent I had stashed in my Drawer Of Light, which promptly and poetically burned out later that same day.1
But that was weeks ago, and the problem hasn’t occurred since. It’s been 100% reliable since I removed the LED bulb, and even catches the signal from greater distance now.
I still haven’t gotten around to replacing it. It turned out not to be essential, and I’m a terrible home-repair slacker, which is why I tried to put LED bulbs everywhere in the first place so half of our light bulbs wouldn’t be burned out constantly. ↩︎