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.
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.
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.
> And Josh Schaffer who led UIKit also leads SwiftUI now.
This makes it sound like GP's theory is at least plausible
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...
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)
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.
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.
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.
I’ve even made the entire App Maker app inside SwiftUI to prove to myself just have viable it is.
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.
Also yes, the documentation is terrible.
A few things I found helpful - https://gist.github.com/lhoward
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.
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
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.
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.
The app I built is bulletweek.
well, thats a dealbreaker if i ever saw one... i wonder if this is "just a bug" and gets fixed in an ios 14.x update...
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.
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.
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.
SwiftUI is a nice experiment, but it’s not a serious UI framework, and won’t be for a very long time.
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.
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.
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.
Introducing text-shadow on code blocks does not add to readability.
Using low contrast color schemes does not add to accessibility.
The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code.
iOS should be a second class citizen.
Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.
Our field, ethics, and freedom take priority over users. If they don't, you should reevaluate what you're doing.
In servicing those concerns, users will win.
Just like Swift, I foresee SwiftUI being a black sheep for a very long time.