Thanks, it's interesting to know a little bit more about EtreCheck. You're certainly right about the percentage of people using old systems. However in my sector of activity is something relatively current to keep an outdated system to ensure maximum compatibility with a collection of (expensive) plugins. It's why this app, which is distributed on the App Store, is compatible with macOS 10.11 and later, and also why I was developing on Catalina, and now on Monterey and Xcode13 (the last systems supporting this deployment target). I admit that this almost archeology now :-), I probably will change that soon. Note that it's perfectly possible to upload to the App Store from Monterey, or even Catalina. On the other hand, Test Flight runs only on recent systems, but on the server side it's as the App Store. You probably seen that I finally found and fix a stupid permission error: there were too many changes at the same time in my setup and that makes me confusing. Anyway, thanks for your help!

Related to my last question, I forgot the key: kAudioUnitConfigurationInfo_AvailableArchitectures that is present in the audio component's ConfigurationInfo dictionary. I'm not 100% sure, but it seems that the plugins built with a Universal architecture fill this array with [x86_64, arm64] while the x86 plugins leave it empty. If confirmed, it could be a way to infer that they run under Rosetta.

Obviously, my first option is meaningless: the plugin cannot run under Rosetta in the main process if the main process itself is not running under Rosetta... Therefore, my only fallback solution is to find the plugin architecture, warn the user when he tries to open a plugin requiring Rosetta, suggesting him to update the plugin or, as a last resort, to run the app under Rosetta. Finally, it's worth noting that auval itself fails to validate any of these Intel plugins. This seems to confirm that the AUv2 API is no longer supported on Silicon Mac. But it would be very helpful to have an expert opinion on this point.

Thanks for your answer. Yes I'm subclassing NSWindow: the method -setFrame:display: reproduced above is one of the NSWindow methods specialized by this subclass. But, apart of that, the subclass doesn't interfere with the layout system in no way. You're right about new macOS versions, I definitely intend to test macOS 26 before publishing a new version of the app (I'm developing on Xcode16 because my deployment target is macOS 10.13).

When the error is printed (at launch time) the method simply called super. Moreover, if I disable the specialized methods, the error is still there. But the interesting point is that the breakpoint then gives me this backtrace: 0 _NSDetectedLayoutRecursion 53 NSApplicationMain 54 main It seems to indicate that the error is not related to my codes, at least directly. I suppose it could also be related to some conflicted constraints in my XIB files but, in that case, don't you think the error should have been detected by Interface Builder? Moreover, how could it be related to a layout recursion otherwise than from my codes? On the other hand, I tested the app and it works without problem on macOS 26, so I don't think I will waste more time on this issue for now. But anyway, thanks for your help!

No, I don't use NSStatusBarButton in my codes, sorry. More generally, since I run Xcode on macOS 15, the number of such messages has become incredibly high... many of those logs have clearly nothing to do with what is under my control (the worse being when using UBSan and friends). This ultimately lead me to the deactivation of all logs (os_activity_mode=disable), but after that I couldn't even see some of my own logs anymore... I finally started using printf as a work around, but if someone knows a good solution to disable all system logs while keeping my own, I'm interested, thanks!

Hi Quinn, thanks for the reply, that's very interesting. Practically, I have to type the name of each library generating my logs: typing the Process name doesn't seem to log anything (although the system proposes it to me). On the other side, if I type the PID, then I get all system logs again. Even for the app's main module, I have to enter a Library name of this form: myApp.debug.dylib. But apart of that, it works very well: I can event retrieve my printf statements by adding stdio in the filter. The only issue is that such a composite filter is a little bit tricky to enter. I thought that it was possible to reuse it through the "Recents" section of the filter menu. But, after giving a try, it appears that this section is cleared on each Xcode launch... that's too bad. It would be very useful to have a way to store frequent filters some way, or maybe to active one from the Scheme (e.g. as it can be done for the OS_ACTIVITY_MODE). Anyway, your post was very helpful, thanks again!