Yeah, bit of a shame. I took some time to go through Apple's tutorial, just to get a taste of SwiftUI, but I ran into Xcode crapping the bed every few minutes; having to clean the build folder every time a new source file was added; compiler bugs; and to top it all off there were a couple of places that the tutorial was outdated already.

And of course you need to be on the bug riddled Catalina to get any real SwiftUI development done (live previews).

UI development in the Apple ecosystem has always been a bit rough, but I've never run into _this_ many problems in such a short amount of time, all while following their official tutorial.

I mean XCode has been a terrible experience for a lot of devs (C++ in particular) for years. I completely avoid it, when you need it for a build just invoke it from the command line. Some of the other stuff is tricky to set up outside the UI so you need it, but other than that, XCode is not worth the hassle imo.

Real shame too. I've talked about this with some of their tools team I went to school with. I don't know what's in the water in Cupertino but I don't think Apple devs are getting the same experience out of XCode as their actual users.

The problems with diagnostics are not Xcode’s fault but rather limitations of the Swift compiler diagnostics engine. The original design dating back to Swift 1.0 has the constraint solver basically produce a success or failure result; in the failure case the type checker would then go and re-type check different subexpressions and try to piece together the types to figure out what went wrong.

This was complex and somewhat tricky to get right, which is why sometimes you see errors that seemingly have nothing to do with the original problem. Closures and generics were especially problematic for the old design to deal with.

Since Swift 4.2 there has been an ongoing effort to rewrite diagnostics so that the solver keeps enough breadcrumbs from failed constraints to piece together an accurate error message. On the master branch the type checker’s test suite has lots of examples where diagnostics have improved significantly.

> The problems with diagnostics are not Xcode’s fault but rather limitations of the Swift compiler diagnostics engine.

True: https://swift.org/blog/new-diagnostic-arch-overview/

SwiftUI should have carried the “Beta” label in my opinion.

Rumors are this was pushed out this year in order to respond to Catalyst’s public unveiling. Word is there was a little internal politics over what is the “preferred” method for apps on the Mac.

At least, that’s what I have seen on Twitter. Personally, I think it was mainly about wanting to get the Swift features in place to support it and since Swift is largely evolved and developed in the public it needed to come sooner, rather than later.

If it quacks like an alpha, is documented like an alpha, and is unreliable like an alpha... it's production ready because the vendor took the beta label off it.

Edits: typos

> SwiftUI should have carried the “Beta” label in my opinion.

Many parts of the SwiftUI documentation are still marked [Beta] for all OSes. Or maybe it's just saying that the documentation is beta, though it's more like Alpha..

EDIT: Apparently it says Beta only in the offline docs on Xcode 11.1 (not sure about 11.2)

> Every bit of SwiftUI documentation is still marked [Beta] for all OSes.

It is not, aside from a smattering of pages I am assuming that have not been updated: https://developer.apple.com/documentation/swiftui

Strange, on Xcode 11.1 I get this: https://i.imgur.com/j5V1CHN.png

Whereas the web version doesn't have the beta tag: https://developer.apple.com/documentation/swiftui/text

That was just while the Framework was only shipping on beta OSs. The docs don't say Beta anymore.

€0.02 SwiftUI is ‘declarative’ done pretty horribly wrong. Specifically: the DSL is a mess, very not easily compatible with vanilla Swift; the gestures are really hard to get working just right; the animation api is way too automagical. All in all it makes doing things like trying to use helper functions become sado-masochism. It really makes me miss my days with React+Redux, even with all the boilerplate.

FWIW, we have a new official addon package called Redux Starter Kit [0]. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action creators or action types by hand.

We're starting on a major rewrite of the Redux core docs [1], and as part of that we'll be encouraging folks to use RSK as the default way to write Redux code.

(Note that we're also discussing possibly renaming RSK [2] to avoid confusion over the word "Starter" - a lot of folks are mistaking this to mean that it's only good for beginners or that it's some kind of project CLI tool.)

[0] https://redux-starter-kit.js.org

[1] https://github.com/reduxjs/redux/issues/3592

[2] https://github.com/reduxjs/redux-starter-kit/issues/246

See also Druid:

https://docs.rs/druid/

...and this thread where two interested parties discuss SwiftUI briefly:

https://twitter.com/raphlinus/status/1190025792534798338

...and also this blog post: https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020....

> Anyone who has managed to figure out anything substantial about SwiftUI has done so purely through a labor of love.

There are lots of apps which are simply specialized CRUD apps. Personally, I love building them. The current state of SwiftUI is sufficiently developed for this kind of app.

I also see great potential in it for game UIs. Scalable UI with crisp text and vector shapes has generally been a pain [for me] in gamedev with other frameworks.

Best of all I generally have to write most game UI views just once for iOS/macOS (because they won't use native widgets anyway) with a few #if differences.

I hadn't realized that SwiftUI could play a role here. Sounds hugely interesting! Best of luck!

Self-plug: My pet project's an open source game engine [0] that lets you use SwiftUI over SpriteKit/Metal views. Once I figure out how to write custom DSLs in Swift, I hope to have an API for describing game scene entities and their components in a SwiftUI-like declarative syntax, or maybe just make them all behave like SwiftUI views + view modifiers.

You'd also be able to use mostly the same code (even for touch and mouse input) on both iOS/macOS without needing to use Catalyst (which brings bugs of its own) :)

[0] https://github.com/InvadingOctopus/octopuskit

Comparing with Flutter, I must appreciate things that SwiftUI does not have:

- open source code - if something is not clear I can always CTRL + click a widget and see how it's implemented

- there is official formatter for Dart which formats widgets on save (IMO essential things for layout in code)

- documentation is good enough

- it works on any iOS version

- it works on two popular IDEs which support plugins

I personnaly stopped exploring flutter after seeing how it lagged on scrolling even on an iphoneX (flutter demo app on the app store), and how this app also had bug when opening the keyboard, with a blank placeholder wasn’t in sync with they keyboard animation and could be seen while the animation took place.

I had great hopes for flutter, but this kind of cooled me down instantly.

I did not intent to praise Flutter, it's just amusing that Google's side project is in many ways more polished than Apple's main source of income.

Regarding bugs you have mentioned... I've seen worse stuff, but that's how it is with new technologies.

100% Agreed. When I was evaluating what platform to develop on, I found Flutter and it checked off all the right boxes on paper. So I started to write an app in it and soon discovered the checks are absolutely real. I can't imagine that it works for 100% of the use cases, but if you're developing a relatively simple mobile app... Flutter is the way to go. Dart is lovely to work in and the API is strangely similar to SwiftUI. ;-)

I also filed a bug about tests in Dart not being able to be code folded properly in IDEA and it was fixed within about a month. The developers of that plugin really take it seriously. Totally awesome.

Agree but despite that I keep coming back to it and using it, replacing a few of my UIKit views with SwiftUI. It's everything I like about React and Swift together. Hoping compiler messages improve a lot in the next few releases.

What makes you say it is an amazing system? In my mind, an amazing system would at the very least be cross platform.

It's 'new' and it has 'Apple' behind it. I had to google to make sure I wasn't missing something. It's 'declarative', it has 'design tools' and it works on 'apple only platforms' [0]. Are those supposed to be killer features?

There was a twitter question that really made me think - it asked what framework, language or tool of today, would give a competitive advantage, if you had it 15 years ago [1]. I couldn't come up with a single thing, and that was a depressing realization.

Is SwiftUI that tool that will be looked back on in 15 years? Is Swift that language? For me, no. It's not even bloody cross platform...

[0] https://developer.apple.com/xcode/swiftui/ [1] https://twitter.com/tolmasky/status/1183146890293956609?s=20

> In my mind, an amazing system would at the very least be cross platform.

Being able to target desktop, phone, tablet, and TV devices while reusing 80%-90%* of the same code for all of them, is cross-platform enough for me. :)

macOS, iOS, iPadOS, tvOS, and soon AROS if the rumors have weight, comprise over a billion users. And if you're someone who likes to tinker with the latest tech in your apps, Apple has the best ecosystem because most of their users quickly upgrade to the latest OS, compared to Android etc.

* Ass estimate

Yes, we all know and love Java cross-platform UIs.

Yes, I actually typed then deleted "beyond Apple's tutorial" because I assumed the point would be understood. :)

> the seemingly secret Swift magic that's used to implement some features

What magic are we talking about? I thought all the new stuff was RFC'd right after SwiftUI was announced.

Maybe I'm just dumb, but there seem to be arcane tricks that SwiftUI's native types can do but I can't replicate in my own types.

SwiftUI relies on implicit return statements, property wrappers, keypath member lookup and function builders. All but the last have gone through the evolution process and are implemented completely in Swift 5.1. The function builders feature has been pitched and is going through the process; the current implementation uses an underscored attribute. The implementation might change but it will not affect client code, only the declarations of the relevant types in SwiftUI. This means you can’t define your own function builders today without a future compiler possibly breaking source compatibility with your implementation — but other than that there’s no magic in the SwiftUI API beyond the language itself.

Yep. The funny thing is that if you try to use this new automatic type-erasure stuff for anything but SwiftUI, you will soon encounter compiler errors like “`some` types are only implemented for method return types or computed property accessor return types”. Lol.

So e.g. you can’t use `some`-typed variables or stored properties.

The `some` keyword declares an opaque result type ([0]), which means "this function has a concrete return type, but the identity of that type is a hidden implementation detail." An opaque result type can be used like a generic type -- the compiler doesn't know the exact type, but it does know that calls to the function will always return the same type (which is important when working with protocols such as `Equatable` that have associatedtype or Self requirements).

A `some`-typed variable or stored property wouldn't make any sense because it would be a variable that has a concrete but unknown type. You can't assign something to such a variable, because there's no way to know whether the value you're trying to assign matches the hidden concrete type of the variable.

Perhaps the "automatic type-erasure" feature you're wanting is actually generalized existentials ([1])? Generalized existentials would allow you to declare a variable whose type can be "any Equatable", rather than "some (specific but unknown) Equatable", and the compiler would allow you to "open" the existential and use it like a generic type (without throwing the "protocol can only be used as a generic constraint because it has Self or associatedtype requirements" error).

[0]: https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.... [1]: https://github.com/apple/swift/blob/master/docs/GenericsMani...

You definitely can have a 'some' type property[0]. Computed properties work just like functions do. Stored properties just need a value assigned, like so:

    let strings: some Collection = ["hello", "world"]

[0]https://github.com/apple/swift-evolution/blob/master/proposa...

I haven't really dug into SwiftUI yet, but I'm not quite sure what you're describing. I'd love to see a concrete example of something you think you can't replicate with your own type.

I tend to run into these when weaving a lot of SwiftUI + non-SwiftUI code together.

A simple example: [0]. There are workarounds for this specific issue, but trying to do complex stuff sometimes surfaces inscrutable limitations that I can't quite figure out. And with no documentation relevant to a particular case, no Google hits, not even on Apple's forums, and the uncertainty of error messages, I'm not even sure if I'm doing something wrong or it just can't/shouldn't be done. I have to try random things until it works...until it doesn't.

I'm currently experimenting with a SwiftUI layer for a game engine [1], and running into weird undocumented differences between macOS and iOS (like view backgrounds clipping at stack container edges on macOS but not on iOS) that I can't be sure if they're bugs or what. Still, I love SwiftUI.

Also see EmptyView [2]

[0] https://gist.github.com/ShinryakuTako/5a7b32bbf4f4c3874439c2...

[1] https://github.com/InvadingOctopus/octopuskit

[2] https://forums.swift.org/t/how-do-views-like-emptyview-confo...

I assume your goal with [0] is to be able to say `ViewContainer()` and have it wrap an `EmptyView`? You can do that like the following:

  class ViewContainer<ViewType: View> {
      var view: ViewType
      init(view: ViewType) {
          self.view = view
      }
  }
  
  extension ViewContainer where ViewType == EmptyView {
      convenience init() {
          self.init(view: EmptyView())
      }
  }

With this code, writing `ViewContainer()` will produce a `ViewContainer<EmptyView>`. Writing `ViewContainer<Text>()` will fail with an error (as expected).

Note that since this is statically-typed, the following will fail:

  let container = ViewContainer()
  container.view = Text("wat")

If you want to be able to do that, you'd have to write something like

  let container = ViewContainer(view: AnyView(EmptyView()))
  container.view = AnyView(Text("wat"))

I love the extension idea, noting that for later. :)

But I do need to be able to change the view during runtime, so I settled on just type-erasing to AnyView for now.

If you have a set number of possible view types you could in theory have it hold onto an enum of the different types.

I think the issue is that a variable's type can't be set by the outside (via the template parameter ViewType) and by the inside (to be of type EmptyView) at the same time. You have to decide.

Your workaround is to use the AnyView type I guess. Or a conditional with either EmptyView or the template type (displayed).

What would be the name of the feature that allows you to use a default template type if no argument is given to figure out the type to use?

> Your workaround is to use the AnyView type I guess.

Yes, I made the init generic instead of the type, and made the property an AnyView, but I've read that AnyView may decrease performance (probably because of reasons discussed in this post's article.)

True. You could work around it by conditionally extending your ViewContainer to have a default constructor (init()), if the type is EmptyView. Then you can write

    var viewContainer2 = ViewContainer<EmptyView>()

But that's probably not what you want is it. Default generic arguments aren't implemented yet, see (https://stackoverflow.com/questions/42015081/can-i-assign-a-...). It would have possibly removed the <EmptyView> aspect. So you always have to give a type to ViewContainer, if you provide no way for the compiler to infer it.

> var viewContainer2 = ViewContainer<EmptyView>()

Yes, that would be a workaround for myself, but for a game engine's API, it'd be ugly to require users to write that every time. :)

And there are cases where they might not even know the type.

It seems the compiler might be smarter than I thought he is (see a poster above), if so I learnt something new. :)

And it seems I didn't understand your problem, you wanting a variable that can change it's type instead of just some syntactic sugar, hmm.

I believe SwiftUI's not doing anything that isn't available in the public version of Swift. There may be some stuff that's still going through the proposal process, not sure.

His problem might be that certain features (of SwiftUI) you cannot hook yourself (your own implementation) into (since they are based on protocols which cannot be implemented yourself since they are not public and so not meant to be implemented by yourself), which makes it, at times, necessary to use workarounds to public-facing apis.

Or it might be something else.

You're correct, part of the problem is indeed that, though I'm not completely sure myself.

But how do things like EmptyView work? How do they conform to the View protocol without having a body property (that must also be a View)?

I think it has a body type [0] (Never). And since a default implementation is provided [1] the compiler probably does not complain. This default body implementation does likely not draw anything, but that's just guessing.

[0]: https://developer.apple.com/documentation/swiftui/emptyview/... [1]: https://developer.apple.com/documentation/swiftui/view/32785...

It's because of Body's type:

    public struct EmptyView: View {
        @inlinable public init()
        public typealias Body = Never
    }

Because Body is Never, you can't access EmptyView's body property.

Can we write a protocol + type like that?

https://forums.swift.org/t/how-do-views-like-emptyview-confo...

I don't see why not. When I trick it into calling `body` on an EmptyView, I get this runtime failure:

> Thread 1: Fatal error: body() should not be called on EmptyView.

So I don't think the implementation is doing anything beyond the fatalError() call from that forum thread. At least not at this point in time.

My thoughts with this stuff tend to go:

   1.  What the ... ?
   2.  That's really clever.
   3.  That's a really bad idea (see 2)

That’s how I feel about nil messaging, autorelease pools and proxy objects :-)

Hmm.. ;-)

You say "nil messaging", I say "pervasive optionals".

You say "autorelease pool", I say "deterministic delayed free".

You say "proxy objects", I say "first class variables".

And all of these aren't particularly clever in the sense of "so incredibly complicated that nobody can figure them out".

Maybe "hacky".