And rightfully so. Tahoe is not just a step back, but it throws away so many good design elements that have been there for ages - and for no good reason.
I really hope they revert most of the design changes in macOS 27. I don't mind the Liquid Glass - the other changes they made to expose/highlight Liquid Glass are the real issue.
IMO we reached peak design in 2013 with Mavericks.
The golden rule from Apple in 2007 when they changed to flat design was icon or text - never both together.
Apple abandoned enforcing HIG for app developers around 2012 (Facebook tiled menu, modal abuse, and hamburger) but now seems to have given up on standards entirely.
The wall to wall interaction pattern is terrible too. Every time my hand brushes my phone some unexpected (and sometimes unknown) interaction occurs. Classic example is changing orientation while watching YT where accidental contact with the bottom-left (becoming top-right) part of the screen as you move the phone selects a new video. It’s becoming slop.
Good that Alan Dye is no longer at apple. Liquid Glass on macOS is a mass. The icons, the floating side menus, the inconsistent corners, the new tabs in Safari..
On iOS it's totally fine, but on macOS it's a disaster. I've only updated one machine so far and will keep all others on Sequoia until this mess is resolved.
But it wasn't just Alan Dye. He's not tunning the MacOS division. He's not running tge iOS division. There are literally dozens senior management people and several people of the same rank who could've pointed out all the issues and stopped this.
You can get away with sloppy, cluttered and inconsistent UI on mobile when everything runs serially, full-screen.
But bring that to desktop, where your UI is windowed and appears alongside (or overlapping) other windows, and you end up with chaos.
The floating sidebars are a prime example of this. Why should I have to expend mental energy to differentiate what's an actual window -vs- what's just a novelty round-rect with a shadow (oh, and and window controls for the parent round-rect, which is a window)?
Yeah, but I doubt that would change much; the amount of damage done would be difficult to roll back. What do you think Apple is going to do for the next macOS: "Look we told you to design all these extra icons last year. Guess what, this year we want you to remove them."
I just can't imagine that happening. This is the fundamental thing that is wrong with this. They had the OSes in beta for a few months, barely listened to feedback, and now we're stuck with the damage. For how many more OS iterations?
I really wish they had at least macOS in a different cycle than iOS (and with the idiotic year version names, they've brazenly signed themselves up for the yearly schedules.) I really couldn't care less about what damage they do to iOS after iOS 7, but I still haven't upgraded to Tahoe and I won't do so until they roll this design back entirely...which I don't see happening.
Maybe I'm just pessimistic about Apple at this point but I feel like no amount of criticism is going to change their design trajectory now, unless it affects their bottom-line.
they'll slowly walk the changes back until the aesthetic is usable
in 8 years or so we'll probably get the next major overhaul
we're not stuck with the damage, except for the icons and such. the rest can be changed no problem. they could remove liquid glass tomorrow and make everything look like visionOS and the icons would still fit just fine
but they can't roll back to the previous design. which is a shame, because they poured in probably millions of man-hours to make it great. and the soulless app icons we now have won't ever match the 3d ish big sur icons that were filled to the brim with personality.
hell, there even were entire webpages and social media accts dedicated just to macOS icons. i regularly saw icon showcases on twitter with thousands of likes. not anymore :(
I hope with change in leadership correction of these things will be possible again. Not just Alan Dye, but Tim Cook is rumored to leave in the next year too.
Hah, really? If you enter recovery mode and install an OS via network it installs the OS the device originally shipped with, right?
On an Intel-based Mac:
- If you used Option-Command-R to start up from Internet Recovery, you might get the latest macOS that is compatible with your Mac.
- If you used Shift-Option-Command-R to start up from Internet Recovery, you might get the macOS that came with your Mac, or the closest version still available.
Eh iOS is fine UX-wise, but the OS is so buggy now it's unusable. macOS looks weird but works basically fine. I haven't noticed actual changes in my workflow; while on iOS, camera stopped working reliably, wallpapers randomly change to black, alarms randomly don't work.
Maybe it's because I use iOS more, while in macOS I "just" work, which is in reality opening a few Electron apps, a Chrome browser and a Terminal.
Nice! A screenshot in the readme would be a great addition. I was looking for a native macOS Teams client a while ago - but to my knowledge this is the first 3rd party Teams client.
I agree, this is the way. To be clear: I'm not a mobile developer, and have only dabbled with it over the years, but I'm generally familiar with the stacks.
If you want to simplify development of a cross-platform app, your work should start by architecting the software in a way that the core business logic is agnostic to the user interfaces. Then your web, mobile, and desktop GUIs, CLI, TUI, API, and any other way a user interacts with your program are simply thin abstractions that call your core components.
The complexity of each UI will inevitably vary, and it might not be possible to offer a consistent experience across platforms or to leverage unique features of each platform without making your core a tangled mess, so this is certainly not "easy" to do in practice, but this approach should avoid the bulk of the work of targetting individual platforms than if you had done it any other way. It should also avoid depending on a 3rd-party framework that may or may not exist a few years down the line.
One extra clarification: If the quality of your app is business critical you should really use the native UI toolkit to offer the best platform integration and user experience.
If your app is not business critical (you just have to offer it - example: dishwasher app, ..) you might get away with using a cross platform toolkit like flutter or react native. But even then this adds a 3rd party dependency as you mentioned which adds risk.
Writing an App in Swift on iOS is boring. The same thing is true for writing an Android app using Kotlin/Java. This is a good thing. Now your developers can concentrate on shipping great features.
I hear this and it makes sense but when I actually go about implementing it, it quickly falls apart.
Most apps are UI, remote requests and maybe some storage. What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
Excellent Points, this is where the answer is "it depends".
> What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
If it's really functionality that cannot reasonable be shared don't share it.
It's probably more work to maintain bindings to a single API client in the core and fiddle with all the details of not using the native HTTP client implementations that it is to implement the API client twice.
Writing the API client twice is boring, but that's a good thing.
> Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
The shared core is optional. You might have the need for it, then it's a good solution.
For an app like snapchat you'd probably share the video effects and have that in your core library.
That's perfectly reasonable but, at that point, the argument becomes: build 95% natively and maybe there's a 5% "core" that warrants extracting into a common lib. Technically? That's excellent architecture. In terms of saving development time — which is where stuff like React Native comes in? Not so much.
This is the direction we are going, but at the moment we are doing iOS only, but with the plan of learning the users UX needs in iOS before investing in Android, which is a bit strange because most of our team are on Android, but our users are on iOS.
Every time I see a new project like Valdi, I am hoping for something that is truly magical and cross platform, but I'm always steered away by comments like yours and people saying "you have to do native".
For context, I am a dev, and I've done RN apps in the past.
And rightfully so. Tahoe is not just a step back, but it throws away so many good design elements that have been there for ages - and for no good reason.
I really hope they revert most of the design changes in macOS 27. I don't mind the Liquid Glass - the other changes they made to expose/highlight Liquid Glass are the real issue.
IMO we reached peak design in 2013 with Mavericks.
reply