I don't know if this is an easy question to answer. I guess the main reason is that afaik Swift doesn't have anything like libobjc that gives you access to the runtime. And then also because sooo much of Apple software is based on the Objective-C runtime, Swift either reimplements or is based on that same runtime behind the scenes. Ultimately most of the frameworks you want to use are actually written in Objective-C even if they're available in Swift, so there isn't much of a reason to bridge to Swift even if it were possible.
Ultimately we want access to the APIs and frameworks, not the language, but we need the runtime to use those APIs. Though it's interesting that because Objective-C is so dynamic and runtime oriented, it would give a language like Go the ability to create classes and instances of those classes at runtime. I don't think that is very useful in practice, but an interesting side-effect of bridging the runtimes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't know if this is an easy question to answer. I guess the main reason is that afaik Swift doesn't have anything like libobjc that gives you access to the runtime. And then also because sooo much of Apple software is based on the Objective-C runtime, Swift either reimplements or is based on that same runtime behind the scenes. Ultimately most of the frameworks you want to use are actually written in Objective-C even if they're available in Swift, so there isn't much of a reason to bridge to Swift even if it were possible.
Ultimately we want access to the APIs and frameworks, not the language, but we need the runtime to use those APIs. Though it's interesting that because Objective-C is so dynamic and runtime oriented, it would give a language like Go the ability to create classes and instances of those classes at runtime. I don't think that is very useful in practice, but an interesting side-effect of bridging the runtimes.