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.
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.
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.
“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.
So far it reminds me of a version of React not crippled by JavaScript. I once spent a year on a React Native project as iOS frameworks lead, and it was a nightmare. Terrible build problems every time they added new libraries, and debugging problems that crossed the Swift/React boundary was at times nearly impossible.
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.
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've been using SwiftUI for macOS and iOS fully to make stayinsession.com
It's my first app while I'm learning Swift. Coming from React, the transition is relatively easy. I did learn some UIKit and AppKit and find it extremely verbose.
The thing is SwiftUI is not really ready for prime time. There's a lot of bug and inconsistencies here and there. Things that work on iOS doesn't work on MacOS. Vice versa.
Keyboard navigation and input focus sucks.
Minor update (like from iOS 13.1 to 13.2) could break some part of the app.
Also performance is not optimized. I have a slideshow that took at least 10% CPU on Mac all the time. That limitation makes me decides to use animation sparingly across the app.
But again, the productivity is no brainer.
Basically my iOS and macOS app lives in monorepo because there's ~95% code sharing.
My personal experience: after working on existing UIKit application for over a month or so, I spent a couple of weeks trying SwiftUI out in last summer, by first watching most of the Stanford's great SwiftUI iOS lectures https://www.youtube.com/watch?v=SIYdYpPXil4&list=PLpGHT1n4-m...
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.
If anyone is interested, here's the Shogi app I developed, intended for two local two players, and as a reminder I am quite new to the iOS ecosystem: https://github.com/EvidentSolutions/toodim
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.
Thanks to
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.
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.
Most of what I like about SwiftUI is the syntax. I wonder if I'd be better off using Swift function builder syntax to build UI/NSView hierarchies and layout.
> 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 adoption rates are extremely high these days, especially with the long support periods devices get and various ways to reduce friction while updating.
As per this Wikipedia article[1], more than 2 billion iOS devices were sold by September 2018. 19% of 2B is 380M devices. So by going iOS 13 only quite a few potential users are left out.
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.
iOS 14 support goes back to the 6S and original SE, so the newest unsupported phone is the iPhone 6 from September 2014. Not a lot of those still around.
Just for the anecdote : as an owner of an iphone6, i have to say this phone was perfectly functional. it made me feel extremely bad to buy a se2 just so that i could test my code on a real device.
moving from iphone6 to se2 is the first time i've felt disappointed by my new iphone. it's bulkier, the battery lasts about just as long, and the screen feels cheap.
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.
Giving my users a good experience is the most important point.
If I give them no experience at all because I cannot get a product of excellent quality done in feasible time would be the worst of all experiences for them.
I am pretty sure given the same amount of time, what you can get done in UIKit will be less and of inferior quality compared to what I will get done with SwiftUI + UIKit where necessary.
I think the important thing to say is that there are already APIs which are SwiftUI only. This trend will definitely continue and in (near) future you won't have much choice.
While SwiftUI definitely lacks some finer customization of default elements (like the mentioned hairlines in the List/Form view), you can re-implement any UIKit view yourself in the end.
Lazy loading is perfectly doable, I think the author could have shown an example on how to do the carousel properly with a full example of the UIKit code.
And let the user experience of the paying users suffer due to the completely uncanny valley and frankly second tier implementation of the cross platform toolkits?
Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.
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).
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.