VerifiedReports

I think these pale in comparison to the deliberate and brainless design regression that has unfortunately continued with this latest release.

"Liquid Glass" was unmitigated garbage from day one, but now look at the "tabs" in Safari. They're even worse; the selected tab is barely discernible. Why the mania for obscuring WTF you're looking at? It's never-ending.

There are anti-user degradations tucked away throughout the system. Another example, from the last OS: Mail now lacks a "get new mail" button. Apple DELETED that from the toolbar. WHY?

So now, when my mom is trying to log in somewhere and it says "check your E-mail for a confirmation code" or something, she can't just go to Mail and press the "get mail" button. It's just so gallingly stupid.

Ah OK.

There are chatrooms again?

That's a lot of assumptions.

"You probably aren't cutting features or television or multicam"

You think THOSE are the target audience of the Cut page? That's not what the marketing has stated.

It's not about the target audience; it's about the target use case. I've tried using the Cut page for quick-&-dirty edits, and it still sucks.

As a Chicagoan... quite often. So many things were introduced there, it's not hard to find a reference with some regularity.

It's disappointing that the two promised movies around the events of Devil in the White City still have not come to pass. One was supposed to feature Tom Cruise in the role of Holmes, and the other Leonardo diCaprio.

People love to tell stories about how stuff is done at Apple, which are often utter bullshit.

Not to mention that Apple has a huge number of teams, and no absolute standards across them. People would be shocked at the things Apple DOESN'T do.

Then again, with the current state of their QA, I think it's becoming clear what Apple doesn't do much of anymore.

The fraud of Android just gets worse.

The great "open-source" OS that was supposed to free us all from vendor and telco tyranny has... not.

Resolve is not any harder to use than any other NLE.

Although... BMD has actually made it harder, by adding bloat like the Cut page. I have attempted to find value in it a couple of times, and didn't. Now I disable it.

BMD needs to stop throwing crap into Resolve and buckle down and do two things:

1. Fix bugs, including UI defects. The Deliver page is a mess. The clip selection between the Edit timeline and the Fusion page makes no sense. And lots more.

2. Unify the node views. Resolve is a bunch of stuff BMD bought and threw together on different pages. The "integration" is janky and can, especially for the beginner, seriously degrade your work. Once example is how Fusion compositions inexplicably downgrade everything to timeline resolution. So you can bring 4K footage into a Fusion comp, but if your output timeline of the moment happens to be merely HD, the entire composition (including keys) will be degraded to work at that resolution. I mean... really? And beyond that, the relationship between Fusion comps and the timeline events they wind up in is extremely fragile and breaks arbitrarily and unrecoverably all the time.

A single nodeview for all operations would be a long-overdue game-changer for editing software.

Clearly the penalties for this are not high enough, because the scumbags keep doing it.

Vizio TVs were caught taking screen grabs and phoning those home years ago.

I grew up with Atari computers. I liked digital joysticks and hated the analog sticks Apple computers used. So I decided to spread the gospel to my Apple-owning friend. Yes, only one; the rest of us had Ataris.

So I borrowed said friend's analog joystick and measured the resistance between its extreme deflections, took apart an Atari joystick and then soldered resistors into its circuits to simulate full deflection... then got some multi-conductor wire and laboriously soldered it to the tiny pins on a DIP connector, which was what Apple computers used for joysticks. I don't remember if I had to figure out the pinout or found it in the Apple manual.

This all worked, but the connector was too fussy and fragile to be practical. Funny how much stuff you could learn in a reasonable time with no Internet, no car, no access to an electronics clearinghouse like Mouser...

I must have gotten all of it from Radio Shack on my bike. I wrote the whole procedure up and submitted it to Compute! magazine, but I don't remember what their response was. They probably concluded that not enough people hated analog joysticks enough to go through all that trouble.

Thanks, but I did read all the doc on this several times. Looking at it again, it reminds me of the fundamental problem conveyed that page: It assumes that you're using a different datatype for every view, and can thus set up NavigationDestinations for them.

But what if you're walking the user through several steps of acting upon the same datatype? Building some kind of message, for example. First add a recipient to the message. Then create and add some content to the message. Then choose delivery options for it. In each case I'm handing the Message object to the view.

Every avenue for using this thing seemed to be crippled by some blundering assumption. Until someone came up with making a special enum for every page, which is just another piece of hokey gymnastics and extra work to "trick" the UI into doing what you want.

Thanks. I was referring to NavigationPath. I do have it working with a bunch of custom enums. It took a while for that solution to come along; I just remember looking at NavigationPath initially and thinking it solved the whole problem, but being disappointed about its bizarrely limited design.

Thanks for your observations. I don't think I've looked at NavigationStack changes since iOS 17, so I will catch up on it. But I do have NavigationPath working well enough with an enum type for each screen, which is admittedly better than the absurd endless binding of "isDisplayed" flags all the way through the stack of views.

And I will have another look at @Environment; I guess I'm thinking of @EnvironmentObject, which is a hack that I'd never choose over a singleton. My only current exposure to @Environment is as a workaround to other missing functions or properties, like this on a custom button:

@Environment(\.isEnabled) private var isEnabled

Or to allow a view to dismiss itself:

@Environment(\.dismiss) private var dismiss

"@environment is super cool"

Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design.

I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more.

SwiftUI turned development, which I used to enjoy and feel good about, into a tedious trudge. I read everything I could, did the Stanford class, adopted "best practices," and really made an effort to do it right. It blows.

Unless your app is a trivial master/detail data-viewing app (as pretty much every SwiftUI example is), you wind up thrashing and performing all kinds of state-tweaking gymnastics to herd your application along through whatever tasks the user is supposed to be doing. Heaven forbid you need to walk the user through a series of steps to do or create something.

It's going to be a testing nightmare, and it suffers from every bit as much opportunity for data to get out of sync between the model and the UI as "traditional" app structure. Apple touts the "single source of truth" as gospel in SwiftUI, but you can't have that. First of all, Swift's official position is that you should "prefer structs" over classes. But (and this is one of Swift's hokier characteristics) structs are passed by value (copied) instead of by reference. So your "single source of truth" is broken after the first function call; your data are copied all over the place.

But there's another problem with the single-source mantra: You can't just expose your core model to the UI for direct manipulation, so you have an intermediary (the so-called "viewmodel"). But that intermediary must have temporary data structures to shadow those in the core model, so the UI isn't messing directly with the model, and the user can cancel or fail when changing things without messing up the integrity of the model.

So now, once again, you don't have a "single source of truth."

The problem isn't understanding the paradigm; it's making it do useful work. Some people love to mock OO for its early and obviously cumbersome and pointless idioms, which were quickly abandoned by experienced programmers. What remains of OO is still quite useful. I predict the same for... whatever the this mess is called. You waste so much time trying to follow the gospel of "MVVM" for no actual benefit. As I went through it, re-reading and re-digesting various pundits' viewpoints... I realized that I just had to start from scratch and build something that pays off instead of a bunch of useless ceremony.

I switched everything to classes, built managers (controllers) for the big categories of data and tasks I need to organize, and inject whatever objects I need into each view.

As for the rest of SwiftUI, its state is disgraceful. It excels at scaling UI for different screen resolutions; something that Apple neglected for waayyyyy toooo long. But there was no excuse for Apple to release a UI framework that basically didn't support the most fundamental UI paradigm of phone applications: a stack of progressive views that are programmatically manageable.

How many half-assed attempts has Apple trotted out, to do what UIKit does with ease? The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype. Look at the examples for this thing: They're applications that present a stack of views that each show... an INTEGER. In decades, I have never written an application that needed to stack up a pile of views that all show the same datatype.

And yes, I know the workaround for this where you create your own struct datatype and then fill it with enums, one for each view. But come on; the fact that Apple even rolled out this ludicrous design tells you that the talented architects have left the building.

Exactly, you've nailed it.

Yes, I disagree that the cited behavior is defective. But I respect his pointing-out of the shortcomings and offering other options.

I find myself using the clipboard-erasure "defect" somewhat frequently to cut something to the clipboard, and then undoing the change and using the clipboard contents. And this is specifically useful in a way that merely copying isn't... but at the moment I can't remember why, or whether I use this when programming or working around InDesign's many defects.

I don't think you're replying to the right comment, since I didn't mention anything working.

Vast majority of what?

So?

That makes no grammatical sense.

Whatever "CSAM" is...

And with such poor value for the money. When an Arduino costs as much as a Raspberry Pi 4, it's eliminated from contention.

Virtue signal received.

And Kaiser already sucks big-time, so... that's not good.

"Old" people? How about the vast majority of the public, which is not represented on HN?

Not to mention that one of the many major UI regressions in Windows is the removal of title bars from application windows, which is fundamental to this "trick." Try opening a PDF in Edge and also in Acrobat. Neither window has a title bar, and they are otherwise almost identical. You have to scrutinize the very few controls around the window to determine which app you're looking at.

Microsoft and its software are trash now.

Thanks for the reply. I don't understand what a TypeScript version bump has to do with import statements, though.

Why would someone downvote this perfectly relevant question?

Pathetic.

Exactly. The distinction between the various layers in "AI" systems is pretty vague to the newcomer. What is the "model" vs. the engine "running" it vs. weights?

I don't recall any previous tech stack that was barfed onto the scene with so little background or reference material, going from zero to endless undefined jargon... and no primer in sight.

For people who demand an understanding of their tools, it's a lot of work. I recognize the value of "AI" in performing the tasks I'd have to do manually; for example, keeping the data structures of my front- and back-ends in sync in a project. But do I want to interrupt my development and take weeks off to digest all of these tools?

And if I do, I want to run the show and fully understand it. And like you, I think that's best done locally.

If this is the previously-discussed one, the difference here is that it's not ribbing so it's not directional.

The disturbing thing is that anyone was surprised by this. GPS is very fragile.

This made news in the U.S. a few years ago because Ajit Pai had the brilliant idea to allow so-called "5G" telecom service on frequencies too close to those of GPS. I don't think this case is resolved yet: https://physicstoday.aip.org/news/new-5g-exemption-may-jam-g...