I believe it was during a Mitchell Baker keynote at OSCON many years ago that she showed survey results that 85% of those surveyed could not distinguish between the web and their browser.

What that meant for Mozilla was that if my web site was slow to load, a good percentage of Mozilla users would blame their browser and not my site.

Today we look at this powerful computer that fits in our pocket and forget how constrained the early iPhone was.

Apple made a brilliant and critical decision for the success of their phone. If my app took too long to load, the Springboard would kill it. Apple wanted people to know that it was my apps fault. They didn't want people to think that the iPhone was slow.

Fair enough. It was my apps fault. And once a device or a language has been branded as slow, it is very difficult to change people's minds.

But what about the cases where it isn't my fault - where it's Apple's fault?

Maybe fault is the wrong term. I'll give you two quick examples.

Yesterday one of my readers wrote to complain that my books no longer highlight the code you need to add or modify in the current step.

Wait - I thought - I know that works. I test my books with a light background and dark background in Books on the Mac, iPhone, and iPad before I ship them.

I present the existing code in a shade of blue and the changing code in a shade of red - and I've chosen the shades so that people who have trouble distinguishing colors can tell the difference.

I opened the book he was talking about on Big Sur and it looked perfect.

Then he followed with a note that he was viewing it on Monterey.

I took out my Mac that runs Monterey and the code looked perfect with a light background. When I switched to a dark background all of the code was rendered in white. As he had reported "my books" no longer highlight the code you need to add or modify.

We're back to Baker's example where people can't distinguish between problems with the book and problems with the reader.

My books do work perfectly on Big Sur and iOS 14 and they don't work with a dark background in iOS 15 and Monterey.

Apple broke this experience for my readers and yet I now have to figure a way to make it work for them.

Example two.

At this year's developer conference, Apple announced a new MusicKit API.

I've had an idea for a music app for years. It's a way of creating lists of music that get rotated like the old top forty radio stations. Some songs will come up every two hours and others will come up less often - but the music will rotate to keep the sound fresh.

It's a novelty app - I don't know if anyone will want it.

If you don't have a music subscription, the app will create sample hours and you can preview what they will sound like.

If you do have a subscription, you can just hit play on one of the stations and it will play your music.

OK - so here's the rub.

At the event the other day Zane said, "today, we're excited to also introduce a brand-new subscription plan for Apple Music, the Voice plan."

That couldn't be plainer. The Voice plan is a new subscription plan.

But if you have a Voice plan and my app checks to see if you have a subscription to Apple Music, the answer is "false".

To the customer, the Voice plan is an Apple Music subscription and here my app is telling them, "sorry, you don't have a subscription to Apple Music."

How do people distinguish between problems with how Apple classifies their subscription and problems with my app?

I really feel for my customers. They just want to see my books the way they are meant to be. They just want to hear the music that they think they are paying for.

They don't - and they shouldn't - understand the nuances of what is preventing them from doing so.

I just have to find a way of making things work, when Apple breaks my stuff.