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!