As someone who has written Apple-only apps with JUCE, the answer is an emphatic yes, for a few reasons.
The biggest is that IMO JUCE’s APIs are simply better than all native APIs, even Apple’s (sometimes especially Apple’s). They “just work”, and are very well documented with full source access and a direct line to the developer (Jules et.al.) for clarification if needed. This API superiority is true for all aspects of JUCE - audio setup, GUI, video playback, etc. especially when it comes to writing audio plugins.
Additionally, using JUCE’s widgets allows you to sidestep using the extremely long-in-the-tooth AppKit/UIKit + the travesty that is modern iterations of interface builder, and instead use a super simple and reliable MVC listener system. Much of JUCE’s design is very KISS oriented, and while it may involve a bit more typing in the short term (i.e. implementing
Listener methods) it makes the architecture so much easier to follow later.
I haven’t used Swift much, but I know it’s a nice language and is useful for app developers. I don’t know much about its implied vs. guaranteed performance characteristics so I can’t comment on its usefulness for real-time applications, but I think for most low-level systems and multimedia framework developers Objective-C/C++ continues to reign and will for a long time. From an engineering standpoint, the reasoning is because of 1. The amount of legacy code which would need to be converted and thoroughly debugged and 2. the fact that Swift has no native C++ interop akin to Objective-C++'s “how is this even working” level of homogenous inter-language flow. In Swift, you have to write C or Objective-C wrappers for all C++ code. Not fun when you’re trying to bring in an external library!