An Alerting Vista of macOS Sonoma | Hacker News Reader

An Alerting Vista of macOS Sonoma

furbo.org

208 pointschmaynard135 comments

As a function of a beta release, I would consider the possibility that the alerts are not fully intended for consumers, and that they might in fact be included in the beta only for the benefit of developers who are presumably testing with Sonoma to discover API calls that need updating in their own products. That might explain the inscrutable (to a non developer) wording, which may reflect a presumption that repeated messages are unnecessary for a developer with the tooling to bisect the code more efficiently.

I have learned never to assume that very obviously bad or broken behavior in Apple betas will go away by release.

That is fair, and I’m with you.

I gather from the thread that my comment above seems presumptuous, condescending, and mansplainy. I do think I overstated my thoughts. I only meant to say, “It looks to me like just a beta thing. Let’s hope it goes away.” It didn’t seem like the original article expressed that consideration (though it may well could have—I just missed it at the time), so I thought it might be a thought worth adding. But I over-composed the comment, and I hit the wrong tone.

This doesn’t seem like an issue worth sorting people by level of authority or experience over. I suspect we all care a great deal about quality work and quality user experience. The OP is right that these dialogs suck, and you’re correct that Apple has released things that suck, and this might be one of those things.

What each of us do in our own work is also not at issue. I’m in solidarity with those below who feel attacked. We shouldn’t have to have our credentials ready for inspection in order to post a worthwhile comment.

In any case, for all we know and in all likelihood, the person who committed the change that enabled these notifications could be here in this thread. We don’t have to like the change, but I doubt the person who made it is any of the things they’re implicitly being accused of being.

These alerts are useless for developers. They contain no detail as to what should be done and are non-actionable.

An alert is hardly the place to list detailed code warnings. I think the prompts are enough to have one open their app in Xcode and review the specific depreciation warnings.

They’re not. Pretty much every developer I’ve talked to has no idea what this warning means or what they should be doing in response to this. All of them are smart people who are longtime Mac developers. There are a bunch of ways to improve this: you could tell people to look in Console for logs, or name the deprecated API being used. What Apple did instead is they decided to shame apps by name but not tell them what they did wrong, and do so in a way that is quite broken because the warnings don’t even line up with deprecated API usage.

Looking at the Console is precisely what I thought of, at least coming from Windows, where I'd be looking at the Event Viewer to know more about such a message. Does the Console show more information?

Will have to check but I think I remember looking at the code to generate these and didn’t spot anything but the alert enabled by default.

Well, if you build your software the Apple way(TM) and use Xcode, just opening the project will show you all the deprecation warning. A C++ Xcode project I have at work has a lot of them, mainly for using old Frameworks like CoreServices, which do not have any modern C/C++ equivalent (they were replaced by Obj-C/Swift APIs) and which, while very old fashion/unsafe in their style, are most of the time way more worth to call for very short task like getting a path, rather then having to whip out a .mm and write some horrible Objective-C++.

However, if you’re not using Swift/Obj-C and have a different/custom build system, you’re probably toasted. Although, if you’re using CMake, you might have some luck in getting these info by generating an XCode project.

I would expect Xcode doesn’t have its own parser, but gets its warnings from the compiler. It, in turn, would get them from the header files.

If so, the problem wouldn’t be “not using Swift/Objective-C” or “have a different/custom custom build system”, but having a binary in your build that calls a deprecated API that the build does not build from source.

That’s the case if you use a third party library you don’t have source code for, or if you use an in-house ‘library’ project (Xcode would warn you if you compiled that, but possibly not when you use it in another project, so you wouldn’t get a direct clue “rebuild that library to see the issues”).

Couldn’t it be just a bug in the beta?

The author of the article is a Mac developer, as am I. The alerts are inscrutable to developers too.

Right, but developers aren't expected to use this to track down the issue.

I'm also a macOS developer - if I saw this I'd just turn on warnings in Xcode, wouldn't you?

The author seems to say something about using this red alert box to 'bisect' their app to figure out what's wrong? Really? Chances are if this is a deprecation issue, they may just get to the start of their app's history... There is plenty of tooling for this in Xcode and the build system. This is just a nag to remind people to use it.

Whether it's working right or not this is meant to nag on ATS and ATSUI which has been deprecated for 13 years.

> I'm also a macOS developer - if I saw this I'd just turn on warnings in Xcode, wouldn't you?

Almost everyone has deprecation warnings enabled. They're enabled by default. I occasionally use #pragma clang diagnostic ignored "-Wdeprecated-declarations" for small sections of code, but you can easily search for those. Do you seriously think that Craig Hockenberry, longtime Mac and iOS developer, is so ignorant and dumb as to not understand deprecation warnings in Xcode? Apparently you do, but if so, you're grossly mistaken.

> The author seems to say something about using this red alert box to 'bisect' their app to figure out what's wrong?

Yes, I'd guess what he means is deleting code in the app until the alert disappears, which would be impossible if the alert appears only once.

> Whether it's working right or not this is meant to nag on ATS and ATSUI which has been deprecated for 13 years.

As saagarjha said, that’s not what it is. https://news.ycombinator.com/item?id=36659491

> Yes, I'd guess what he means is deleting code in the app until the alert disappears, which would be impossible if the alert appears only once.

You really think that's a reasonable approach? Deleting parts of your app until it goes away?

I can't stress this enough this is not a developer tool, and it wouldn't be any more of a developer tool if it appeared every time.

> Do you seriously think that Craig Hockenberry, longtime Mac and iOS developer, is so ignorant and dumb as to not understand deprecation warnings in Xcode? Apparently you do, but if so, you're grossly mistaken.

Respectfully, I've been developing for macOS longer than you have, I started in 2002. Granted it was my first platform, and I wasn't exactly aged at the time. However, I make mistakes and come to silly conclusions all the time (as folks here are quick to point out), which is why I try to avoid appeals to authority whether for or against my position. My position should stand on its own merits.

People get mad about silly things all the time, I'm still mad about brushed metal and the unified toolbar.

> You really think that's a reasonable approach? Deleting parts of your app until it goes away?

Absolutely! It's an extremely common debugging technique when you have a mystery problem and need to determine the cause. You've never done that in 20 years of development?

Not in at least 10 years, no. I haven't had to, because tooling has come an awfully long way in the last 20 years. The idea that in this the year of our lord 2023 Apple would offer a tool where that was the prescribed approach is pretty nuts to me. I can't really imagine giving that advice to someone and being taken seriously except in the most ridiculous of situations. Pretty much just as a Hail Mary.

Without tooling you have no idea where you would even start cutting.

But hey, it sounds like you've got an approach that works for you.

> The idea that in this the year of our lord 2023 Apple would offer a tool where that was the prescribed approach is pretty nuts to me.

There is no "prescribed approach" here.

> except in the most ridiculous of situations.

This is a ridiculous situation.

> Pretty much just as a Hail Mary.

Of course it is. As I said, "when you have a mystery problem".

> Without tooling you have no idea where you would even start cutting.

I'm not sure what you mean by "Without tooling".

> I'm not sure what you mean by "Without tooling".

Well, I'd start with Xcode and static analysis. If that fails, Apple says this is triggered by ATS and ATSUI so I'd probably start with something like grep to see if I could track down a recursive dependency. [1] I wouldn't start deleting code at random from my codebase.

Given this is just a nuisance I'd then file a radar.

[1] https://medium.com/nuclei-technology-blog/how-to-check-your-...

> Apple says this is triggered by ATS and ATSUI

That's what Apple says but unfortunately it's not entirely true: https://news.ycombinator.com/item?id=36660932

> Given this is just a nuisance I'd then file a radar.

They're called Feedbacks now, and if you read to the end of the blog post, you'd see that Hockenberry did indeed file some. But filing a bug report isn't any kind of solution to a problem. Apple only fixes a small subset of all bug reports.

I strongly suspect Apple will either change the alerting behavior, or change the documentation around it. Either way is fine, IMO.

> They're called Feedbacks now.

Yeah, I'm not going to stop calling them radars lol.

> I strongly suspect Apple will either change the alerting behavior, or change the documentation around it.

Which is exactly the point of the submitted blog post: Apple needs to change this. But here in the commentary we have people talking down to the author and others, suggesting they're somehow ignorant and "not using the tools".

I've resorted to this level of debugging myself, but only in scripting type languages not requiring a recompile every time to test. I can only imagine the halving technique getting quite tiresome compiling each time. However, I could see this being a last option before taking off and nuking it from orbit option is chosen

What approach would you use for something like this, where it doesn’t tell you what the issue is? Apple sometimes shows alerts for exceptions for example which contain a stacktrace of where they came from, so I understand in that case if you have some options rather than going in blindly. Here there’s not actually much I see you can do?

>> Yes, I'd guess what he means is deleting code in the app until the alert disappears, which would be impossible if the alert appears only once.

> You really think that's a reasonable approach? Deleting parts of your app until it goes away?

When you send a feedback to Apple, they almost always ask for a minimal test case (Xcode project).

If you can guess what the problem is, you can just create a new Xcode project from scratch that triggers the error.

But often, when you do that, the new project doesn't fail in the same way your app does. Then you have to start with your app, and keep removing stuff until only the stuff that triggers the problem is left.

I want to point out also how unhelpful the release notes are. When I see ATS mentioned in Apple docs, I think of Apple Transport Security, not (I guess?) Apple Type Services, a font API dating back to Mac OS 8.5.

>As a function of a beta release, I would consider the possibility that the alerts are not fully intended for consumers

Read the message box copy, it’s consumer facing copy.

Developer facing message box wouldn’t be warning me about another developers deprecated api and telling me to contact them.

This is not a particularly new direction for Apple. I just bought a Mac Studio and set it up today. Latest and greatest non-beta (Ventura 13.4.1). I'm not even trying to do anything particularly adventurous, just install a basic suite of applications and get to the point where I can use my machine. I have been besieged by dialogs, popups, and notifications asking me to give a program access to a file or removable disk or my downloads folder, or "informing" me that a setting has been changed, or that something will run on startup, or most intrusively, in half a dozen cases, preventing a program from working until I open the security preferences and find the "Allow" button.

At one point, after rebooting my computer - a required step in the 10-minute process of updating the firmware for my fresh out of the box Apple monitor - I got a dialog that said "The application 1Password is not open anymore" (exactly like https://us.v-cdn.net/5020219/uploads/editor/w1/apqiiyi6lwer....). Clicking the help button opened the classic Apple help panel that grinds your computer to a halt and, in this case, displayed a blank white window. I spent a few seconds trying to puzzle this one out, ending on an Apple discussion forum (https://discussions.apple.com/thread/252590137) with the again-classic mode for those forums where derision and insults are provided in lieu of assistance.

I fell in love with the "it just works" and "an actually usable GUI plus Unix under the hood" and "they actually sweat the small stuff" aspects of the Mac experience that drew a lot of us to the platform in the early days of OS X. Over time, the shine has worn off and many patches have tarnished or even rusted through. The user-annoyance-factor difference between modern Windows and macOS is very slight.

> I have been besieged by dialogs, popups, and notifications asking me to give a program access to a file or removable disk or my downloads folder, or "informing" me that a setting has been changed, or that something will run on startup, or most intrusively, in half a dozen cases, preventing a program from working until I open the security preferences and find the "Allow" button.

I grant you, this experience sucks.

Was it better before, when everything had carte blanche to do what it liked without your knowledge/consent? (My intent isn't to lead the witness — I have my preference, but am curious what you think.)

Not OP but pretty much in the same boat.

> Was it better before, when everything had carte blanche to do what it liked without your knowledge/consent?

Yes.

The caveat is I'm using a very stable set of programs, that I spent a long time to decide if I was OK with giving access to a lot of my critical information. I'm using Karabiner since it exists, and it's a worse experience and performance as it is now than when it was running unprotected and full carte blanche. Same with Bitwarden, it already has all my life's passwords, giving it access to read my screen is just an additional annoyance.

At some point VSCode could also go rogue, but I'll be more worried with it leaking my SSH keys than recording my face when I'm coding.

The caveat is that you know what you're doing. Most people don't. Computers are made for most people. The era of computers being made for people like us, is long gone.

(We did this to ourselves, by constantly trying to make computers easier to use, and telling everyone else they should have one)

Yes, but … no.

> (We did this to ourselves, by constantly trying to make computers easier to use, and telling everyone else they should have one)

Agreed. However: most people never wanted a computer, they only wanted to do certain computer-y things.

And they don't have to anymore! We now have this new breed of wondrous, computer-y devices which are less capable, but in return are also a lot easier to use. It's here, it's absolutely ubiquitous and it is roughly good enough most of the time.

The worlds of "smart" devices and general computing machines could have, _should_ have coexisted perfectly next to each other. That Apple is slowly but surely merging the two is a massive, unnecessary, foolhardy mistake that is on them and them alone.

Thing is, these people already have better options.

Enterprise "businessy" people already have fully managed enterprise Windows, large education fleets and low computing needs organizations can be served by Chromebooks or iPads.

We're the ones stuck in a state where linux is still too compromised, Windows lacks polish, and now macos has iOS-ified to the point it becomes an hinderance but without getting the real advantages (touch support etc.).

I'm patientely waiting for a shift to happen, in the meantime jumping to Windows looks like the more pragmatic solution, how crazy it may sound.

I agree, in my eyes one of the major problem is that Apple does this at an insane markup. Sure the hardware is mostly nice but when you factor in the premium you pay for it there shouldn't be this kind of major hindrance to usage in the software. It's like if you were to buy a professional power tools but it would still have all the warnings message and "protections" found on consumer level tools with no real way to disable them without rendering the tool almost useless...

Sure you can disable many security stuff in macOS but then many of the apple stuff don't work, so you would need to leave on the table one major reason to buy Apple hardware.

In my opinion Apple painted itself in a corner with their strategy, they may have more money than ever and more customer than ever but they are making their offering so irrelevant to tech enthusiast people so quickly I'm not sure any of their tech will be relevant in ten years.

Of course Apple fanboys (omnipresent here) want to believe the contrary...

> The caveat is that you know what you're doing. Most people don't. Computers are made for most people.

While you're absolutely correct it's my impression that most people will grant any permission without reading just to make this popup interruption go away and move on with their task.

I think it's not bad for the average user, say my dad. Personally, I would like a 'developer' toggle to disable it all or have a different default.

Reboot into Recovery Mode, open the terminal, run:

  spctl --master-disable
  csrutil disable
  nvram boot-args="amfi_get_out_of_my_way=1"

and reboot into normal mode. Almost all of the "annoying" safety protections will be disabled.

[2008 me] fell in love with the "it just works" and "an actually usable GUI plus Unix under the hood" and "they actually sweat the small stuff" [...] [By 2018, say] The user-annoyance-factor difference between modern Windows and macOS is very slight.

Could not have said it better myself.

>The user-annoyance-factor difference between modern Windows and macOS is very slight.

You’re still wearing the rose-tinted glasses. MacOS is not able to (natively): 1. Allow the trackpad to scroll “natively” and a mouse to “normal” scroll. 2. Scale for an external display without a specific PPI. The PPI is so high there’s only a couple monitors that support it on the market. 3. Display crisp text on a non-high-PPI screen (as above). 4. Allow the user to edit or remove the horrendous mouse acceleration curve. 5. Allow users to select minimized windows with Alt+Tab. 6. Allow users to snap windows. 7. Etc etc.

I’m stunned I can’t scale stuff on my 4k monitor, adjust the mouse, or be productive with alt-tab.

Gorgeous hardware, but wow, I’m stunned you guys (and girls) can use this seriously.

On the other hand, I read that as a laundry list of “things to make it work exactly like Windows”. I’ve used a Mac for a lot of years now and none of those have ever bothered me.

I’m not saying you’re wrong for wanting them. I’m saying you’re wrong to assume that everyone else does, too.

ChromeOS, Android, Windows, and Linux have almost all features I mentioned. But, I understand some don’t care.

Having two separate scroll directions available for mouse and touchpad is just basic common sense, not "make it work exactly like Windows". Pretty sure every OS/DE out there allows for that, except for macOS which doesn't in a subpar manner too (there are two separate toggles in two menus, one for mouse, one for touchpad, and they toggle each other...).

>Scale for an external display without a specific PPI.

Be happy they still let you use non-Apple external monitors! :)

Ha! Hilarious you said that. I was planning on purchasing their display until I learned it’d take a decent effort to use it with my work laptop (windows). So, part way there?

Hell, you even need a custom third-party driver to use the multitouch trackpads on Windows. They are the best trackpads money can buy though, so I use one with my desktop.

cmd-tab is program, then cmd-` to cycle through the windows of that program.

4k monitors also scale fine?

I agree with most of your points, save for alt-tab. macOS app and window management is completely different from Windows, and trying to use it like Windows only ends up hurting.

Minimizing a window in macOS takes it out of the working set. You can't quick switch to a minimized window, and it doesn't even show on Mission Control. You have to click the minimized window in the dock to bring it back. In short, minimizing a window is not just a visibility setting, but a workflow choice.

Used to be something Vista was laughed at for. Oh, how the turn tables https://youtu.be/0eEG5LVXdKo?t=637

Things have improved a whole lot since then. Used to be that as soon as you opened any app, it just requested full admin access to everything. Now its that you try to share the screen and you get a popup asking if you want to allow sharing the screen.

It's actionable now. You can use an app without allowing the permission request, and the permission request is tied to when you try to use the function rather than at install time or app boot.

> or most intrusively, in half a dozen cases, preventing a program from working until I open the security preferences and find the "Allow" button.

You can ctrl+right click and then press Open to bypass this and just show a warning with an "Open" button on it, fyi. After you do it once, it won't bug you for the same application.

luckily the Windows experience is getting shittier too so we’re all stuck with macOS

> I have been besieged by dialogs, popups, and notifications asking me to give a program access to a file or removable disk or my downloads folder

This is not MacOS's problem. This is an industry-wide problem where users are besieged by rude software that treats the user like an idiot and decides to do as it pleases regarding system configuration. It is not an exaggeration that it is a security nightmare. With dark patterns becoming the norm, I am happy to have MacOS limit which programs can access which resource, even if it means setup takes longer.

The world you wistfully pine for, with well behaved software and operating systems that simply serve as a platform for programs, no longer exists.

Linux, BSDs, keep to software in the repos and you get that. Apple treats all software as hostile even the stuff it ships. Having to give the terminal access to see my Documents folder is nuts AND confusing.

Holy Shit this is bad news. I really hope Apple doesn't show this dialog for all deprecated APIs, because for a lot of them there just isn't an alternative.

Apple has a history of deprecating APIs, and then not shipping a suitable replacement, or shipping a broken replacement.

For example, the SecKeychainSetUserInteractionAllowed function, which disables password prompts when trying to fetch passwords from the keychain, has been deprecated for a few years. So I replaced it with the new method to disable UI. But the new method stopped working suddenly after a minor update! It just showed the UI anyway! This led to a bug where my app kept showing the dialog again and again.

The only fix was to revert back to the deprecated API, which still seems to work.

If Apple wants developers to stop using "deprecated" APIs, they need to start shipping replacement APIs that actually work.

I'm a bit less angry at apps asking me always for the goddamn password.

Yup, my main project relies on a bunch of deprecated APIs that have been deprecated for years with no viable alternative. Hoping for the best!

While I agree it's not terribly useful if it pops up whenever an app that uses a deprecated API starts (or something similar), I assume Sonoma is, right now, targeted at developers that will be happy if they learn about their usage of deprecated APIs before the OS is launched.

The alerts shown in the post are about Apple system services and do not name the deprecated API, so these alerts are useless.

And you think Apple has no use of warnings for themselves? The OS is as much a test version for developers as it is for Apple during the beta.

I don’t think Apple developers can do much with warnings like those, especially if they appeared when waking up from sleep.

These alerts are suspiciously useless. When I see something like that, I immediately try to think “who would they not be useless for?”. Obviously useless for end-users, similarly useless for the developers of the named app. But I can think of someone it wouldn’t be useless for: the MacOS developers working on a new method for detecting deprecations.

I imagine there’s a MacOS developer somewhere with a test harness on their local machine, it has a bunch of app stubs with names like “ThisAppShouldAlert” and “ThisAppShouldNotAlert”, and their new deprecation-detection method that they’ve been working on starts with “if DEBUG == 1”. (Maybe this developer is right now in a meeting with management, getting a grilling for using the DEBUG flag instead of the INTERNAL_DEBUG flag.)

Seems like a brilliant way to browbeat your developers into constantly updating all "legacy" API calls thereby ensuring they only work on the latest system, forcing your customers to always upgrade to the latest and greatest OS, meaning they'll be forced to buy new hardware continually to ensure compatibility with their favorite applications, and Apple ensures a continuous demand of selling clueless customers shiny new things.

Yep, considering recent Apple behavior it is very likely that this is actually the prime motivator for this happening. I'm pretty sure some manager got pushed to find how they could motivate peoples to upgrade/swap earlier and this is one method they came around.

Then Apple and their (power)users don't understand why big software company don't want to go through the trouble or porting to macOS their very large software. It's not just about market share...

I saw these a bunch in beta 2, and none at all in beta 3. I suspect it was a bug, and not a new feature.

Some popups were even for system services (a long no-space process with "blastdoor" in the name for iMessage, etc).

(fwiw, blastdoor is the XPC process used by iMessage to render the little rich previews. It is heavily sandboxed in case the contents are malicious)

9 days later--but yeah, that's why I'm pretty sure this is a spurious popup. There's no way Apple would show a popup with an internal service process name to a user.

It’s incredibly naive for this journalist to be reviewing beta software as if it’s a final product, let alone calling obviously unintended behavior as if it’s a new “feature”.

Adding another domain to my “news” block list.

The article author is not a journalist, he's a Mac developer. His bio is in the sidebar of the blog post.

Your sneering is incredibly misguided and ignorant.

That’s even worse as I’d expect a developer to know better.

Whatever you think he doesn't know, he actually does know.

The ignorant one here is you, and now you're doubling down on it, sadly.

And whatever you think I don’t know, I do know. See how this works?

In release versions of macOS, if you boot macOS in "verbose" mode (hold down the V key on keyboard when starting the computer), you get the text of the console messages scrolling on your screen, until the login manager starts.

Lots of "Deprecated API" messages from what appears to be kernel code.

I always thought these messages were an internal Apple QA thing: one team notifying another of the need to tweak something.

But alerts like the ones discussed in the article and the discussion here are terrible. Non-actionable messages should be invisible to the user. There's no point.

They are actionable.. con User will massively contact the lazy developer who will either want to fix it or stop publishing old software

Software people are so presumptuous. Imagine at random times when you flip a light switch the power company flashes you an error about a complaint leveled at another company. It's frankly not the user's business what happens between apple and 3rd party developers. I think we need to step back and realize the world doesn't revolve around us.

These alerts have a big "debug tool semi-accidentally left turned on" vibe. I wouldn't be surprised if they disappeared in a subsequent beta, with no comment.

This is 100% the case and I’m getting quite a laugh out of all the “top minds of HN” lambasting Apple for something that’s obviously not intended.

Is this localized? That’s my test on if this might be a feature. Does it say that in other languages?

I wonder if Apple will use this to annoy people who are still happily using the (admittedly old versions of) OpenGL, which has been deprecated for awhile but still working for people who want simple cross-platform graphics.

10 years ago (WWDC 2013), Apple clearly understood that Security UI does not work and was able to express why to avoid it if possible. What happened to them? https://i.imgur.com/qbUy5aH.png

Security dialogs aren't guaranteed to help fatigued users, but they are extremely useful in preventing silent attacks.

The big risk is that some rogue app silently steals your data. If there is no dialog, nobody would realize.

If there is a dialog, the chance is higher that people will realise that the app steals your data, and write blog posts and articles about it, making it known that some app steals your data.

I for one am very happy about eg. clipboard notifications in iOS. I don't want random utility apps logging my clipboard, and without notifications I would have no way to know about them.

Anything that isn't relevant to making more money and selling scaremongering security "features" to rich boomer is none of Apple's business nowadays.

Apple has lost it with the "interruptive" notifications. Steve Jobs used to make fun of Vista's UAC.

This also includes your battery is less than 10%

Apples alert mechanism is a disaster, anyway. I've lost so much work because some notification appeared on my iOS device, which subsequently gets lost in the annals of time because there doesn't seem to be any way to go through all the notifications ever received, to find the one that was robo-swiped away ..

And then there's MacOS, where I can never be sure where to go to find these same notifications.

The whole issue of user dialog on MacOS and iOS needs a serious review. Jobs' would never have let this mess happen under his watch ..

Shocking how terrible the wording is in these, even for a beta release. 'Alert "GeoServices"' isn't even a sentence. Feels like something implemented at the last second.

This is a private beta of MacOS before the public beta is ready. It's probably just a debug popup someone stuck in and will pull out before release.

Built my first Mac app in a while this month, electron based because it does the job.

Really unsettling to me that something running fine all working good I upload it to my web space and download it again and now launching the app says “this app is damaged, contact the developer” and the only option is “move to bin” or cancel.

Now I understand the gatekeeper system well enough at least I thought I did that I was expecting to have to right click open which is pretty standard in Mac land now. But it took me some digging that this “broken” message is just about signing nothing else, the app isn’t broken at all it’s just not been signed.

I understand the reasons gatekeeper exists and I agree with them mostly but changing this messaging from “unidentified developer” to “broken” feels like an aggression against being able to build software without paying the $99 toll gate.

I eventually found a way around it after 3 hours to get the old style “unidentified developer” message without paying Apple. But there was so little info around in half considering making a tutorial explaining it.

But yeah my point mostly is Apple trying to force the hands of developers by escalating warning messages is very worrying to me. None of this was needed from OS X 10.0 to 10.10 not sure why the aggression is needed now, because the Mac App Store is a failure you need to force the hands?

Not saying these are good, but I imagine opening Console and looking at the error logs may shed some light on what is happening here.

Looks like everyone enjoys guessing things in non-retail releases, so I'll join in on the fun: my guess it's the same type of deprecation warning you'd normally only get in the system log, but now you get a popup as well. Maybe to nudge developers to not lean on deprecated APIs, maybe for something else we don't know about yet.

I always wait 6 months before upgrading to a new MacOS versions - the best thing about MacOS is being able to get on with work without having to mess with the operating system!

This version of MacOS isn't even released. It's not even in their "public beta", its a private beta intended for developers to get the earliest possible test env for updating their software.

The fact something weird happened on a private beta is not at all surprising.

Has anyone checked the syslog to see if there are parallel references there? Are would have assumed hockenberry would have done so, but he didn't mention it.

How dare a non-public early beta build be unfinished and rough around the edges

This is Apple coercing developers to donate development time and research to track the latest Apple changes by scaring their customers.

They did the same thing with unsigned apps (the confirm dialog mentions malware).

It’s worse now the dialog just says it’s “broken” and right click open no longer works.

You have to sign it with a self made signature to upgrade from “broken” to “might be malware”

echoing the its a beta comments: it’s a developer beta, what do you expect? And because it is a dev beta, this is technically under an NDA?

Discussing beta versions of macOS is allowed under the developer program NDA.

How will problems with the beta be solved if we can’t talk about the beta.

These alerts are so hurtful and useless that are actually very effective an amazing. These will push developers to be on top of their game and avoid having mediocre apps with deprecated APIs.

macOS finally has its version of “This application has performed an illegal operation and will be shut down”

"There’s a new “feature” in Sonoma, and no one besides Apple is quite sure what it is."

No worries, I am pretty sure what it is. It is an error code to notify the user (or more likely a developer testing their software with the beta for the updated OS, as that is who/what the beta is intended for) that there is still a deprecated API used. Apple used the following slogan in the updated notes: "Update your apps to use new features, and test your apps against API changes."

This was introduced in MacOS 14 beta 3: "Starting macOS 14 Sonoma, whenever the OS detects the usage of ATS or ATSUI APIs, the user will be presented a dialog stating that the application needs to be updated. Once the dialog is dismissed by the user, the application will exit. (100521621)" - https://developer.apple.com/documentation/macos-release-note...

That’s not what it is.

Ironic seeing such an aggressively unhelpful comment in this particular thread. Would it have killed you to include any detail at all, or an alternative explanation for the alerts?

Thought I had mentioned it in another comment, turns out that it was elsewhere on the internet.

https://twitter.com/_saagarjha/status/1672855750862073856

https://federated.saagarjha.com/notice/AXWrYlVPrEjHCXucaW

Reply on news.ycombinator.com