Swift ABI

[wdb]

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?

[JohnMoshakis]

I think this is the latest info

Elements and SwiftUI

We’ve started working on the “Swift” object model for Island/Darwin, yes, which in the long run will include generating Swift ABI compatible types that Apple Swift can link to, and linking to Apple Swift-generated libraries and frameworks (which would include SwiftUI). We’re not doing anything specifically for working with or integrating SwiftUI, nor will we, probably, before “SwiftUI 2.0”, which will most likely break everything. But the above, once done (which it’s nit close to being, yet ;),…

[ck (Carlo Kok)]

Do you have any specific use cases we can take in account for this feature?

[wdb]

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!

[mh (marc hoffman)]

@wdb

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.

Thats the goal, yes.

@wdb

I am only wondering if the existing Silver Swift language limitations (or will these be gone in the future?) would apply here too.

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…

@wdb

The dream would be if it would support something like Swift Package Manager and maybe compile it and go use it!

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.

[wdb]

@mh

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.

Thats the goal, yes.

Awesome, super excited about this

@mh

I am only wondering if the existing Silver Swift language limitations (or will these be gone in the future?) would apply here too.

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…

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?

@mh

The dream would be if it would support something like Swift Package Manager and maybe compile it and go use it!

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.

Totally understandable

[wdb]

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.

[ck (Carlo Kok)]

Swift support is a work in progress. It’s not usable for anything atm.

[mh (marc hoffman)]

@wdb

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?

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.

@wdb

In this week’s changelog for the Fire download it’s referring to Swift HI. What does this mean?

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.

[wdb]

Earlier in this topic was asked by @ck which use case I have to want to use Swift frameworks, if this would be supported this would allow to use AWS SDKs or a library like Lottie-iOS (http://github.com/airbnb/lottie-ios).

Currently, if you try to import these .framework files it will give you Importing Swift frameworks is not supported yet.

[mh (marc hoffman)]

@wdb

use AWS SDKs

The AWS SDK is Swift now? I didn’t know that… last I used it it was still Objective-C and imported fine (I use it in the Weather app)

[wdb]

Sorry, for the confusion I was trying to use this one: GitHub - aws-amplify/amplify-ios: A declarative library for application development using cloud services.

Luckily, somehow while googling that I did discover that Lottie upgraded to Swift in v3 and v2 is ObjC so that’s happy days Appears more and more frameworks are moving to rewriting in Swift

[mh (marc hoffman)]

@wdb

Appears more and more frameworks are moving to rewriting in Swift

Yeah. now if only Swift ABI was a viable os platform like Cocoa was and not a utter and total shit show… :(.

[JohnMoshakis]

Is it stable and not documented or do they keep changing things ?

[mh (marc hoffman)]

@JohnMoshakis

Is it stable and not documented

way worse than either: it’s “the compiler code, bugs and all, is the spec”.

[chikega (Gary Chike)]

It appears that Module stability (and ABI stability) are still under ‘active development’ … so it’s a moving target for the RemObject peeps and everyone else. This author appears to suggest using an Objective-C wrapper which was confirmed as a viable ‘workaround’ by an Apple engineer.

[mh (marc hoffman)]

@chikega

This author appears to suggest using an Objective-C wrapper which was confirmed as a viable ‘workaround’ by an Apple engineer.

Good idea, yes — where feasible.

@chikega

It appears that Module stability (and ABI stability) are still under ‘active development’

here’s to hoping that at some stage it will be truly stage and fully cleanly spec’ed, then…

[wdb]

Discovered this on HN: IR/AArch64/X86: add "swifttailcc" calling convention. · llvm/llvm-project@82a0e80 · GitHub

[ck (Carlo Kok)]

that in no way makes it easier to do swift interop though. That’s a new feature in llvm that swift needs.

[wdb]

Oh I thought maybe it helps deciphering behaviour of Swift
Maybe they will release a specification this WWDC (five nines chance they won’t)

Kotlin seems to work the other way around if I understood they marketing correctly. You write code in KVVM and then generate libraries you can use in Xcode/Swift.