I've been working full time on an app in SwiftUI for the past 8 months or so. I'll sum it up this way: I frequently oscillate between thinking "This is amazing, it truly is a joy to work with SwiftUI" and "Holy FUCK this is the most infuriating thing I've ever experienced in my life".
I can't comment on the documentation, because there isn't any. The closest thing you get is the WWDC videos from the past few years where most things are outdated anyway. There's also lots of third party tutorials and what not that open with "Apple doesn't say anything about how this works, but I think I might have figured it out". And a lot of those third party sources are pretty good, but still. It's hardly ideal.
There are also a lot of inscrutable little edge cases where something just doesn't work, and there's hardly any path to figuring out why. Scrolling performance will tank, for example, after some trivial change. The framework "works like magic", until it doesn't. And you're stuck tweaking random things hoping something makes a difference.
BUT, at the same time, it's awesome. Code reuse is like, a real thing this time, not just something that works on paper but not in practice. You can compose things very quickly and succinctly, and you no longer have the unreadable, un-mergeable, unsearchable, existential nightmare that was storyboards. When it works, it really is fantastic. Don't count on the "live preview" though. That thing never works for anything other than the most trivial of examples.
If I could go back to 8 months ago, I probably would have chosen differently. But it is clear that SwiftUI is the future, and within a year or two it will be unequivocally better than UIKit. So if you're starting now... maybe. Just be prepared for some pain.
Can't agree more with this. Coming from Elm/React to my first project in Swift choosing SwiftUI seemed like the obvious choice. It always felt like the type system wasn't quite powerful enough to express the API. Once you add Combine into the mix type erasure makes debugging issues unspeakably painful, errors appearing on the wrong lines at best and often in entirely different files. Then there's the tooling, Swift Package Manager was endlessly running into mysterious issues that would eventually disappear if I just rebuilt the project enough times. As for SwiftUI preview I have no idea what was going on there but it brought my brand new iMac to a halt, simple code changes causing multiple minutes of the dreaded spinner. I was using Swift for a side project and the issues just destroyed all motivation to continue with it. I've since switched to Flutter which while the language isn't as capable (though reified generics are a huge improvement) does at least feel like a solid tool to build apps with.
I don’t understand why Apple doesn’t just document this. Is the team responsible for it just pro-UIKit and doesn’t actually want people to use SwiftUI or something? Because the lack of documentation for so long really does give me the impression that they actually don’t want people to use it. It’s hard to believe it could just be incompetence.
The documentation for everything lags years behind now. The only reasonable explanation is just that they have far too few people working on docs and don't consider it an important thing to hire more people for.
I had no idea this was a thing, thanks! Could have done with it recently when tracking down some nasty internal bugs in CoreMIDI. Ah well, the investigation was interesting at least...
True, but if everyone did that, there wouldn’t be any Apple engineers left to fix the damn software itself, because they’d all be running 24/7 support for millions of angry users, answering the same damn questions and complaints again and again and again.
If that is their intended process, then it is such a false economy that it warrants firings all the way up to the board.
This is why we write documentation—good documentation, that explains the product and how to use it, and anticipates the common problems that users run into and guides them through those as well. So that users can handle the day-to-day stuff and only need to interrupt its developers for the exceptional cases that no-one has anticipated—which is as much about the developers learning what more they need to fix as about getting users over that hump in the meantime.
.
Apple is absolutely, notoriously, abominable at documentation, in part I think because Apple really absolutely hates to admit that its shit ever smells too. But if you can’t own your own mistakes, then you’re never going to fix them and get rid of that stink.
Honestly, I really miss their old NeXt-derived docs from back in the early days of OS X, both in their content and their presentation and navigability. I mean, they weren’t brilliant—good on the Whats but not asogreat on the Hows—but compared to the slop they’ve been serving users these last 10 years those docs were an absolute masterclass. Or even look at Microsoft, who * and* accept their APIs are complex and difficult, and so document the tar out of them so their users can mostly get by for themselves.
.
The other problem is, the health of the developer platform today isn’t immediately, directly reflected in the size of the next quarter’s results. So when the company’s run by and for the beancounters and shareholders, without regard for what the engineers are telling them, they don’t see the need for greater long-term investment. I mean: everything works great now, just look at the size of those revenues!
It not till years later that the knockon effects of those poor upstream processes and resources reach the surface, at which point the damage is far more severe than it ever should have been had they nipped it at the start. Just ask the formerly engineer-led Boeing how that whole McDonnell-Douglas pennycounting culture is working out for them now. Yup.
While I concede documentation has slipped greatly the last 20 years to an all time low, Apple did produced the Inside Macintosh series, possibly the greatest developer documentation ever written.
IM was a work of art in its own right. Maybe a bit James Joyce, but if nothing else you could always mount it on your wall.
I spent a lot of time in the IAC book many moons ago, extracting the concepts and motivations left unspoken in Apple’s newer “long lists of buttons” documentation. “How” stuff makes vastly more sense once you understand the “Why” that underpins it all.
For what it's worth, I've been getting plenty of Feedback Assistant responses from Apple to requests related to SwiftUI and its documentation. And Josh Schaffer who led UIKit also leads SwiftUI now.
> Is the team responsible for it just pro-UIKit and doesn’t actually want people to use SwiftUI or something? Because the lack of documentation for so long really does give me the impression that they actually don’t want people to use it.
> And Josh Schaffer who led UIKit also leads SwiftUI now.
This makes it sound like GP's theory is at least plausible
Yup, I wonder same thing. Besides the docs, it's the lack of comments and help on the "developer forums". They are content to let developers flail and struggle with a topic for years rather than take some time to help. It comes across to me as gross arrogance, but it could be something else.
I've had these problems for everything Apple since before Swift was even a thing, documentation is basically 'Google things up and pray you find something that's not only relevant, but recent', since every September you're basically forced to migrate breaking changes of everything. But SwiftUI really is the right move.
> Don't count on the "live preview" though. That thing never works for anything other than the most trivial of examples.
this was the one thing i would have hoped they would have finally fixed... wether its with xib/storyboards or swiftui, not getting realtime feedback on layouts is infuriating...
It works for me for a few not-quite-trivial views (e.g. a plot). It got a lot better with Xcode 12. The main thing now is if it doesn't work the error messages are basically useless, so you have to be very careful in setting it up. At least for me, the error message often made it seem like a random issue with Live Preview but it actually boiled down to some mistake in my code.
yes, this is the hard part i think, and it was a similar issue with even storyboards/xib... since everything is in the same module, an issue somewhere else prevents compilation and hence the preview dies*
* maybe that is a reason until recently, declarative xml layout was used for a long time, no need to worry about compilation failure to get previews (in theory anyways)
> I frequently oscillate between thinking "This is amazing, it truly is a joy to work with SwiftUI" and "Holy FUCK this is the most infuriating thing I've ever experienced in my life".
Definitely, but I'm more on the side of "This is amazing."
Most of the things that I find really frustrating are just me misunderstanding how it works and now that I understand it better, everything goes way smoother.
Even going back in time, I'd make the SwiftUI choice. It's the clear future and it's so much fun to build stuff in.
The only documentation you can count on is to just read the code. It’s all pretty well commented and the interfaces make sense. I’d say the difficulty is it’s not very discoverable, and you actually have to watch the wwdc videos to learn the high level concepts. The only discoverability you get is just surfing around, reading the code. I think it’s all in SwiftUI though, which is obviously a huge file.
I can't comment on the documentation, because there isn't any. The closest thing you get is the WWDC videos from the past few years where most things are outdated anyway. There's also lots of third party tutorials and what not that open with "Apple doesn't say anything about how this works, but I think I might have figured it out". And a lot of those third party sources are pretty good, but still. It's hardly ideal.
There are also a lot of inscrutable little edge cases where something just doesn't work, and there's hardly any path to figuring out why. Scrolling performance will tank, for example, after some trivial change. The framework "works like magic", until it doesn't. And you're stuck tweaking random things hoping something makes a difference.
BUT, at the same time, it's awesome. Code reuse is like, a real thing this time, not just something that works on paper but not in practice. You can compose things very quickly and succinctly, and you no longer have the unreadable, un-mergeable, unsearchable, existential nightmare that was storyboards. When it works, it really is fantastic. Don't count on the "live preview" though. That thing never works for anything other than the most trivial of examples.
If I could go back to 8 months ago, I probably would have chosen differently. But it is clear that SwiftUI is the future, and within a year or two it will be unequivocally better than UIKit. So if you're starting now... maybe. Just be prepared for some pain.