Hacker News Reader

Comment by jmbwell | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com