Elements and SwiftUI

Elements
1

We’ve received quite a few questions like this via private support channels over the past few weeks, so I wanted to go ahead and post this reply publicly for everybody to enjoy.

Not quite yet.

We’re looking into supporting SwiftUI, of course, but there are many things to consider as to why it will be a short while until we can.

For one, SwiftUI is early beta. Half of the Swift language features that drive it are still in review, and some are not even in in review yet, let alone finalized, and they will change both between now and Xcode 11 RTM, and probably, it looks like, change again between then and when they are made official language features.

In fact, Beta 5 of Xcode 11 just drastically changed SwiftUI, yesterday.

For another, and this applies to using any Swift-based Apple frameworks (eg Combine, RealityKit), Swift has just reached **ABI Stability&& (in 5.0) — and Swift Module Stability, while planned and announced for Swift 5.1 is (a) still in beta and (b) entirely undocumented. This means a lot of work, research and reverse engineering will go into this over the next few months before we can link to Swift frameworks (maybe, depending on what Apple ships when, in time with Xcode 11 release, but possibly not until after).

The thing to keep in mind is this: Apple’s developer platform, Cocoa, is a beautiful and well designed piece of technology, well documented, solid, and easy to work with both for developers and for tool chains such as ours. That’s the Objective-C runtime, and you can tell that it was created a good while ago by people who knew what they were doing,

On top of this/parallel to this Apple is constructing a whole another layer, the Swift Runtime and ABI, and it is not well designed or documented (neither well or, like, at all) and as not, frankly, the air of something designed by someone who did this before or knows what they are doing. :frowning:

That’s what we have to deal with right now, for Swift ABI interoperability.

You can also refer to these documentation topics for more information on what we’re doing to support Swift object model on macOS/iOS:

These will be updated over time, as things progress.

thanx!
marc

3 Likes
3

Is there any news regarding this ?

4

Short answer: no.

5

I saw in the latest release notes

  • 83417: Swift ABI arc
  • 83408: Swift ABI interop support (wip)
  • Preparative work for Swift ABI.

Does that mean your working on something at the moment ?

6

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 ;), should let you use the SwiftUI APIs.

2 Likes
7

Can’t agree more. On Windows I once briefly looked at the (back then) new and shiny WPF, but quickly realized that it’s better to keep using the good-old WinForms. I personally tend to stay with proven (= old) technologies. That’s the safer choice.

Same for Swift. When it was introduced in 2014 it was far from finished. If you look at some questions in StackOverflow you’ll often see multiple answers for v1, v2, v3, v4 and v5 (…). You had several breaking changes, especially from v1 to v3. That’s why many programmers still prefer Objective-C. It’s old, but very mature. The older the better.

Same for SwiftUI. I hate frameworks doing “magical stuff” dynamically; I want to sit at the steering wheel. I personally stick with Cocoa until SwiftUI has become mature. That can take 4-5 years maybe. Or maybe I will ignore it.

Imho … :wink:

1 Like
8

Are we any closer to being able to use Swift UI. I was looking at the WidgetKit and it looks like its swift ui only ?

9

Afraid not, no.

10

Whats the issue ?

11

Same as before — Swift ABI is totally undocumented (“the compiler, including bugs, is the spec”), fragile, ever-changing and we need to reverse-engineer support for it (which we’re working on), with the expectation it’ll break with every OS. Apple is making a huge mess here and it will come to bite them, badly.

We’ll get there eventually, but not this week, and not this month.

That said, by all accounts SwiftUI is still pretty much unusable for any real dev work. So widgets aside, I don’t believe it’s a huge problem that we’re still a few months away from supporting it It won’t be good until next summer (if then).

2 Likes
12

I noticed in the change log for this weeks preview

“prep work for upcoming Swift ABI support”

I was wondering if I should be getting excited ? :slight_smile:

1 Like
13

yeah, but not too excited yet. it’s still a long road ahead.

1 Like
14

Rome was not build in a day, but:

image
image2942×1980 468 KB

1 Like
15

We will be able to use Oxygene and have something to play with in Friday’s build ?

16

Swift ABI types will be (are) available from any language yes, once you have the .fx files.

I have nothing to announce for SwiftUI specific language features (some, function builders) coming to Oxygene and the other lanuguages at this time., But i expect once this is working, we will provide some (pun not intended) features to make SwiftUI easier/as easy to use from all languages,. yes.

Something, possibly. something usable? probably not for a few more weeks.

If nothing else, i can make the imported SDK files available (assuming they don’t make it into the build yet, which might or might not happen), so you can replace the regular SDK with that one and get the extra .fx files to play with.

Note that all of this is Island-only.

17

Which platform do you care about most for playing, macOS or iOS?

18

iOS

1 Like
19

lol this was interesting reading.

20

It’s all very insane, yes.