# Objc warnings at exit since catalina switch

**URL:** <https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712>\
**Category:** General JUCE discussion\
**Created:** [July 14, 2020, 6:56am UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712 "2020-07-14T06:56:13Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [July 14, 2020, 6:56am UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/1 "2020-07-14T06:56:13Z")

</div>

All my juce apps with juce6 now print this at exit:

```
objc[42970]: objc_disposeClassPair: class 'JUCEWindow_7654d7c572cb2def' still has subclasses, including 'NSKVONotifying_JUCEWindow_7654d7c572cb2def'!
objc[42970]: objc_disposeClassPair: class 'JUCEWindow_7654d7c572cb2def' still has subclasses, including 'NSKVONotifying_JUCEWindow_7654d7c572cb2def'!
objc[42970]: objc_disposeClassPair: class 'JUCEView_b11f4fbe71056da2' still has subclasses, including 'NSKVONotifying_JUCEView_b11f4fbe71056da2'!
objc[42970]: objc_disposeClassPair: class 'JUCEView_b11f4fbe71056da2' still has subclasses, including 'NSKVONotifying_JUCEView_b11f4fbe71056da2'!

```

i’m pretty sure i’m releasing my objects at the end, and ASAN is confirming.

Anyone got these ? Any idea on how to get rid of them ?

---

<div class="post-metadata">

**Author:** ![ed95](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ed95/32/7635_2.png) [@ed95](https://forum.juce.com/u/ed95)\
**Post date:** [July 14, 2020, 7:19am UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/2 "2020-07-14T07:19:17Z")

</div>

Previous thread on this topic: [Warning messages on startup](https://forum.juce.com/t/warning-messages-on-startup/25389/2)

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [July 14, 2020, 4:12pm UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/3 "2020-07-14T16:12:33Z")

</div>

annoying. i wonder why only juce get those. might be because of the objc helpers custom dispose pairs?

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [July 14, 2020, 4:15pm UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/4 "2020-07-14T16:15:24Z")

</div>

found this, maybe it can inspire some ideas [https://www.cocoawithlove.com/2010/01/getting-subclasses-of-objective-c-class.html](https://www.cocoawithlove.com/2010/01/getting-subclasses-of-objective-c-class.html)

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [July 15, 2020, 6:49am UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/5 "2020-07-15T06:49:32Z")

</div>

it seems to be those static ObjCClass objects that are destroyed at static finalization.

```
NSView* NSViewComponentPeer::createViewInstance()
{
    static JuceNSViewClass cls;
    return cls.createInstance();
}

NSWindow* NSViewComponentPeer::createWindowInstance()
{
    static JuceNSWindowClass cls;
    return cls.createInstance();
}
```

---

<div class="post-metadata">

**Author:** ![ryanfrancesconi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ryanfrancesconi/32/10056_2.png) [@ryanfrancesconi](https://forum.juce.com/u/ryanfrancesconi)\
**Post date:** [December 21, 2020, 5:15pm UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/6 "2020-12-21T17:15:59Z")

</div>

Hi, I’m an audio unit host developer and I’m seeing this in various juce based audio units when attempting to shut down. Is there any additional info about this?  
Thanks, Ryan

---

<div class="post-metadata">

**Author:** ![emezeske](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/emezeske/32/15528_2.png) [@emezeske](https://forum.juce.com/u/emezeske)\
**Post date:** [May 8, 2026, 5:32pm UTC](https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712/7 "2026-05-08T17:32:13Z")

</div>

I sent out a PR that would fix this:

> <https://github.com/juce-framework/JUCE/pull/1656>
>
> I have found that depending on the situation, anywhere from 0.1% to 1% of my sta…ndalone JUCE application launches end up crashing at exit due to objc\_disposeClassPair() being called on a class that is still referenced.
> 
> This doesn't seem to be new. I have found several forum posts over the years that relate to this problem:
> 
> \* https://forum.juce.com/t/warning-message-displayed-when-exiting-the-demo-application/20904
> \* https://forum.juce.com/t/warning-messages-on-startup/25389
> \* https://forum.juce.com/t/objc-warnings-at-exit-since-catalina-switch/40712
> 
> I noticed this causing crashes for me, and built some simple tooling to launch a basic application thousands of times, and it the crashes are complete reproducible, even for a headless app that doesn't even open a physical OS window. Exactly what is required to reproduce the crash is very hard to say; I first noticed it under MallocScribble on macOS Sequoia/Tahoe (Darwin 25.3.0), so it is likely that it requires certain memory circumstances to become a crash rather than just a warning.
> 
> The thing is: all of the ObjCClass objects that JUCE uses have static lifetime. So there's really no benefit to calling objc\_disposeClassPair() -- the class will be cleaned up when the process terminates. Whatever the perceived benefit of "proper cleanup" it is outweighed by the fact that it causes crashes (or user confusion due to the warnings).
> 
> The simplest solution is to just give up on objc\_disposeClassPair(). I don't see any concrete downside to this, and this change will fix crashes that I see regularly as well as questions on the forums about the warnings.
