Wrote basically the exact same thing 1 day later in Swift with AppKit and NO SwiftUI and it sits at 0% CPU usage with less code complexity. Maybe in a few years I will give SwiftUI another try.
Is it possible it is re-rendering the view hierarchy due to some data invalidation you haven't noticed?
Just like cars, you can’t build a Kia Soul, and then just replace a few parts to reach Ferrari-like performance.
AppKit (NextStep) has been iterated on for over 30 years now.
Apple's development strategy is like that of old school Microsoft. They make a choice like Win32 and just keep on iterating on it over the long haul. Four years of SwiftUI would still be described as very early days.
Nothing like the development strategy of the week you see Google and the Microsoft of the past decade push as the one true future then abandon almost immediately.
It's not about Final Cut Pro specifically. It could be a new app. It's about having a single showcase complex app that says to developers—look hey we can build something really performance intensive and sophisticated in SwiftUI. We're dogfooding it. Look what can be accomplished with it!
It could be anything—Final Cut Pro, Logic, Pages, Numbers, a new productivity app all together. Some showcase sophisticated, complex productivity app to show what can be done with it and we're in the trenches with you using it.
I'm converting the iOS version of the app from UIKit app to SwiftUI and it is a nightmare. Nothing works, everything is tightly coupled, and nothing works out of the box without some hacky modification and much googling. I've also come to the conclusion that they don't use SwiftUI before releasing it.
> everything is tightly coupled
just curious, but what do you mean specifically?Who told you this? :D
SwiftUI is mostly useful for apps that show a bunch of nested lists. Basically websites, but natively. It's Apple's answer to React Native or something, and it looks cool in demos with the live preview and whatnot. But serious apps like Pages, FCP, Finder, Calendar, etc. will never be written with SwiftUI. The paradigm is just too wasteful for these kinds of interactive apps.
Heck, large apps aren't even using Swift! It's just too inefficient at their scale. And before you say it's due to legacy ObjC code - no, Facebook rewrote Messenger from scratch in ObjC(++) a few years ago. Swift is cute, but it lacks the maturity and stability of ObjC.
Apple explicitly said so in a WWDC 2022 video. I think it’s the State of the Platform one, or if I’m wrong, the one titled like What’s New in SwiftUI. Their statement is that while UIKit and Objective-C will serve us for a long time, the best way to write new apps for Apple platforms is with Swift and SwiftUI.
I don’t believe that though. Swift is a great language, I agree, but UIKit is way ahead of SwiftUI and I would never use SwiftUI in a product where meeting deadlines matters, at least not in the next 3 or more years.
Nonsense.
And yet here we are, Apple doing the same thing to macOS, resulting in the same shit desktop/mouse experience that macOS has become.
I understand the reasons but it seems so incredibly un-Apple to sacrifice UX for this.
With that said, this is an interim solution; I’m actually working on my own desktop environment as a long-term solution, since I’m disillusioned with what modern personal computing has become, devices and software that promote consumption over creation, and environments that encourage walled gardens and large moats instead of interoperable, interchangeable components. What I want is essentially the classic Mac interface with Smalltalk- or Lisp machine-style underpinnings; the power to mold my environment to my taste, but with user applications that abide by the 1990s-era Macintosh Human Interface Guidelines, when Apple had UI/UX heavyweights like Don Norman and Bruce Tognazzini influencing the Mac’s direction.
There are no macs with touchscreens and no plans to release any from what I gather — that's what iPad is for, after all.
Microsoft tried for a decade to merge touch design in a desktop space and it was whole-heartedly rejected in the marketplace. Funny that Apple has been trying the same thing long after I get the sense that it no longer matters.
I'm not against the idea of unifying the underlying frameworks, but they went with a lowest common denominator approach. In my mind, that is a failure of execution on their part.
I am still surprised that Apple is pouring resources into the Mac. Nowadays, smartphones and tablets are the main computer for 90% of people. The sooner Apple rebuilds Xcode from the ground up for the iPad, the quicker we can get rid of the Mac with its decades of legacy baggage.
Now more than ever it's important to keep developers / desktop users.
If they destroy macos, lots of developers will actually go somewhere else. What do you need these days? Chrome..
If I'd move off of the Apple ecosystem with my laptop, I'd probably look into other fields to jump ships as well.
MacOS X became popular bc of developers. We are the ones creating things for people.. I hope they don't forget this.
However, that wouldn't replace macOS for me at all. I see a lot of value in iPad as a device I use on a regular basis, but even with all those features, I still need a general purpose computing machine for plenty of reasons. No matter what features iPad might end up having in the future, it wont replace macOS for me.
Killing Mac not only hurts Mac itself, it also hurts all the adjacent products. Two features I personally really like on iPad are universal control over mac+ipad screens (one keyboard+trackpad controls both devices at the same time, but keeping the OS and everything else entirely separate) and the extended screen (where ipad can act as a simple external screen for a mac, either as wired or wireless). That class of features straight up wouldn't exist without mac existing. Hell, part of the reason i even use an iPhone is because of how smoothly it interacts with macOS (shared clipboard+imessage ftw).
Sure, the general public needs might change, and they might swing towards ipads over similar form factor general purpose computing devices (aka laptops). I don't see it happening, however. The people who would be the ones to do it, they had already done it by switching from laptops to smartphones over the past decade with the rise of iOS and Android. And i just don't see them switching away from smartphones to iPads (or tablets in general, for that matter).
I’ve used a Mac my whole life. Recently, I’m using 4-finger swipe to switch full screen apps. I’m also choosing the “snap” layouts over dragging windows around. It’s useful to have 2 folders on screen to be able to move files between them, but I don’t stack windows like I used to.
Part of the definition of a "real computer" is that it's truly general purpose. Anything not meeting this requirement is a special purpose device or at most a "console," which is the category I place iOS devices into.
Sure, that’s where things stand today, but the Mac is part of Apples brand. They screw it up enough and iPhone won’t win on its strengths anymore. Design and execution.
You’re on top of the world…
Until you’re not.
It used to be but not anymore. The iPhone is Apple's most important product and the majority of iPhone users aren't interested in the Mac.
All those apps used by people on smatphones and tablets get developed on a Mac.
You should also compare sales trends vs point in time stats to get a better picture, as Mac sales got a significant boost with the introduction of the M1 chip.
There is still a market of billions of dollars for those people who need a general purpose machine and not a walled garden.
Even if you are right and the mac will be no more, there will be people doing general purpose computing on Linux and Raspberry pis. Those people will be willing to pay for a better experience.
legacy baggage, a lot of which is/was well-designed or well-thought-out baggage, that is also being thrown out the window in the rush to mobile-ify everything, making people less productive overall, because big companies (and users) are bent on the idea that users shouldn't learn how to use their tools.
Still, I think this will be a major loss for longtime users of macOS who enjoyed roughly two decades of using a well-polished operating system that was unabashedly designed for desktop computing workloads, unlike Windows and some Linux desktops with their confused aims of trying to merge the desktop, mobile, and Web experiences. While iOS's success has been undoubtedly wonderful for Apple, in some ways the success of iOS was the worst thing to happen to the Mac. What hurts in particular is that there is no alternative with the polish of macOS and its ecosystem; it's all ports of Web apps and mobile apps from here on out, with the usability and flexibility issues inherent in these engineering decisions, and all running on platforms that support the moats that Microsoft, Apple, and Google built.
I saw the writing on the wall years ago and my daily drivers are now PCs running Windows 10 and FreeBSD. I don't work for Apple and I'm just one complainer on Hacker News, and so I have little control over the Mac's direction; the best I can do is vote with my dollars. But I'm hoping projects like helloSystem and ravynOS will gain traction and help keep the spirit of Mac OS X alive, and I'm working on my own side project that will explore ideas influenced by the classic Mac OS, OpenDoc, Smalltalk, Lisp machines, and Plan 9; basically, explorations of what could've happened if some of the dreams of early 1990s Apple researchers and engineers had been realized.
The rest of industry has moved on to Electron and keeps bucking, trying to get react native or some other cross platform thing to work well enough on mobile.
Apple itself uses webviews for complex UI in their desktop Music app. Are there any non-trivial apps Apple has created from scratch in the past decade using its own libraries and frameworks? No, right? Why should anyone expect the libraries they themselves don't need or use to be any good?
It also depends on what you mean by "non-trivial". For me, something like Final Cut Pro is non-trivial. I'm yet to see that kind of thing (one that's actually used, not just a PoC) done in either Electron or Apple's Swift framework-of-the-year.
I don't think there are more than 1000 people worldwide who have shipped a moderately complex mac-native app within the past decade.
Apple doesn't seem to think it a problem - they're well on their way to becoming a company people despise but continue using, like Microsoft, Google and the rest of em.
Nobody is saying that. It's a good stop gap for building cross platform apps that don't need to be rewritten every 2 years, when MS and Apple design PMs launch a new fad framework. (Friendship ended with rounded flat buttons, new best friend is glassomorphism)
What people want is primarily a good rendering target, and for that you just need a webview. You can port many electron apps to Tauri today and reduce footprint to native levels. OS vendors have slowly and reluctantly come around to provide webviews.
> It defeats the entire point of making a desktop app in first place.
Absolutely false. Sure, there are a few apps that could have been web only, but have you seen Electron's API surface? It provides a ton of useful features for apps that can't be achieved through the web, such as.. Opening a file by path.
> It's slow, wasteful[...]
Electron is perhaps slow to start, but fast afterwards unless you bloat it with your own crap. And electron is wasteful though, a lot. However, webviews used correctly has no meaningful perf downside. In fact, JS- and web rendering engines are some of the most optimized pieces of code there is.
> [...] abstracts too much of the filesystem away for a desktop app
I'm not sure what you mean? Electron provides the Node APIs directly, which are similar to any other std lib. Speaking of abstracting the file system, have you seen Apple's "bookmarks" they created for persistent file permissions within a sandboxez app? That's abstraction for you.
> [...] doesn't integrate into the OS
Partly true, and it should be better. Any cross platform UI framework is at a disadvantage because native is completely non-standardized. At the same time, web gives you accessibility, zoom, system fonts, rtl, locale etc, so it's much better than most bespoke UI frameworks.
> [...] doesn't use the OS-provided UI widgets
Text fields and similar inputs are native by default. For say sidebar nav, it's again not standardized, so you have to either provide high-maintenance-greatest-common-denominator APIs or trouble the developer with per-OS moving target APIs. I understand why devs don't bother, and as a user I prefer that VSCode works the same across my computers over 2-3 per-OS uncanny valley same-but-different experiences.
It mirrors what Valve is like these days. It's the Steam platform company. They do make a few new games (Artifact, Half-Life: Alyx), but nothing transformative like their previous new franchises or even sequels were like. So many companies are in the platform businesses these days, because it's good to be a rentier. So it goes.
And that's why that new app is complete garbage. If you think iTunes was bad, this is much worse. iTunes at least had some actual functionality - its replacement has mostly whitespace.
Really? Do you have a source for this?
Because honestly I find it impossible to find anything in it and the search doesn’t even work reliably.
We're going to a CRUD operation world, where you have to do every edit one-by-one. And then in a few years, people will be amazed that you can save so much time because of a new "bulk editing" feature.
Ahh such great times with Office in the 90s.
This thread of UI issues with the Ventura System Settings really says it all. Most of this would have been shocking in a different era of Apple.
So what are they doing now? Using tools that evolved to serve touch-first interfaces to build desktop applications.
The Mac/iPad split grows more confounding with every iteration. Now it feels like familiar desktop features are being reimplemented poorly in both iPadOS _and_ macOS.
Apple views the Mac as an iPad with an attached keyboard and optionally cooling.
There will be touch on the Mac very soon and they are preemptively getting the Apps ready. The whole Apple Silicon migration is to facilitate this merge of macOS and iPadOS. As soon as the 3 year migration to Apple Silicon is complete and most developers have stopped relying on Rosetta, Macs will have touch and there will be no longer two OSs.
At least they don't suffer from the "it's working on Electron and on the web", meaning it will not run any good anywhere. Same result at the end though...
Taps and clicks are completely compatible and the only issues come from multitouch interfaces but even they can work well with substitutions like scroll to zoom instead of pinch to zoom.
Besides, the web has been first-class on both platforms for quite some time now and interfaces that work well on both are pretty much ubiquitous. It comes with added benefit of UI familiarity, be it a Web UI or mobile UI.
Therefore, I think the current issues in some apps are not fundamental but simply bad design choices that can be fixed with better adaptations.
I also don't expect quick and complete re-write of the established apps as re-write with a new UI framework is a common death sentence.
I don't think Apple lost their religion. I think Catalyst/SwiftUI were created as an answer to desktop applications moving to Electron. Moving to web-based applications significantly reduces the value proposition of macOS and to some extend also iPadOS/iOS. Most likely, a SwiftUI app will still be a better macOS app than an Electron app. And if you can use a single framework across Macs/iPhones/iPads, it might entice developers to use SwiftUI for Apple platforms instead.
IMO, Catalyst and SwiftUI (at least so far) are a regression compared to good-old AppKit apps. But the world has changed, and I'd rather have a Mac/iOS world with SwiftUI apps than one with Electron/Ionic/whatever apps. At least the SwiftUI apps will look somewhat consistent and provide stronger platform integration.
How is it an answer? Electron gives the developer the same code for the web and for Microsoft Windows. Catalyst and SwiftUI give the developer none of theses.