Issue 738

9^th January 2026

Written by Dave Verwer

Comment

It happened while I was away on my end-of-year break, but at the end of last year Apple announced changes to iOS in Japan. Alternate app marketplaces, external payments, alternate browser engines, and more are all now allowed.

iOS 26.2 enabled the changes, and now there are several regions of the world where users could be using browsers with non-WebKit rendering engines. If they existed, which they don’t.

Mozilla expressed disappointment with the changes two years ago when the rules changed for the EU, and as far as I am aware, is not working seriously on an iOS port of Gecko. It appears that work to port Blink is underway, but it’s a “large and laborious project” and I could find no recent news of progress since that video in late 2024.

I was heartbroken when Google forked WebKit way back in 2013. At the time it felt like we had a chance for HTML rendering engines to converge into one standard implementation (apologies to Gecko 😬), which promised to be a win for the web. Note, I’m not talking about browsers, strictly about rendering engines. I know some people will disagree, but I’d argue we shouldn’t need more than one underlying rendering engine for such a complex set of technologies, as long as it is open source and managed well by all the large browser vendors. At the time, I hoped that WebKit could be that.

Apple’s original rules of only allowing WebKit-based rendering forced what I wished for on mobile platforms, but unfortunately it meant that mobile and desktop just had different dominant engines.

My hope for a single, well-governed rendering engine effectively died when Google forked WebKit. I was probably naive to think it could have worked, but once Blink existed, convergence became impossible.

I don’t think we’ll ever get either Google or Mozilla fully backing an iOS port of their rendering engine until it’s possible for it to be used worldwide and not just in a couple of regions. Will that ever happen? I won’t speculate on that, but I don’t think it’s out of the question.

Would that be a good thing if it happens? I think it would, given where we are now, even if it would truly be the end of my hope for a single standard.

– Dave Verwer

Sponsored Link

RevenueCat Paywalls just added a steady stream of new features: more templates, deeper customization, better previews, and new promo tools. Check the Paywalls changelog and keep improving your subscription flows as new capabilities ship.

News

I noticed something interesting when checking out TelemetryDeck’s latest chart on iOS 26 adoption. Yes, ~55% adoption by January is good, but compare it to the left-hand side of that chart. One year ago, iOS 18 was at ~78%. That’s quite a marked difference. That said, it’s still very safe to assume you can comfortably deploy to “current version and previous version” without cutting anything significant from the market.

Tools

I had no idea about this fantastic SwiftPM feature before I read Bartosz Kunat’s latest post. If you ever have to make changes to a package your app depends on, then you need to read this.

Nick Heer kindly linked to Trevor Kay and Christopher Muller’s lovely screen sizes tool. As a developer, it’s probably been a while since you’ve needed to regularly worry about point/pixel sizes. That said, the information can still be useful, and this is such a comprehensive archive and well-designed way to consume it. It’s definitely worth a bookmark!

Code

Great advice from Matt Massicotte on when to avoid the temptation of a versioned Swift package manifest. I’m glad this feature exists, for the edge cases, but it should be a last resort when no other solution is possible.

Natascha Fadeeva:

Unlike a database-based storage, there’s no built-in migration mechanism. Since we don’t get any compiler hints or errors when changing the struct, this kind of storage may easily lead to bugs or lost data.

She doesn’t ask the question of whether you can store Swift structs in UserDefaults, but whether you should.

Design

Vadim Drobinin:

So the first UX lesson was painfully simple: minimalism doesn’t grant telepathy. In a normal app the UI does a lot of quiet admin for you: it tells you what you can do next, what will happen if you tap, and whether you’re in the right place. When you delete all of that and leave a blob on a gradient, you’re basically asking the user to infer intent from body language.

If you’re anything like me, you’ll really enjoy this design-focused look at Vadim’s novel and minimal language-learning app’s interface. Thoroughly recommended. 👍

I’d say it’s a little unfair to hold Apple to what they published in decades-old Human Interface Guidelines, but the point that Jim Nielsen makes in this post remains valid. Adding an icon to every menu item in a macOS app doesn’t help with usability. It’s also worth reading Nikita Prokopov’s article on the same subject. Both posts were written independently but make almost exactly the same points, and I suspect you’ll nod along as you read.

Jobs

Lead iOS Engineer (Senior/Staff) @ Moongate – Employee #4 at a fast growing (1M downloads, 120k subscribers) indie app for sound therapy. Work with 2 iOS dev founders to become the lead contributor to our modern Swift + SwiftUI codebase, and learn firsthand how a successful app business runs in 2026. – Remote (within US timezones)

Senior iOS Engineer @ alba – We have a unique approach to identifying opportunities, entering markets, and scaling our products. This approach puts us on a fast trajectory for maximizing the reach and delight our products create. Founded about three years ago, our products have been used by more than 50M users. – Remote (within European timezones) or on-site (United Kingdom)

And finally...

On this day 19 years ago, the world changed. Oh, and I know I should have waited until the 20th anniversary but it was a slow And Finally… week. 😬