I was wondering now that Swift 5.1 is available. I was wondering what the planned features for Silver? Would the Module Stability / ABI stability help in any way? Would I be able to compile something in XCode and leverage it in Fire/Silver?
I think this is the latest info
Do you have any specific use cases we can take in account for this feature?
Hey Carlo, I think it would be amazing if I could use .xcframework files or compile a Swift-coded library in Xcode and leverage it in Fire/Silver. I am only wondering if the existing Silver Swift language limitations (or will these be gone in the future?) would apply here too. For example, if I would compile projects like Chatto or MessageKit as framework I could leverage it without needing to partly rewrite due the above mentioned reason.
The dream would be if it would support something like
Swift Package Manager and maybe compile it and go use it!
Thats the goal, yes.
No, since you’d be compiling these with Apple Swift, and just use the binary. If/Once we have full support ABI compatibility, any Swift binary should be usable. Problem is, none of Swift’s ABI is documented, all of it is messy, and despite what Apple is saying, from the looks of it its very likely to break in future Swift or OS versions :(. We’ll see…
Support for Swift Package Mangewr is outside of the scope of what we’re looking at, for now. But if you have an import project for the frameworks you wanna use, you could then use Remote Project References (essentially our equivalent of a package manager format) to pull those in.
Awesome, super excited about this
Ah so one of those cases where the source code is the documentation? My understanding is that bunch of limitations in Elements for the Swift language are due to the limitations of .NET.
I was wondering when you would use Island if these kind of limitations would be lifted?
In this week’s changelog for the Fire download it’s referring to Swift HI. What does this mean? My Google skills are too limited it seems.
Swift support is a work in progress. It’s not usable for anything atm.
Some are .NET, some are also due to Island’s own object model (think generics, which are very different in Swift). once Swift ABI is done, you’ll have here object models in Island/Cocoa: native Island, Objective-C/Cocoa (those two are supported now) and Swift. The latter will ideally have all the capabilities.
HI is short for Header Importer (the tool we use to import .fx files, currently from C/Objective-C. The entry means work on that was done, but it’s no finished (far from) nor exposed to the user yet.