Building Zavala 4.0
Adding data syncing to any application is hard. iCloud helps with that somewhat, but it is still really hard to get right. Shoehorning a hierarchical data structure like an outline into a flat data structure like iCloud is super hard and I did not get it right the first time. While I did improve the reliability of the syncing code over the course of many Zavala releases, it was never quite right. […] This has been resolved in Zavala 4.0.
To do this I had to change how Rows are stored in the internal database as well as how they are stored in the iCloud database. This new solution works really well, but isn’t compatible with the old versions of Zavala.
[…]
Love it or hate it, Liquid Glass is the new design language from Apple for their latest operating systems. If you are an app developer and don’t support it, your app is going to look dated and out of place on the latest OS’s. Fortunately, I feel like Zavala is one of those kind of apps where Liquid Glass looks good and isn’t the worst at usability.
Unfortunately, it is very difficult to have a Liquid Glass version of your interface along side the legacy look and feel of previous OS versions. This is because you have to update to the latest API’s to correctly use Liquid Glass and some things, like the spacing of elements have been changed. Basically to keep backwards compatibility for OS’s before the version 26 ones, you need to maintain two different versions of the user interface code.
[…]
I used Claude Code to translate Zavala into German.
Previously:
Update (2026-03-02): Steve Troughton-Smith:
iOS 26 is the minimum for any major releases of my apps going forward. There’s just no way I’m maintaining two separate UIs for every app
I only had one user write to me to let me know that not supporting older OS versions with Zavala 4.0 inconvenienced them.
14 Comments RSS · Twitter · Mastodon
"If you are an app developer and don’t support it, your app is going to look dated and out of place on the latest OS’s."
Not really on macOS. It's more the OS that looks like out of place when you use an application that is still using the better UI design options.
"So I made the difficult decision drop support for previous versions of iOS, iPadOS, and macOS."
Let's just hope for him that the new UI design team at Apple is as "talented" as the previous one and does not revert most of the controversial changes of macOS Tahoe.
"…your app is going to look dated and out of place on the latest OS"
This is not as high of a user value like it was 20 years ago, or even 10 years ago. Among Apple's apps, everything is an inconsistent mess that looks out of place.
It matters that you meet your *user* expectations, not Apple's WWDC talking points.
Apple's completely lost control of platform design. It feels like half of most user's apps are now Electron. No Electron dev I know had to waste their life on Liquid Ass (aside from an icon downgrade). Most importantly: their users aren't clamoring for LA.
It's a huge failure of AppKit, UIKit, and Swift that devs on the Apple stack are *constantly* forced to carry water for Apple and waste so much time on yearly churn just to say they're "up-to-date".
A big point of building on a vendor stack is stability and avoiding churn, and Apple is bottom-tier for this.
I'm happy this dev is continuing to develop his app. My main quibble is with the mentality that you *have to* follow Apple, even when you know they messed up bigly and they don't take their own advice.
"So I made the difficult decision drop support for previous versions of iOS, iPadOS, and macOS."
Difficult... the app is a three column split view with a toolbar, and the same exact layout as before. I greatly doubt it would take more than 2 hours to make it work properly even on iOS 12.
My users don't care much about the app looking dated - they care a lot about all the stuff Tahoe broke, though.....
The contempt for a rational decision by a Mac developer is something. As a Mac developer, I want my app to look like it belongs in macOS. That's what users want. More than 70% of my users are using macOS 26. My choice is to look out of place with current macOS users (> 70%) or adopt the new UI changes. If I'm going to look out of place, then why bother writing for native macOS. I use just build with Electron, QT, or some other 3rd party stack that doesn't look native. I can tell you that will make no one happy. Yes, this time around, it is a big enough split in UI that if I want to support older versions of macOS, I have to do a lot more work (in some cases duplicating the UI altogether). And once you split, you then add to maintenance for as long as you support those older versions of macOS.
If you're solo developer, the rational choice is to adopt the new look, or risk larger taking on technical debt down the road when the old look is so outdated that your app looks like it is from the early 2000s. The hope is that Apple will address some of the glaring problems and it will be better in the coming OS releases. Apple has already done this within the iOS/macOS 26 releases.
As a solo developer, I have limited resources (even with AI tools). Maintaining two different UIs in each platform seems like quite an ask of a developer. And for Maurice Parker, quite an ask for a free product that works across iOS, iPadOS and macOS.
It seems Mac developers always complain when we are left behind with UI changes, but then will also complain when we thrust onto front lines of UI changes. If you didn't think iOS and macOS looks weren't converging, you haven't been paying attention for the last several years. Indie Mac devs are pilot fish swimming around the shark that is Apple's ecosystem.
I agree with @Hammer, that the yearly churn puts extra stress on smaller developers. Whether it is UI changes, API changes, Kits going obsolete, etc. Apple doesn't care much about backward compatibility when it makes those changes, which puts the burden on us. And they rarely provide good tools (and/or techniques, examples) to help move us forward with all their changes. And certainly almost never take into account that we have to support older versions of macOS.
But then, Apple has always been that way.
"I use just build with Electron, QT, or some other 3rd party stack that doesn't look native."
This isn't System 7 or Mac OS 10.2. At this point, frikkin KDE has a more consistent ecosystem of third-party apps. Of the 100+ apps on my Mac, maybe 20 look like they belong on the platform.
I wish people would use cross-platform GUI toolkits and release their apps for other platforms.
@Mark Munz
"[…] to adopt the new look, or risk larger taking on technical debt down the road when the old look is so outdated that your app looks like it is from the early 2000s. […]"
This is not a "technical debt" risk. This is just having "taste". Which the macOS Tahoe UI team clearly did not have.
"My choice is to look out of place with current macOS users (> 70%) or adopt the new UI changes."
Let's imagine there are 70% of macOS users that have macOS Tahoe installed on their Mac (Apple just communicated the numbers for iOS as far as I can know (1)):
- how many did not have the choice to upgrade? Think enterprise.
- how many never had the chance not to have it installed? Think new hardware.
- how many were tricked to upgrade to macOS Tahoe because of the Apple's numerous poorly designed notifications and the terrible UI for upgrades in the macOS System Settings application?
- how many do not actually like it?
- how many would like to go back if given the opportunity but can't because of Apple's downgrade policies?
- how many do not give a damn about applications not adopting the Liquid Glass theme?
1. https://www.macrumors.com/2026/02/13/apple-shares-ios-26-adoption-stats/
Like NNW, Zavala is open source and free to use, so I want to say off the bat, I support the devs decision to do what is easiest for him. I will not complain about anything developers do this for for free do. But I’ve seen a lot of paid app developers take the switch to Liquid Ass to force Tahoe adoption AND a paid version upgrade and that’s where I lose my mind.
Your app would have to have features I cannot even contemplate for me to be willing to put Tahoe on my personal Macs. I’m hoping Apple will backtrack as much as possible next version, but I also feel bad for the OSS devs especially who put time into updating their UIs to look like garbage. The paid guys, look, this is your game. And if you chose to drop support and push a shitty UI you’ll probably have to change in a year, just on the off chance you might get featured in the Mac App Store (worthless promo at this point), hey, good luck.
And look, I get it, no developer owes their users anything. If telling 20% or 30% of your users to get wrecked is your decision, I respect it. For those paid apps, I hope to use your apps on my Apple silicon machine in fall 2026, when hopefully Liquid Ass is refined to a place where I can effectively use my Mac. But other than my work machine, I will not put Tahoe on my personal devices. And if that means I don’t upgrade (or continue a subscription) your paid app, well, I hope I remember it later this fall. I hope I don’t vibe code an alternative for myself.
The worst part of this whole Liquid Ass monstrosity is it’s the last macOS for Intel Macs. So it’s the last time we can expect any app dev to care about us, and yet, we're forced to have this Tahoe garbage as our last hurrah. For anyone who still has a usable Intel 2020 iMac or Mac Pro but doesn’t want to inflict Tahoe on it, this has essentially forced us onto either Linux or using Tahoe in a VM so we can keep our sanity.
“No one likes this design language and it makes our app look ugly but at least it doesn’t look like it’s from 2024” is depressing on myriad levels. Remember when Mac OS X indie apps brought their own style while still respecting usability conventions and we loved them for it? This sucks.
@Billyok Spot on.
Compare this era to the Delicious Era of app dev. Respecting platform conventions and expectations while trying novel designs and interaction.
Now we build apps with buggy UI gimmicks from a failed VR headset for a hypothetical touch Mac that's not even announced.
@Mark Munz "As a Mac developer, I want my app to look like it belongs in macOS."
And as a Mac user, I want macOS to look like it belongs on a Mac, rather than, I don't know, a hotel kiosk.
As a Mac user, I want the apps I use to value usability over keeping up with Apple's insanity.
I like my Apple hardware, but macOS is pushing me toward abandoning ship and going to Linux or even Windows.
The best apps on my Mac, the ones which have the best usability, and are the most pleasant to work in, the ones which best let me work, and focus my attention on the content upon which I'm working... also happen to be he oldest apps.
SketchUP from 2017, Capture One from 2021, 1Password 6 from 2018.
It's not just modern Apple UI style that's terrible, modern Mac App developers seem to be unable to do basic things everyone used to be able to do. When was the last time you saw a new app with a tear-off inspector / tools palette, an app where documents were separate windows from tools, where the app itself was anything other than an iPad screen floating in space on your display.
Yes, Qt apps may not look *perfect* as Mac apps, but a lot of the time they're *better* than the garbage the "stars" of Apple development offer with their giddy embrace of Apple's UI decorative fashion of the moment, and least-effort-necessary single-window UI paradigms.
Go look at what the Krita folks are able to do in an Open Source, free app for Pete's sake.