Mouse hover events cause warnings in the console when running an iOS Audio Unit on an M1 Mac

Question

Created Apr ’22

Replies 5

Boosts 0

Views 1.9k

Participants 4

Hi, When debugging an iOS AUv3 extension in GarageBand (or in other host apps) on Mac OS Monterey running on an M1 Mac, there is a large number of warnings that read:

WARNING: SPI usage of '-[UINSWindow uiWindows]' is being shimmed. This will break in the future. Please file a radar requesting API for what you are trying to do.

I noticed that immediately after such a warning, the view's hitTest is called with a UIHoverEvent, and indeed moving the mouse results in more log spam. Although the very first occurrence of the warning may have a different root cause. Using a symbolic breakpoint wasn't helpful in revealing further information.

Note that I'm launching the AUv3 extension in the "Designed for iPad" mode. Project language is Objective-C. I was able to reproduce the issue with even an empty project, adding nothing beyond Xcode's built-in appex template for iOS Audio Units.

The issue doesn't seem to happen with the Apple sample code "CreatingCustomAudioEffects", which is a swift project. I also compared and matched storyboard settings between that project and my own, but to no avail.

Any pointers would be highly appreciated. Thanks.

Boost

Answer 1

pianonik OP

Feb ’23

I am having the same problem -

0

Answer 2

DTS Engineer OP

Apple

Feb ’23

I am having the same problem

Is this causing a problem other than the log message? If not, I’d treat this as log noise.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

anydev OP

Mar ’23

Is this annoying problem solved yet, Apple ??? Any AudioUnit version 3with an user interface in SWIFT will actually endlessly produce this kind of none-descriptive logging junk.

0

Answer 4

anydev OP

Mar ’23

THis is what Apples says... It is an internaly thing, we cannot do anything about that.

UIWindow + NSWindow = UINSWindow If you’ve done some iOS development, you’re familiar with UIWindow. On iOS, these generally do not represent anything UI-related and are used to separate different view hierarchies. NSWindow is a similar concept that has existed on the Mac since the beginning. Windows are native to the Mac and are a much more natural abstraction there, compared to iOS.

To bridge UIWindow to NSWindow when using Mac Catalyst and allow you to present your scenes as familiar Mac windows, Apple created a different class — called UINSWindow — that is used for Catalyst only. This is a private class, so you cannot use it directly — and even if you try, your app will get rejected by the App Store Review. A UINSWindow instance conveniently inherits from NSWindow, so it supports all the functionality that a standard AppKit window supports. This suggests that there is a possibility to somehow mix the UIKit and the AppKit layers together in one view hierarchy.

0

Answer 5

DTS Engineer OP

Apple

Mar ’23

This is what Apples says

Where did we say that? In your bug report?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0