[HN Gopher] Should I use SwiftUI in production? A code-to-code c...
___________________________________________________________________
Should I use SwiftUI in production? A code-to-code comparison to
help you decide
Author : danielwbean
Score : 45 points
Date : 2020-11-21 18:18 UTC (4 hours ago)
(HTM) web link (triplebyte.com)
(TXT) w3m dump (triplebyte.com)
| yoz-y wrote:
| 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.
| [deleted]
| lukeh wrote:
| 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.
|
| Also yes, the documentation is terrible.
|
| A few things I found helpful - https://gist.github.com/lhoward
| lupinglade wrote:
| 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.
| bartvk wrote:
| How did you find out about this?
| lupinglade wrote:
| First hand experience.
| lunixbochs wrote:
| I think UIActivityIndicatorView is just:
| ProgressView()
| .progressViewStyle(CircularProgressViewStyle())
| rnikander wrote:
| 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.
| [deleted]
| Jakobeha wrote:
| > 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.
| wlesieutre wrote:
| 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.
| saagarjha wrote:
| iOS adoption rates are extremely high these days, especially
| with the long support periods devices get and various ways to
| reduce friction while updating.
| jonplackett wrote:
| Plus the constant, never-ending nagging!
| pritambarhate wrote:
| 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.
|
| [1]
| https://en.wikipedia.org/wiki/List_of_iOS_and_iPadOS_devices
| dilap wrote:
| Though I wonder what fraction of those people are interested
| in installing new software? I wouldn't be surprised if it was
| pretty small.
| moonchild wrote:
| Maybe. On the other hand, maybe they're likely to engage
| more with the few apps that still support their version of
| ios.
| auggierose wrote:
| I doubt all of those sold devices are still functional.
| shinycode wrote:
| 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.
|
| The app I built is bulletweek.
| mushishi wrote:
| 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
| makecheck wrote:
| _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.
| philipyoungg wrote:
| 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.
| auggierose wrote:
| 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 ...
| rnikander wrote:
| 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.
| anupamchugh wrote:
| I'd love to see a SwiftUI's API implementation for AVFoundation
| in their next iteration. Building camera based SwiftUI apps would
| get much easier.
| svntid wrote:
| 1 min glance and I came to the conclusion that I should not use
| it - thanks cowboy
| mikenew wrote:
| 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.
| ollysb wrote:
| 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.
| jrsj wrote:
| 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.
| plorkyeran wrote:
| 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.
| rnikander wrote:
| 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.
___________________________________________________________________
(page generated 2020-11-21 23:00 UTC)