Steve Jobs gave the world some of the most beloved products in computing history. He also left the web with a walled garden that, decades later, developers are still paying for. This post is the story of one very small symptom of that legacy - and why fixing it meant writing code around a single company's decisions.
Every device, except Apple's
Most web apps have a "works everywhere" dream. It usually goes like this: build once, ship once, and let every browser - Chrome, Firefox, Edge, Opera, Android's stock browser - render your work faithfully. MockupTown achieved that dream, and it mostly held true. Windows, Linux, Android, macOS: the same code, the same pixels, the same result.
Then we ran into a wall that had one logo on it.
We recently upgraded MockupTown's export system to a modern, robust DOM-capture library - the kind of battle-tested engine used by design tools and screenshot services across the industry. We tested it across browsers and operating systems. It worked beautifully.
On a few devices, though, it didn't. The export produced files that were missing their images - layouts intact, photographs and avatars blank. Not corrupted. Just... absent.
Every single one of those devices was made by Apple.
Why "Chrome on iOS" doesn't help
Here's the part that makes it such a trap. The problem isn't that someone was using a weird niche browser. The problem is that every browser on iOS is Safari.
Since the App Store's early days, Apple has mandated that all browsers on iOS use the WebKit engine. Chrome for iPhone is a WebKit browser with a Google paint job. So is Firefox. So is Brave, and Edge, and DuckDuckGo. When Google ships a fast new rendering feature to desktop Chrome, iPhone Chrome gets whatever WebKit decides to implement - because it is WebKit.
So an app that "works in Chrome" breaks on iPhones - and it breaks in all iPhones, in the same way, forever, until Apple's engine team gets around to it. There is no competing engine you can target. There is no alternative browser your users can install to escape it. There is only WebKit - and WebKit has its own rules, ones that no other browser on earth shares. Which is exactly what our exports ran into.
Steve Jobs' legacy, measured in workarounds
This is where the critique of Jobs and Apple belongs. Not the products - the products are, by and large, excellent. The critique is of the philosophy: the insistence that one company's vision must preside over every experience, including parts of the web it doesn't own.
Jobs built a culture of total control - the App Store's lock, the hardware-software integration, the refusal to let anyone else touch the experience. That control produced beautiful devices and, inescapably, a browser platform that answers to Apple's priorities rather than the web's.
The costs are distributed unevenly:
- Developers absorb them first. Every PWA that can't send a notification, every file input that behaves differently, every canvas that drops images, every
<input type="datetime-local">that isn't supported - these are hours stolen from building actual features. - Users absorb them second. They get a web that works less well on their expensive device than on a $150 Android, and they blame the website, not the vendor.
- The web itself absorbs them last. Standards only become standard if engines implement them. A platform where one vendor controls the only engine gets to slow-walk the shared public infrastructure forever.
Nobody at Apple sets out to break the web. But nobody needs to. When one company owns the whole ladder, the stories of the people below are just noise.
It's not malice. It's worse - it's control.
To be fair: WebKit isn't hostile. Its team has shipped real improvements over the years, and Safari on modern iOS handles far more than it used to. Nobody should pretend otherwise.
The problem is structural, not personal. On iOS, there is no escape hatch:
- One engine. No Chromium, no Gecko, no niche competitors to pressure it.
- One store. No sideloading to run a different browsing experience.
- One opinion. No user choice, no developer recourse, no "just install Firefox".
Apple's innovation was real. But so is its razor: the company profits most when the web looks least like a capable platform - because then native still needs the app store. Every PWA you can't install, every notification you can't receive, every export that drops its images does double duty: it improves the experience for nobody, and it quietly feeds the message that "an app would be better."
That's the part worth criticizing. Not excellence. Not execution. The mercenary use of the platform to define what's possible.
Where we landed
For our part, the fix worked precisely because we refused to accept "Apple devices don't export images" as reality. The updated export system - the same robust library we shipped to production - now produces correct PNGs everywhere, including on every iPhone and iPad that reaches the site. You should see the difference; it's why the mockup generators export the way they should.
The takeaways are simple:
- A robust, modern library is worth it - it caught attention to details most tools never reach, and it works everywhere a standards-compliant engine exists.
- On Apple's platform, you still plan for quirks. Budget for them. They're not bugs you can file away; they're a permanent product feature.
- If your web app "works everywhere except iPhone," you are not alone. You are not wrong. The platform is wrong, and the remedy is usually yet another Apple-specific workaround and a deep breath.
Jobs said "thought different." A web that silently works the same everywhere, including on the company's own devices, would have been a far greater contribution than another walled garden.
Frequently asked questions
Why do Chrome and Safari behave the same on iPhone?
Because they're the same engine. Every browser on iOS must use WebKit, so "Chrome on iOS" is Safari wearing a Chrome logo. Rendering quirks affect every browser on the device identically.
Why did the exports lose images only on Apple devices?
Because Apple's browser engine plays by its own rules on iOS. The exact same code that produces perfect exports on every other browser quietly drops the images on iPhone and iPad, no update available. So we built around it - the way every web developer working for an Apple audience eventually has to.
Is this an Apple bug?
It's a platform behavior. Whether you call it a bug or a deliberate policy, the result is the same: developers must write Apple-specific workarounds that no other platform needs.
Will the exports work on my iPhone now?
Yes. After we shipped the fix, exports include images on iOS in Safari and every WebKit-based browser, matching the behavior on Chrome, Firefox, Edge, and Android.
Isn't this post just an excuse for a rant?
Partly. But the rant is earned the same way a compliance team earns its budget: device by device, feature by feature, year by year.