I recently took to rewriting what should be a very simple app from Obj-C to Swift with SwiftUI - because it's the future. The CPU usage was at 5% while idle, just for having a simple tiny pie chart that updates. Not to mention that for some seemingly basic things I still had to use AppKit anyway.
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.
Did you find out what was causing it? I have developed 'heavier' (aka 50k lines of code) applications in SwiftUI on mac and it mostly sits idle (0-1% cpu based if it is doing some regular background stuff). Heck, I just created a quick Charts based app from an online example on Mac and stays at 0,0%.
Is it possible it is re-rendering the view hierarchy due to some data invalidation you haven't noticed?
Was this with the debugger attached? Did you do any further profiling in instruments on a release scheme to determine the cause of the cpu usage? You should be able to narrow it down to the specific sys calls.
It's really not an impressive showing for SwiftUI. 4 iterations later and after being told it's "the future" in unequivocal terms, it's still at 12% (and only like 3% without any AppKit combined (last chart)). It's not dogfooded for any productivity apps. For Ventura, rewriting "Font Book, System Settings, and Tips" is not exactly confidence inducing. If they rewrote Pages or Final Cut Pro, that would wake people up. One showcase productivity app. The thing is, in its current state, I don't they can.
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.
UIKit after four iterations (i.e., iOS 6 in 2012) was far from its "very early days": it was a well-designed, production-ready, powerful UI framework that was way closer to AppKit than SwiftUI (in its fourth iteration) is to UIKit now.
UIKit started out with more polish because they took the AppKit they had iterated on for so many years and slimmed it down for extremely resource constrained devices.
Why would they rewrite Final Cut Pro in SwiftUI? Rewriting code is a large effort and a waste of time without proper justification – new developer tooling for UI is not usually a good enough justification to rewrite the entire UI
> Why would they rewrite Final Cut Pro in SwiftUI? Rewriting code is a large effort and a waste of time without proper justification – new developer tooling for UI is not usually a good enough justification to rewrite the entire UI
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.
Absolutely! So you need to align that goal with a project that is actually going to provide value to the end user. There aren’t enough new features each year to (re)write large portions of macOS UI.
The Shortcuts app in macOS 12 and the Settings app in macOS 13 are almost entirely SwiftUI and the most substantial projects in this regard
I converted the Android App I work on to Compose with zero problems everything just worked. Everything that didn't work was my fault because I didn't grok something about how recomposition worked. I was able to convert everything in small encapsulated pieces without breaking other parts of the app.
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.
So why are you doing it? Why not just leave it UIKit. Is it just a learning experience? Clearly, UIKit is not going anywhere for a LONG time, so I don't feel compelled to update old code.
>after being told it's "the future" in unequivocal terms
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.
Exactly. I haven’t upgraded my Macs since Mojave, for this and other reasons. I’ve grown increasingly disillusioned with the direction of the Mac under Tim Cook. What happened to the Macintosh emphasis on building software for creators that was easy to use? Last year I moved on to Windows 10 on a Surface Pro and a dual boot Windows 10 and FreeBSD with KDE on a Ryzen 9 workstation. I still have my 2013 MacBook Air and Mac Pro whenever I need a Mac, but my Surface Pro and Ryzen 9 workstation fit my needs.
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.
Microsoft at least made a semblance of sense because some Windows laptops have touchscreens and some even can be turned inside out into tablets. They wanted to embrace those hardware capabilities but did so at the expense of the remaining 95% of their users.
There are no macs with touchscreens and no plans to release any from what I gather — that's what iPad is for, after all.
My worry though is that when Windows fucked up, Mac OS was a viable alternative. Now that Mac fucks up, what's the alternative? Linux has its own challenges.
Windows is absolutely not an alternative. The UI degradation we're complaining about in the Mac has already happened in Windows - I mean they've now got 3 different UI paradigms for system settings and the newest one is this disgusting phone-style UI full of whitespace. Ads and "suggestions" everywhere don't help either.
Still crazy.. I want to use my keyboard. My shortcuts, and do proper bulk operations. It's just pure laziness from their devs.
They don't know, they don't care..
The iPodification of the Mac has been so utterly jarring to me. Little nuances in productivity have been reduced to accommodate porting over a platform that was designed for touch.
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.
In 2021, the Mac grossed $30B. iPad ($30B) and iPhone ($196B) together grossed $226B. Mac users might think they're still the most important part of Apple but it turns out, the Mac is quite insignificant compared to Apple's mobile OS's when you put things in perspective.
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.
Don't get me wrong, I definitely like my iPad pro a lot, and use it on regular. And I also think that having some functionally useful version of Xcode on it would be amazing.
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.
I do, yeah. Though I stopped using windows for work and just use it daily for gaming or just general reading/browsing/minor task machine. Occasionally I would write a bit of code on it, maybe a small python script or some in-browser debugging, but that's about it. For work, audio/music recording related stuff, coding side projects, and all other sort of personal usage, it is macOS. I also use linux for work quite a lot, but usually from an ssh terminal on a mac machine.
If I had to put numbers on it, it would be around 60/40 mac/windows split on weekdays, and around 30/70 mac/windows on the weekend. Heavily averaged out, because there are definitely days and even streaks of days when i exclusively use only one OS or the other.
Also, do you mind elaborating a bit on what you meant by the swiping story?
On a personal tangentially related note though, I also like a lot how the swipe gestures are shared between macOS and their touch-based devices' gestures. That's how i accidentally ended up discovering a few nice and useful macOS ones. Once i realized that three-finger gestures on a mac trackpad act as an equivalent of single-finger gestures on iPhones, the first thing i tried was a three-finger swipe left and right. And yup, it was virtual desktop switching. Then i tried a three-finger swipe from the bottom, and it zoomed out and brought up all open windows on screen at the same time, and then returned back to what it was before when swiped back down. Not gonna lie, it felt a bit mindblowing how nicely designed and thought through it felt.
So sorry, I totally misread what you meant and wrote a wall of text about Windows OS, rather than desktop window management.
I do use quite a lot of application windows on macOS, and I use Rectangle Pro to snap/organize them. I saw someone else mentioning Moom in the comments as well, also heard good things about it.
However, I will admit, I definitely like the way FancyZones (feature built-into PowerToys, which is a first party Microsoft tool for Win10/11 full of other nifty things) window management works more than that of Rectangle Pro. But the combination of Rectangle Pro + virtual desktop organization + trackpad gestures is imo amazing for overall window management for me. I definitely like that overall package more than FancyZones on its own.
The iPad can't replace the Mac unless I can run my own software on it outside the App Store.
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.
That argument is shortsighted. Classic business school thinking. No consideration of second order effects or long term strategy.
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.
> 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.
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.
That's because the majority of iPhone users are consumers.
The majority of Mac users are producers, creating content for the iPhone users. If they kill Mac then their iPhone cash cow will dwindle as they will no longer have content.
That's not true at all, and sounds like Mac user elitism that everyone hates.
It is true, that many iPhone users aren't interested in mac and some not interested in any kind of desktop/laptop device at all. The same true vice-versa - I have a mac* and not interested in iPhone and plenty of my colleges are the same.
*: One because compliance is easier than on Linux and another one because I need to develop for mac and iOS.
Sorry, that's not what I meant, I incorrectly phrased that the wrong way around.
If you are making stuff for iPhones, you essentially have to have a Mac because XCode to create iPhone apps requires a Mac to run. I meant the majory of app creators are Mac users. So if they kill the Mac workflow then they will castrate the cash cow that is the iPhone.
I know there are alternative workflows you could make by using something that can cross compile to iPhone and using a Windows/Linux system, then renting a Mac device via a cloud service like AWS, but I would be surprised if it made up a significant amount of development.
> If you are making stuff for iPhones, you essentially have to have a Mac because XCode to create iPhone apps requires a Mac to run.
I would assume people at Apple aren't brain-dead to kill mac and not have an alternative development flow, haha. "killing mac" if it's on a table would include allowing other platforms to build iOS / iPadOS apps.
> $30b is an awesome business all on its own, and compliments, not detracts from, the iPhone brand.
yep, and just because the ratio of revenue is heavily in favor of iphone, there is no reason to subsume (subvert?) the mac ui into its paradigm... the worse ux could result in that 30bn shrinking, wherein they will just devote more resources to consolidation, again accelerating the mac's decline.... its a potential negative spiral if i ever saw one...
There's huge amounts of work that can only be done on desktop or on laptops, and not on smartphones, simply because of form factor. Unless we're imagining a future where people plug their phones and tablets into monitor-keyboard setups and type away, all the time.
> I am still surprised that Apple is pouring resources into the Mac. Nowadays, smartphones and tablets are the main computer for 90% of people.
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.
> 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.
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.
> the quicker we can get rid of the Mac with its decades of legacy baggage
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.
To be honest, before the release of Apple's M1 Macs in 2020, I thought that the Mac was on its way out, especially around 2017 when we had to endure many years of waiting for new desktop Macs (the Mac Mini had a long period between updates from 2014 to 2018, and the Mac Pro had an even longer period from 2013 to 2019). I still think with the gradual adoption of iOS UI/UX idioms by macOS and the growing adoption of SwiftUI, combined with the fact that Macs now run on Apple Silicon just like iPads, that eventually macOS and iOS will merge despite Apple's repeated claims to the contrary.
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.
SwiftUI has been a pain to learn because it’s young and you still need to learn UIKit or another framework to get unsupported tasks done. So basically need to learn the old frame and the new just to use the new. At least that’s been my experience not knowing the older frameworks myself.
Same here. Have had to use UIViewRepresentable a few times to make use of UIKit features that SwiftUI doesn't support. Specifically, MapKit is incredibly barebones in SwiftUI, so I couldn't use it at all. Had to use an MKMapView through a UIViewRepresentable instead; this is so I could do things with custom overlays, even as simple as paths between two coordinates.
Meh. Apple has near infinite resources, it can do whatever it wants.
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?
Electron is not a good option either. It defeats the entire point of making a desktop app in first place. It's slow, wasteful, abstracts too much of the filesystem away for a desktop app, doesn't integrate into the OS, doesn't use the OS-provided UI widgets, etc. etc.
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 hear you on the downsides of Electron. The upsides are that there is a plethora of ready-made UI and backend integration solutions to choose from and an abundant pool of candidates to hire from, for a reasonable wage.
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.
> I don't think there are more than 1000 people worldwide who have shipped a moderately complex mac-native app within the past decade.
This is grossly mistaken.
The Mac App Store, which is only 11 years old, is by itself empirical refutation of this claim.
Also, I believe your claim is also mistaken that "Apple itself uses webviews for complex UI in their desktop Music app." Where do you get that from? I don't mean to be rude, but your other comment "I've mistakenly conflated Electron with webview use" strongly suggests that you're not technically sophisticated when it comes to analyzing Mac app binaries. No Mac developer would ever make that mistake. (I think we can safely assume that you're not one, considering that you think there are only 1000 worldwide.)
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.
I'm not sure if Apple is planning on building huge non-trivial apps anymore. This isn't a knock against the amount of work that goes into creating new versions of their macOS apps. But I don't think any of them are creating new transformative experiences for use cases that consumers were missing on before. Stocks and News are just delivering more content and services. This very much reflects Apple's continued focus in becoming a services company.
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.
It's not Electron, but it does use a fair bit of web views, or at least did in the past (there might have been talks of some of it being moved back to native code). Either way, it feels like an Electron app, and not even a good one. It's a piece of shit.
Why would someone be forced into changing their entire operating system to get an update to an app?
I just checked since I own multiple macs. It's true, they're going away from webviews, but their new native app ui is broken! When you go Browse, click the first big image and then press the back button in the top left corner, the white navigation bar space at the top disappears, causing the content below it to visibly jump up.
>Why would someone be forced into changing their entire operating system to get an update to an app?
...probably some APIs used that don't work on older OS's, and/or why bother supporting old Macs when the old app still works fine? I don't think it's a big deal.
> Apple itself uses webviews for complex UI in their desktop Music app
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.
Interestingly, the search index in iOS Settings is not based on localized UI strings, as one would assume or hope, but on keywords that are updated independently of the UI as a neglected afterthought. So, while it’s technically “reliable,” you’re right that it can’t be relied upon.
Yup. and basically all apps (re)created suck big time. They're just iOS ports. You're forced to do litereally everything using your mouse, and for example the Home app, it's basically useless if you want to organize/edit things.
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.
I started using macOS with Big Sur (still on it) and I don't understand why Apple would remove the ability to select buttons in dialog windows with the keyboard. I've googled it and it seems you used to be able to do that on macOS, but when I follow the instructions on Big Sur, I can't move the selection from the button active by default to the other one (e.g. "Ok" vs "Cancel"). That means my right hand is making runs between keyboard and mouse all the time. Very unergonomic.
There’s an option in Keyboard settings > Shortcuts > “Use keyboard navigation to move focus…”. There are a couple security based dialogs it don’t work in but the majority of things it does work for me.
As others have said "use keyboard for navigation" works, but also you can generally press any button with the shortcut cmd-first-letter-of-button-text. E.G., if the dialog is "delete" and "cancel" and cancel is the default, cmd-D should press "delete". "replace" and "cancel", cmd-R should press "replace". Etc
4. A dialog box shows up, prompting you to save the file. Hitting Tab just cycles between the "Save As" and "Tags" text fields. There is no way for me to select the "Delete" button with Tab.
Challenge: quit TextEdit.app in that situation with they keyboard, without using the mouse, and without saving a file.
That's a broader topic btw: Apple's apps often make the Tab button only cycle between text fields. In Safari when logging into Spotify I can't reach the "Remember me" checkbox with Tab. It only cycles between the login and password textfields and the URL bar. Luckily, other browsers don't have this flaw.
I believe this is possible if you turn on "Use keyboard navigation to move focus between controls" in System Preferences -> Keyboard -> Shortcuts. I have no idea why this isn't on by default.
That works, thanks! Although there is a weird bug that going forward with Tab cycles through everything and goes back to the first field, whereas going back with Shift+Tab stops at the first field.
This^. It used to be command-D for "Delete/Don't Save" but at some point they changed it to command-delete; maybe someone thought it made more sense and was harder to type by accident?
<Delete> command-delete (backspace, not forward delete)
<Cancel> esc
<Save/Default> return/enter
I actually prefer command-D precisely because it is easier to type: on the home row and you can type it with your left hand while mousing with the right.
For “Delete” specifically you can also simply press ⌘backspace when the save dialog is activated to trigger the button. In some dialogs where the button is “Don’t Save” (i.e. autosave not active) the combo may be ⌘D
Home: you can only cycle between de navlist on the left, and the top toolbar. The complete app does not respond to the keyboard, probably because they are not buttons, but clickable rects.
There's this boilderplate menu "Format". cmd-nr nav behaves weird.
Reminders: you can only cycle between de navlist on the left, and the top toolbar. The complete app does not respond to the keyboard, probably because they are not buttons, but clickable rects.
Stocks: you can only cycle between de navlist on the left, and the top toolbar, and it get towards some articles, but it simply doesn't work properly. Arrows have weird behavior, can't nav to "more data". But this is a lot better than the previous two.
Everything feels just like some one-person solo project recreating the OSX experience, but only focusses on how things look.
Doesn't work for me, probably because my system language is Russian. The button is "Удалить" but neither Cmd+D nor Cmd+У work, regardless of the current keyboard layout.
I hate this consolidation of mobile and desktop apps and I hoped Apple would have had the design sense to keep them separate like they should be. Mobile and desktop UIs are two different worlds with different interaction paradigms. Trying to combine them makes an awkward UI that feels good nowhere.
Most new macOS apps from Apple seem to be pretty awful and don't feel like an actual mac app. Home, TV, and Music have some really horrible ux/ui. Music is slightly better than the others but you would think they would have the resources to make these right. TV and Music are subscription-based in a way which seems like a no-brainer to add resources to make a proper app.
For non-Mac users, Ventura is a forthcoming version of macOS which will be released this fall. Developers are reporting UX issues with beta releases now, and in my experience, many of them will be fixed by release. However, a System Preferences rethink is going to take multiple OS releases to get right.
It’s really quite remarkable how something as simple as a settings app ends up showing the toolkit isn’t ready for prime time. The new windows settings app was also a disaster.
Settings seems like a good way to test out a Framework. You've got a lot of different areas to cover, with a mix of graphical content, text, buttons, menus, & dropdowns.
Supposedly a major justification for the continued separation of Mac and the others (especially iPad) was differing UI interaction patterns.
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.
it’s not that confounding when you consider that iphones dominate apple’s earnings, and so apple wants to unify the platforms under ios (via ipados) rather than under macos where they have no app store lock-in.
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.
What a depressing future we're headed into :/ Instead of iPad becoming a "proper" computer, the Mac is being dumbed down to become a tablet with a keyboard attached. Sometimes I wonder if the people making decisions at Apple, Google, Microsoft etc. live on a completely different planet than me.
Yup, but you forget the famous "develop once, deploy everywhere" that will give the user "a consolidated experience". And allow you to make huge economy on the cost of development.
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...
To some degree yes but it has been great to be able to use iPhone/iPad apps on Apple Silicon.
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 hoped Apple would have had the design sense to keep them separate like they should be
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.
> I think Catalyst/SwiftUI were created as an answer to desktop applications moving to Electron.
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.
macOS has a small number of users compared to iOS. Many companies do make native iOS apps due to its large market share. If macOS can be targeted with the same API as iOS, it's more attractive for developers who are writing an iOS app to make a macOS build as well.
This has already happened for a small number of applications -- e.g. the macOS Twitter app is a port of the iOS app using the Catalyst framework.
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.