From reading this post, it sounds like using Swift reference types, even those not marked @objc, introduces the same sort of startup overhead as Objective-C classes. This is surprising, especially after watching a WWDC talk where it claimed that using Swift types would reduce this sort of overhead. The post mentions that using Swift structs could help, but that also has tradeoffs of course.
Why does Swift need this sort of setup at startup? Are there any ways to reduce it (while still using reference types) or plans to reduce it in the future?
The article attribute start up time to class pointers rebase. Since this has to take place, then not much dyld do to improve this?
But...
The latest iOS dev beta 14.5 (18E5164h), app launch from cold is much faster than the previous beta, pretty much instantaneous for my own app. Most apps start up super fast! I thought maybe they are cheating by not actually killing the app when you flick up on task switcher. So I even reboot my phone and app start up still super fast!
What did Apple do make it so fast?
Since app startup just become so much faster now by the new iOS version, then what he was talking about may not apply anymore.
As for class vs struct, it's amazing to see how much code is generate for class:
Your linked article explains why: ASLR requires it. However, the article doesn't mention the various costs of actual Obj-C initialization, such as +initialize, where many frameworks hide work they want performed before various Obj-C classes are used. These have a much higher performance hit than simple pointer rebasing, and you avoid all of these costs by using native Swift classes, as those performance bottlenecks don't exist.
Edit: Additionally, Swift classes inherit from Obj-C on Apple platforms to enable Obj-C interop (AFAIK). This doesn't happen on other platforms (again AFAIK).