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.
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.
> 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.
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)
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.
Where it works, SwiftUI is indisputably the most compact and maintainable form of data bindings and auto-layout that you have. It should be used immediately for those working cases.
It is therefore critical to also learn the bridges (e.g. how to get a platform-specific view or controller out of SwiftUI) because you will also want those somewhere.
Note, I have seen Herculean attempts on blogs, etc. to shoehorn ungodly amounts of hacks into SwiftUI objects to get certain behaviors that don’t exist yet; That Is Wrong. Do not fight this framework; either use a native element with full functionality and a bridge, or a succinct SwiftUI description. It is clear that “someday” everything will have a nice SwiftUI version and it isn’t worth faking it for now wherever it doesn’t work yet.
What I don’t understand is why Apple made accessing the underlying UIKit/AppKit elements such a fight in the first place. They knew they couldn’t encompass the full breadth of these frameworks in many years to come, so why not allow easy access to underlying implementation details, to allow fine tuning for those that want/need it. Really dumb decision making, but that seems to be a lot of what Apple is doing in the last few years.
I think the author put it best with "If you've undergone the mental paradigm shift, the productivity gains were worth the minor setbacks, which really weren’t so hard to fix."
My career has included periods where I had a React day job and a bunch of iOS side projects. So many times, I'd come home from work, stoked on React, and look at iOS and wish it were declaratively already. I actually took a stab at an open source, declarative UI library that's still on GitHub.
SwiftUI, IMO, brings the smarts of React, with many dashes of magic that only Apple HIG magic that only Apple could come up with. Definitely, there are plenty of holes today, but I never, ever, ever have to hook up a UITableViewDataSource and a UITableViewDelegate ever again, and for that I am infinitely thankful.
Looking purely ahead at SwiftUI and what it will do for Apple platform years from now. I recommend anybody who is thinking about it to try it out.
Soon enough, I'll forget the signatures of the UITableView stuff, and other UIKit stuff, happily.
“Unlike a collection view, all items will be loaded into memory at once.”
I recently had to rewrite a UIView where the dev implemented a 3 by 30 scrollable image display only using StackViews. Despite image disk caching it took forever to load, the table was a veritable forest of spinners for 30 seconds. Re-Implementing as CollectionView only partially improved the display, eventually I had to add a memory cache to make it snappy.
I’m at start of switching to SwiftUI right now for a new project and these are the kinds of edge cases that worry me. But as long as I can build UI in UIKit too I’m okay with it. Build the 90% that is easy on SwiftUI, and the 10% performant pieces in UIKit and I should still be much faster.
Nothing like being blamed for endemic updating problems for months while pulling your hair out trying everything to solve them. Then to have the React lead quietly say “oh, I found the problem” during an offsite. The rest of the company never remembers that, just the months of the iOS team looking incompetent.
This is so far a piece of cake by comparison, with far higher code quality.
SwiftUI is pretty and a pleasure to work with when you want to do something that is expected. The moment you need something more, SwiftUI is not your friend anymore. Too much is hidden away in internal implementation details and much of it is broken, incomplete or completely missing. It may be adequate on iOS, but on a Mac it is nowhere near usable at this stage.
Agree with all the comments here. Once you get your head around it, it’s fast and capable – until you run into a corner case it doesn’t support (attributed text was the big one for me). Then you end up needing to wrap UIKit, which is straightforward except there is a new set of corner cases to deal with, eg. content sizing, embedding in native scroll views, etc. It all does work in the end but it takes a while to get there, and I know I’ll be replacing a lot of code as SwiftUI evolves. Having said that, it’s probably a better situation than releasing a half-baked but more featured framework.
I'm using it in production, but a few situations that I could handle with autolayout constraints seem impossible in SwiftUI. Examples here: https://developer.apple.com/forums/thread/664283
In these 1% cases, I can make things "good enough" by hacking it with SwiftUI. But it bothers me. Sometimes I want to go past "good enough" and reach for "perfect". I could do that with UIKit/AppKit, but with SwiftUI they haven't documented (or created) the layout system to allow it.
I have two apps in the Store built with SwiftUI, one ported from UIKit and the other started from scratch in SwiftUI. I’ve been “all in” since it’s announcement in 2019, despite suffering through it’s growing pains. I really wish the framework was opened up or at least distributed separately to OS updates, watching how open and quick the Android team are with Jetpack Compose really shows the different approaches to library development and Apple’s feels really outdated.
With the little experience I got, I agree with mikenew's comment. SwiftUI felt like an expressive way to define UI elements, but I had some small weird details that took long time to solve, perhaps because I defined something in a way that wasn't supposed to. Ultimately, I mostly got the code to look in the way I preferred, but for example regarding animation or gestures there were some problematic details I didn't want to spend time to get exactly right.
Overall I enjoyed it much more than UIKit but I would hesitate to use it in the future in a professional setting without properly investigating how mature it is at that point of time.
Thank you for pointing out the Stanford lectures. I wasn't aware of them and they look really good to get up to speed. I messed around with SwiftUI a while back but I haven't for the past year, so those should help me get back into it.
The game looks very impressive for being new to iOS. If you haven't looked into it yet, I recommend learning SpriteKit as well. Its animation system (SKAction) is pretty nice. I actually ended up basically re-implementing it in C# for another game I was working on, since it wasn't terribly hard to do (got the subset of actions I needed working in a couple of hours), and you can be very expressive with it, once you grok groups and sequences.
I spent a year building an app from scratch in pure SwiftUI.
The first few month were difficult because of the bugs and missing doc.
But then it got refined and enhanced. I could do almost everything I wanted with it and this years release brought well waited features.
Big Mountain Studio’s work on documentation and lots of blogs with nice articles (swift with majid) it’s possible to get a good grasp on the subject.
It’s definitely the future and a real joy to work with, definitely so in new projects.
> As of June 2020, Apple Reports that 92% of devices introduced in the last 4 years use iOS 13, while 81% of all devices (including the oldest) use iOS 13. Some businesses are not willing to part with that remaining 8%-19% of users.
I'm surprised that so many people have the latest iOS. I was reluctant to use SwiftUI because I thought that more people have older iPhones which wouldn't support it.
iOS users who don’t upgrade to the latest iOS versions are far less likely to spend money on APIs than iOS 13 & 14 users. That 19% accounts for closer to 5% of actual App Store sales and subscriptions.
I suppose when they were dropped in iOS 12 it wasn’t nearly as old. They’ve done well to keep the same devices supported since then.
You probably don't want to buy a new phone again, but I recently went from an SE (2016) to a 12 Mini and can tell you it's a pretty great device. If the new SE feels too large, you might like it too. More expensive, of course.
For a new app, it is a no brainer. I've been coding up an interface in SwiftUI in the last week that would have taken me ages with UIKit. And the resulting interface is so much better, because tuning a small detail corresponds to a single line or two instead of the agony of spinning up a new UIViewController ...
If you want your new app to be more than just a simple view, have polish, have acceptable performance in simple use cases, then it is quite the “yes brainer”. SwiftUI has considerable shortcomings, very real and unfathomable limitations, and many, many performance issues. You might be fooled by how quickly you can come up with a skeleton interface, but that doesn’t make an app. Especially for people who are coming from “React” as many have said here, once they hit those limitations, they would be fish out of water, just like React Native “developers” are dumbfounded what to do once their app doesn’t work as expected, or slows down seemingly inexplicable.
SwiftUI is a nice experiment, but it’s not a serious UI framework, and won’t be for a very long time.
It is a very serious UI framework. People from React (I am not one of them) just understand this better, because they know that the reactive approach is superior for UI. People who have not experienced that have often a problem grasping this simple fact.
SwiftUI has annoying bugs. I haven't hit performance issues yet. But if you encounter these issues you can always escape to UIKit. I already did several times, I have my little set of SwiftUI components already which replace the original ones. For example, Image is a buggy component which doesn't display SVG assets properly. I made an XImage component which fixes that.
On the other hand, doing everything in UIKit from the start is just a waste of developers resources. My time is too precious for that.
For now. It’s still a first class citizen receiving the full attention & buy in of the platform to a level even Swift itself didn’t receive this early on AFAICT (iOS 14 widgets can only be written with SwiftUI).