Adding support for Swift / Moving away from Obj-C on Apple platforms
This proposal aims to define a possible design for how we can move away from Obj-C on Apple platforms, and what challenges we might face along the way and what needs to be done to get there. It is a continuation of the work setup by https://github.com/react-native-community/discussions-and-proposals/issues/253 and https://github.com/facebook/react-native/pull/41896 .
Please feel free to leave comments, edits and thoughts on this proposal as well as any challenges that you feel might block such a change so we can define the scope of the work that might be needed and how / if we should go about doing this.
Special thanks to @cipolleschi for the instructions on how to setup this RFC
A rendered version of the proposal can be read here
Not very constructive, but I just wanna say I really stand behind this RFC.
Objective-C (or actually Objective-C++) is really good when it comes to C++ interop, but that's about it. Swift is easier to read, much less code, simpler, memory is managed better, sometimes it's even faster (direct method call vs message send), and it ultimately invites more outside contributions. I'm sure a lot of people are hesitant about reading RN Core code or contributing to it just because it's Objective-C. Swift is easier to understand for JS devs.
Expo uses Swift, VisionCamera uses Swift, and pretty much all modern iOS libs use Swift.
With that said, it's obviously a huge effort, and I fully agree that current efforts are best dedicated to new arch stuff. That's where it starts to get tricky though because everything is in C++ now and Swift <> C++ interop is still very limited - no templates, not all default headers will work, and stuff like folly, jsi, or react headers will probably require intermediate bridging headers.
Which is an okay workaround, but takes more time to write.