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. ↩︎
Apple has, for a while now, offered two separate additional security measures to protect your Macs, iOS devices, and iCloud account, but thanks to some inexpert nomenclature, it can be a little difficult to tell them apart
I’m glad Dan Moren figured this out and wrote it up, because Apple sure didn’t make it easy to even know that there was a newer, better option than the original two-… uh, factor? Step? I already forgot which is the old one and which is the new one. Whichever it is, switch to the new one.
A few Tesla vehicles have had accidents with Autopilot enabled recently, and I’ve gotten countless questions about these incidents and the nature of Autopilot from people who aren’t Tesla owners. Tesla and the media haven’t clearly communicated what these features do (and don’t do) to the public, so I’ll try to help in whatever small way I can as a Model S owner for a few months so far.
I apologize in advance if I get any technical details wrong about these features. Authoritative information is hard to find, and these features change and evolve often.
Tesla’s autonomous features today, all somewhat grouped under or involved in “Autopilot”:
Automatic emergency braking: This always-on feature will sense if you’re approaching another car or obstacle too quickly and loudly alert you. If you don’t apply the brakes yourself, the car will automatically brake to somedegree. This is a common feature in luxury cars today and seems to be a clear safety win.
Autopark: Reverses into parking spots on demand. This is also becoming a common feature on other cars, and seems reasonably safe as long as you watch out for pedestrians. I use it regularly for parallel parking and it works well.
Summon:This feature lets you command the car, from outside of it, to very slowly drive itself into or out of a garage or parking space. It’s disabled by default and requires multiple steps to enable and engage (nobody could do this accidentally). The potential damage from failures is likely limited to car body or garage damage, not major bodily harm, due to the very slow movement and ultrasonic parking sensors. I haven’t used it yet — I don’t think the small benefit is worth the risk.
Adaptive cruise control: Like normal cruise control, but with a forward radar (augmented by the camera) to maintain a safe distance from the car ahead of you, automatically slowing down or even stopping as necessary. It’s almost like automated driving, but you still steer, and you’re responsible for obeying signs and signals. This feature is also available on many luxury cars today, and Tesla’s is the best one I’ve used yet, so I use it all the time. It bears most of the same risks as any cruise control, but the chances of rear-ending the car ahead of you are greatly reduced, and it may even be safer than manual driving in low-speed stop-and-go traffic. I’m a huge fan of this feature.
Autosteer, which people probably mean by “Autopilot”: Really just one significant addition to adaptive cruise control: the car also steers itself, using the camera to detect lane markings painted on roads (a feature offered by many other cars on its own) and automatically steer to keep you roughly centered in the lane.
Autosteer is a strange feeling in practice. It literally turns the steering wheel for you, but if you take your hands off for more than a few minutes, it slows down and yells at you until you put your hands back on the wheel. It’s an odd sensation: You’ve given up control of the vehicle, but you can’t stop mimicking control, and while your attention is barely needed, you can’t safely stop paying attention.
It’s automated enough that people will stop paying attention, but it’s not good enough that they can. You could say the same about cruise control, but cruise control feels like an acceptable balance to me, whereas Autosteer feels like it’s just over the line. History will probably prove me wrong on that, but it feels a bit wrong today.
Tesla, Elon Musk, and a lot of media coverage have set expectations too high for these features. People expect Autosteer to be fully autonomous, but today’s Tesla vehicles simply don’t have the hardware or software to safely and reliably self-drive on all roads, and such an advance doesn’t feel imminent.
There’s a huge gap between Autosteer and what most people expect from a “self-driving car”. For instance, Autosteer doesn’t see signs or traffic signals, so it will happily drive through red lights or stop signs if you let it.
Most critically, Autosteer has simply not been reliable enough yet for me on anything but wide-laned, gently turning, intersection-free highways with clearly painted lines in dry weather. In my experience, using it on any other type of road — even New York’s highway-like parkways — is dangerous and unsettling, often requiring manual corrections to avoid crossing center lines or getting dangerously close to lane edges and concrete barriers.
The most reliable, useful, and defensible parts of Tesla’s “Autopilot” features today are emergency braking, Autopark, and adaptive cruise control. I’d be just as happy with my Model S if it only had those, without Summon or Autosteer.
While I like using Autosteer on long highway trips, frankly, I’m amazed that it’s legal. I don’t think it’s a big enough advance over adaptive cruise control to be worth the risks in its current implementation. I’m scared for what will happen to Tesla and the progress of autonomous driving as more people use Autosteer in situations it’s not good at, or as a complete replacement for paying attention.
If Tesla updates the software to restrict Autosteer only to interstate highways, the yelling (and possible lawsuits) from existing owners would cause short-term pain, but I think it may save a lot of reputation damage — and possibly even people’s lives — in the long run.
The San Francisco Chronicle, in a very rare front-page editorial:
On one point we must all agree: The level and pervasiveness of homelessness in San Francisco is a disgrace. It is simply not acceptable to allow people to stay in the squalor of tent encampments or sleep in doorways, parks and freeway underpasses without attention to the underlying issues that prevent them from attaining shelter and stability in their lives. It’s bad for public safety, bad for public health, and bad as a matter of basic humanity.
Its reduction to the extent humanly possible should be this city’s No. 1 priority.
I only spend one week a year in San Francisco, and I’ve seen relatively little of the city. But every year, I’m increasingly struck by the widening class divide and disturbing contrast I see as tech workers (including myself) briskly walk past a lot of people for whom society has completely failed, pretending not to notice them, on our way to offices and events of some of the richest companies in the world.
We can’t continue boasting our industry’s “innovation” and how much we’re “changing the world” when we can’t even take care of people’s basic needs literally right outside these companies’ front doors.
This isn’t just a San Francisco or tech-industry problem, but there isn’t another place in America that illustrates the problem quite as clearly, sadly, and disturbingly.
Governments should be fixing this problem, but they have mostly failed due to public ignorance, judgment, and apathy. If you really want to be “disruptive” and have a meaningful impact on the world, disrupt the way our cities and citizens treat those less fortunate than the rich young people ordering overpriced burritos from their phones to avoid going outside.
This fall’s new iPhone is strongly rumored to have nearly the same physical design as the iPhone 6 and 6S, but with the headphone jack removed. Many have guessed the possible justifications for such a move:
In short: There may be a great reason why the headphone jack must be removed on an iPhone that isn’t getting a noteworthy size change or battery-life increase, but we haven’t heard one yet.
There are clear benefits to Apple — minor savings in parts and internal complexity, some profit from adapters and Lightning licensing, and driving a big Beats upgrade cycle — but nobody has come up with any compelling benefits for customers that require removing the headphone jack and can’t already be done in today’s iPhones.
People already think Apple changes ports capriciously and slows down their phone with OS updates just to force upgrades and make more money, even when they actually have good reasons that benefit their products and customers. I suspect that the reaction to removing the headphone jack will be even more severe in this way than the Dock-to-Lightning transition.
Apple better have very good benefits for this that customers will want, but none of the reports so far indicate any.
Combined with the disappointment sure to result from the same physical iPhone design for three years in a row — a mediocre one, at that — I fear for the public perception of this fall’s iPhone and Apple as a result.
It’s too late to change anything about this year’s iPhone hardware, but if this is true, I hope Apple at least reduces the perception damage by including a Lightning-to-3.5mm adapter in the box along with the new Lightning EarPods, and also selling the adapter separately for just $9.99. That would go a long way toward alleviating the problem.