Anyone who has managed to figure out anything substantial about SwiftUI has done so purely through a labor of love.
It's a really amazing system, but the sparseness of proper official documentation, Xcode bugs (like marking errors on a line far away from where the problem actually is) and the seemingly secret Swift magic that's used to implement some features, means everyone is stumbling blindly in a labyrinth, relying on each other's shouts to navigate.
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.
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.
> 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)
€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.)
> 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.
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) :)
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.
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...
> 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.
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).
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:
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.
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 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.
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.
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.
I'm having great fun building a SwiftUI app for a client. I haven't encountered any showstoppers, but several times I've changed the design to make it easier for myself.
To give you an example: pull-to-refresh isn't there yet. You have to build it yourself. I looked for a searchbar and I built it myself as well.
However building the GUI itself is very fast, because it compiles and immediately previews your code. The preview can be changed with the mouse, which updates your code again. That aspect is very, very nice and made my client smile when we were adjusting some padding, font sizes, image sizes etc. on the fly.
My personal showstopper was dealing with attributed strings. I couldn’t get an equivalent of multiline uitextview of attributed string. It happened after just 20 minutes building a real world app, which made me wonder if anyone has ever built anything real at apple with this framework.
(Also, i couldn’t get a list of all the types of views and their documentation anywhere in apple’s documentation).
Works with multiple lines, multiple font sizes etc.
Another undocumented gem that I discovered via the SwiftUI community. You should be able to build a constructor that reads a string with formatting codes like Markdown and spits multiple Text views.
Yeah it looks very promising since you can still use constants for all kinds of stuff like padding and colors but you do have that immediate feedback you get from interface builder. It seems to be faster than live code rendering views in interface builder, which admittedly is a really low bar to pass.
How does an `if` expression get inferred as a type `_ConditionalContent<...>`? Is there some magic support for SwiftUI in Swift? Does it desugar into something like:
It's using a not-yet-offical feature of Swift called "function builders." It's basically a way to walk through each Swift statement inside a function and build an aggregated value, including maintaining all of the type info.
So the language feature isn't tied specifically to SwiftUI (though SwiftUI is the only supported client at this point), but it supports that general kind of transformation.
The trick of using more compile-time knowledge to avoid diffing the tree of elements seems similar to svelte (https://svelte.dev) in the Javascript world.
> Is there some kind of embedded DSL stuff going on here?
Exactly. It's a (at this point, unofficial) Swift feature called "function builders." The types end up being the same, because the conditionals are represented as wrapper types.
It's a really amazing system, but the sparseness of proper official documentation, Xcode bugs (like marking errors on a line far away from where the problem actually is) and the seemingly secret Swift magic that's used to implement some features, means everyone is stumbling blindly in a labyrinth, relying on each other's shouts to navigate.
Resources like this post and https://swiftui-lab.com and https://mecid.github.io are a godsend.