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 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.
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”).
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?
If the deprecated API is used by a library you're using and not compiling within Xcode (for example, IIRC the Facebook SDK), you're SOL.
Also, it appears not _all_ deprecated APIs are causing these alerts, making matters worse. If you are using several deprecated APIs but aren't sure which ones absolutely need fixing, it would be quite tedious -- especially because the error only appears once per app.
And all of this is very easily improved with more diagnostics as the article suggests.
You can also trivially suppress deprecation warnings with clang flags or pragmas, so even with Xcode there may not be a logged warning, because someone already decided "yes, I know this is deprecated, but there is no alternative, so we'll have cleaner build output thank you".
Don’t have to get so personal, I do not know saagarjha nor do I know of his various achievements writing software, and as a matter of fact, you do not know me either.
I speak purely off experience, writing/porting software for macOS for more than 4 years, most of the time using Xcode.
"Nonsense" was a very dismissive reply. What saagarjha said is not only sensical, it's true. And you were presuming to explain Xcode to people who know Xcode intimately.
> I speak purely off experience, writing/porting software for macOS for more than 4 years, most of the time using Xcode.
And I've been a professional Mac developer for 17 years.
It appears that you created your HN account less than an hour ago, for the purpose of talking down to someone who actually knows more than you do. I find this very sad.
I mean yes, but that's because Saagar _is_ an authority. He's worked at at least one company that requires far greater amounts of knowledge and understand of Xcode, macOS, iOS, etc than the overwhelming majority of Mac+iOS devs.[1]
This is a case where an "appeal to authority" is reasonable - CyclOp posted an opinion, that claimed Saagar was incorrect, but provided no supporting evidence for the claim, e.g. they have at best appealed to cynicism, or more realistically themselves as the 'authority'.
Now if CyclOp had presented actual support for their claim, or the erroneousness of Saagar's comment just responding with "Saagar knows more than you" would be BS, but that isn't what happened here.
In honesty, I'd also consider lapcat an authority on Mac and iOS dev as well.
Authorities can also miss the obvious like the rest of us. So still needs a proper argument (even if it's just "No, it's not shown in XCode, go check and you'll agree").
I wasn't trying to make an argument. I'm just really tired of clueless mansplaining internet randos talking down to experts, as if they'd never heard of Xcode build warnings, which is absurd and insulting.
It took me some time to track down the reference, but here's your argument:
> No, it’s not; the alert is the result of calling legacy CoreGraphics APIs rather than ScreenCaptureKit. Of course the fact that I had to learn this by reverse engineering replayd and locating “coreGraphicsCaptureAPINotificiationEnabled” (sic) is part of the problem. https://twitter.com/_saagarjha/status/1672855750862073856
(Unfortunately, one can no longer see the entire thread if logged out from Twitter, due to recently imposed restrictions.)
> I'm just really tired of clueless mansplaining internet randos talking down to experts
The vast majority of people on here don't have a figment of an idea of who you are, let alone your gender. If anything, they probably assumed you were a man and were just being armchair arrogant/pretentious. So your base qualification for your complaint ("being mansplained to") is instantly nullified.
As far as your qualifications go, you're as equally anonymous and qualified/unqualified as the other poster is. So get your panties/knickers/boxers/briefs/whatever out of a twist.
> The vast majority of people on here don't have a figment of an idea of who you are, let alone your gender. If anything, they probably assumed you were a man and were just being armchair arrogant/pretentious. So your base qualification for your complaint ("being mansplained to") is instantly nullified.
It's not about me. I was upset about the careless disrespect in these comments to saagarjha and to the article author Craig Hockenberry. Cycl0p created a HN account yesterday for the sole purpose of replying, incorrectly and dismissively, to saagarjha: https://news.ycombinator.com/user?id=Cycl0p
I'm not a big fan of the term "mansplaining" either, but it's the most recognizable one for something like this phenomenon. I once coined the gender-neutral term "downspouting", but nobody knows it. If there's a better word, I'd be happy to use it.
My own qualifications are largely irrelevant here. All I said was, "I can guarantee that saagarjha knows more than you about Apple development", a guarantee that I think has now has been demonstrated by subsequent comments.
> I'm not a big fan of the term "mansplaining" either, but it's the most recognizable one for something like this phenomenon. I once coined the gender-neutral term "downspouting", but nobody knows it. If there's a better word, I'd be happy to use it.
> If you don't recognize lapcat, you haven't been reading a lot of macOS articles on HN.
I read plenty of macOS articles here. I'm sure I've run across them. They're neither memorable enough nor important enough for me to pick them out from one user or another. And for them to assume that importance would make them far more arrogant to me (and many others) than the "mansplainer" (no matter if they're in the wrong, which I happened to agree that they were).
> Also, "mansplaining" probably just meant "giving unwanted advise about a topic they only have superficial knowledge of".
I could pick up the context of their intention. It's still extremely odd to use a politically and emotionally overloaded word with a specific meaning that clearly doesn't apply here. OP could be a woman themselves, for all we know. The explainer wasn't talking down to lapcat out of an assumed lack of knowledge based on their gender; they were just talking with a general lack of knowledge on the subject, which is pretty common on the internet.
>If you don't recognize lapcat, you haven't been reading a lot of macOS articles on HN
I, for one, barely recognize 5-10 names. I focus on the content, and don't keep the names in my mind after reading something or even after having a chat, unless they make some unique impression, or have a consistent theme and style to be recognizable.
>I wasn't trying to make an argument. I'm just really tired of clueless mansplaining internet randos talking down to experts, as if they'd never heard of Xcode build warnings, which is absurd and insulting.
There are people who don't know who an account handle they reply to is, or their expert status and history, in order to show the appropriate reverence. Some wont even recognize the initials "pg" they might be replying to.
There's this saying "A billion chinese don't know who you are and don't give a shit". The same if often true of the mere tens of thousands of HN users.
I think the solution is to assume that everyone is an expert, and try to understand why they said something, and ask for clarification, instead of telling them they are wrong.
> I'm just really tired of clueless mansplaining internet randos talking down to experts, as if they'd never heard of Xcode build warnings, which is absurd and insulting.
This is an unreasonable position to take on a forum where there are absolutely zero clues about the competence of the person in the thread. You may know who saagarjha (and lapcat) are, but there is absolutely nothing in any of your messages, or theirs, to indicate that they are professional Apple devs with decades of experience.
If HN had flair, we might have a chance. But as it stands we have to contend with the fact that each and every HN contributor has to be treated as incompetent developers until they demonstrate otherwise...
And it is incompetent developers - at Apple - that gave us this nonsense notification system in the first place.
> This is an unreasonable position to take on a forum where there are absolutely zero clues about the competence of the person in the thread.
> each and every HN contributor has to be treated as incompetent developers until they demonstrate otherwise
It's absolutely not unreasonable. On the contrary, the HN guidelines state "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize." https://news.ycombinator.com/newsguidelines.html
(I realize that I've violated the guidelines here in my response to other guideline violations, which I'm not supposed to do, and I'll take my "punishment", whatever that happens to be.)
> And it is incompetent developers - at Apple - that gave us this nonsense notification system in the first place.
I'm inclined to think that it was more of a bureaucratic mess. There are tight timelines, lack of coordination among different teams, underspecified or conflicting requirements, etc.
>It's absolutely not unreasonable. On the contrary, the HN guidelines state "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize."
How does that fit with accusing the other person of "mainsplaining", of purposefully disrespecting an "authority" (sic), assuming they would have known who the other person is and it's only because of their audacity they responded as if they might have possibly missed something basic, and so on?
> How does that fit with accusing the other person of "mansplaining"
It doesn't, as I said in the very comment you're replying to: "I realize that I've violated the guidelines here in my response to other guideline violations".
> assuming they would have known who the other person
That wasn't my assumption. Although one ought to know who the submitted article author is, as that information is easy to obtain directly from the article.
> they responded as if they might have possibly missed something basic
That's the problematic part. We're not required to know who the HN commenters are, but we are required by the HN guidelines to treat them with respect and respond to the most charitable interpretation of their words.
My complaint isn't "You don't know saagarjha". Rather, my complaint is "You're assuming that saagarjha is an incompetent idiot, but saagarjha just so happens to be extremely competent and knowledgeable."
We disagree, but that's our individual prerogative. I don't contend with the idea that one must kowtow to authorities on the basis of a single message thread - you only know of the competencies of saagarjha by stint of having interacted with them for years - it is entirely unreasonable to require others to have that same understanding, when literally nothing in this forum promotes any means by which to gain that understanding other than to follow individuals for years.
If ssagarjha had prefaced their statements with "I'm an XXX dev with YYY years of experience on this subject, and my conclusion is .." then you'd have a point. But there was no such introduction - and thus it is absolutely unreasonable to expect other contributors to the thread to understand the prowess of the person whose opinions they are challenging.
>"punishment"
.. seems to be limited to having to deal with other, random strangers on the Internet, and whose competence you are yet to divulge from limited interactions...
> bureaucratic mess
All developer incompetence is bureaucratic mess, there is no other form of it. We are bureaucrats, not artists. Not even Apple can escape this fact, as we can see time and again with their low-effort, poor quality releases lately ..
> .. seems to be limited to having to deal with other, random strangers on the Internet, and whose competence you are yet to divulge from limited interactions...
HN does have moderators.
> Not even Apple can escape this fact, as we can see time and again with their low-effort, poor quality releases lately
I blame upper management for that, i.e., Federighi and Cook.
I mean that it is entirely our prerogative to disagree on whether one should recognize an expert, immediately upon engaging with them. There's nothing in the HN guidelines that indicate otherwise - unless your point is that one should have respect for the potential experience of everyone one encounters on HN, which is fair.
But I still contend that your position that we should all know saagarjhas' competence is entirely unreasonable. There are tens of thousands of such individuals here on HN, how are we supposed to know we're talking to the very founders of the technology we're discussing? Its unreasonable, but its your prerogative to make the statement, "don't argue with saagarjha, he's an expert", and its just as viable to see this is a "call to authority fallacy" designed to shut down honest, viable - and valuable - dialog that results from the challenge to this so-called authority.
In other words I don't think you're applying the HN guideliness effectively. Please let people challenge experts - its important to our community, after all.
>Federighi and Cook.
Never accept technical management from someone who can't do your job. This is Peter Principle, 101. Someone at Apple is dropping a lot of balls lately, and it shows in the very poor quality of their releases over the last few years. The notification system is entirely dysfunctional, on both iOS and MacOS - I would wager the bureaucrats don't actually use these tools.
Meanwhile, why and how would they know who "saagarjha"is and whether they're an expert? Are they supposed to be famous, I mean Carmack or Lattner famous no "they are known in some circles".
Even if they visit their blog, they can just see: "Hi, I'm Saagar Jha. I'm a software engineer from Cupertino, California, but I spend an inordinate amount of time in the southern part of the state" and a list of smaller projects and experiments.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it a lot lately. It's not what this site is for, and destroys what it is for, so we eventually have to ban such accounts.
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.
> 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?
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
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.
> 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.
> 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.
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".
>> 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.
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?
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.
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.)
> 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)
> (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.
> 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.
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...
> 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.
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.
>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.
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...).
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.
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.
[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.
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.
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.
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...
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”.
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.
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.
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.
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.
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?
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.
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.
"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...
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?
