I don't believe it.
Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
For that matter, AppKit was first released on a NeXT with a 25 MHz 68030 and 8MB of RAM.
Of course they cause problems as well, you not believing it doesn't change profiler facts.
I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
Can I see the profiler data that shows AddRef/Release being a performance bottleneck?
Yes, learn to use one and point it to a C++ Github project full of shared pointers.
While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
embarrassing