> 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.

> 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".

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.