[HN Gopher] SwiftUI in 2022
___________________________________________________________________
SwiftUI in 2022
Author : mpweiher
Score : 270 points
Date : 2022-05-25 13:39 UTC (9 hours ago)
(HTM) web link (mjtsai.com)
(TXT) w3m dump (mjtsai.com)
| tikimcfee wrote:
| $0.02 on this is that I see a great many people doing the typical
| "all or nothing" with SwiftUI. I think this is a mistake. Like
| every single other engineering tool in existence, this one has
| costs and benefits.
|
| For the people saying it doesn't work: use UIKit for those
| pieces.
|
| Otherwise, use it where it makes sense, and no more. I see this
| in Compose in Android too - lots of devs doing wholesale
| refactoring to replace components. Bad move.
|
| SwiftUI is powerful and offers a new way of defining the
| interface that is focused on the expressiveness it offers to
| devs. UIKit is just a modified version of that trade off : it
| offers less expressiveness for more power and sometimes
| correctness.
|
| Mix your poisons, don't pick them.
| tarentel wrote:
| I think trying to re-tool an existing app to be swiftui is a
| mistake. Replace swiftui with anything and it's a mistake. But
| swiftui is marketed as a replacement for UIKit and it doesn't
| seem to work. If I was starting a new app it still seems like a
| bad idea. Every attempt my team has made to make even small
| components in swiftui has been a disaster.
| tolmasky wrote:
| I think this hides the actual pitfalls: it is possible to be
| lulled into thinking SwiftUI is the right tool, only to
| discover that a minor UI change is impossible, leaving you with
| little option than to dump it entirely for the component in
| question and rewrite it from scratch in UIKit or AppKit. It is
| a truism that you should "choose the best tool for the job".
| Yes, of course. You definitely shouldn't choose the worse tool
| for the job after all. The tricky bit has always been in
| determining _which tool is best for the job_. Once upon a time
| the answer was easy, there was only one tool, and critically,
| it was the tool Apple themselves dogfooded for their own stuff,
| so it was usually at least _capable_ of doing most things. In
| the age of AppKit /SwiftUI/Catalyst, this is a significantly
| more difficult question, and this is ignoring things like
| Electron, etc. The problem with SwiftUi is precisely that if
| often feels like you only know if it was the best tool for the
| job _after the fact_. It requires being an expert in it before
| you can predict its limitations (which often are bug-related
| and not necessarily "conceptual"). This would maybe be
| excusable for a beta release, but SwiftUI is now around 4 years
| old.
|
| Arguably, its original sin is simply not being open source, and
| on top of that is trapped behind one of the most opaque bug-
| reporting mechanisms in the industry. Every minor hack involves
| tremendous reverse-engineering, which may then have to be
| replicated throughout the community, instead of being a GitHub
| issue and PR request like in Electron for example. There are of
| course upsides to the closed-source model, but in 2022, you
| have to _deliver_ on those upsides if you want to make a strong
| case for your framework. But as I 've mentioned above, SwiftUI
| hasn't. It has none of the aura or magic of AppKit from the
| 2000's: a framework _used by amazing apps at Apple_ that can
| get just about anything done. In fact it is the poster child of
| all the downsides of this model.
|
| And this doesn't even touch on the fact that Apple seems to
| repeatedly demonstrate that they don't take these technologies
| very seriously:https://twitter.com/stroughtonsmith/status/15294
| 383578346332...
| ragnese wrote:
| To be fair, though, I feel like the difference between SwiftUI
| and UIKit or XIB is much bigger than the difference between
| UIKit and XIB.
|
| I don't have much practice with SwiftUI since I have to support
| some older iOS devices, but how awkward is it to do navigation
| between screens implementing with SwiftUI Views and those using
| UIViewController and friends? How does UINavigationController
| work into all of that?
| jshier wrote:
| XIB? xib files are used in UIKit apps, alongside storyboards,
| but they're simply serialized views, not a different
| architecture or paradigm.
| ragnese wrote:
| Yeah, sorry. I wasn't being precise. When I say "UIKit" I
| mean what iOS devs usually refer to as "programmatic views"
| where you do all the UI stuff in Swift code files rather
| than the UI Builder and Storyboard tools that Xcode offers.
|
| I'm sure SwiftUI is UIKit underneath, too, for what it's
| worth.
| happytoexplain wrote:
| If you use SwiftUI at all, the app has to start with the
| SwiftUI lifecycle (Edit: May not be true, see replies). But
| then you can wrap any UIView or UIViewController in a SwiftUI
| wrapper (UIViewRepresentable and
| UIViewControllerRepresentable). So that view/controller will
| be presented by SwiftUI's navigation logic, but inside that
| view/controller, you can write a whole UIKit app if you want.
| ragnese wrote:
| Cool. Thank you for that. I've got through the SwiftUI
| tutorials and stuff, but I've never tried to make a real
| project that mixed both approaches, so I had no idea about
| UIViewRepresentable, etc.
|
| I think that adds to my point that SwiftUI isn't something
| that's very amenable to "just use it where it's
| appropriate", or "gradually try it out by migrating a small
| part of your project", etc. It sounds like you have to
| commit to "this is a SwiftUI app now, and we can integrate
| with old stuff if/where/when we need to".
| Willamin wrote:
| You can absolutely slowly migrate a UIKit project to
| begin using SwiftUI - it's part of what I've been doing
| at work for the past 8 months.
|
| The way to cross the boundary from UIKit to SwiftUI or
| SwiftUI to UIKit (either direction) involves implementing
| one or maybe two classes/structs and is not too difficult
| to do.
| ragnese wrote:
| Fair enough. I saw your reply to the grandfather comment
| and I asked some follow up questions there. Thank you. :)
| Willamin wrote:
| Part of that is untrue. You can add SwiftUI to an app that
| starts with the UIKit lifecycle.
|
| In fact, you can jump back and forth between UIKit and
| SwiftUI as many times as you like throughout your app's
| view hierarchy.
|
| The current project I'm working on involves slowly porting
| an older UIKit+Storyboard app over to SwiftUI, so I'm
| seeing this in practice every day.
| happytoexplain wrote:
| Thanks, I didn't know that!
| ragnese wrote:
| What's involved in the "jumping back and forth"? Is it
| pretty cumbersome or no? Do you use a
| UINavigationController at all in your app, or do your
| UIViewControllers do all of the navigating/presenting
| themselves?
| Willamin wrote:
| We do use UINagivationController in our app, so that's no
| issue.
|
| Crossing the boundary from UIKit to SwiftUI involves
| instantiating the SwiftUIView, handing that over to a
| UIHostingController, then presenting that controller.
| Something like this: let myView =
| MySwiftUIView() let hostingVC =
| UIHostingController(rootView: myView)
| navigationController.present(hostingVC, animated: true)
|
| Crossing the boundary from SwiftUI to UIKit is slightly
| more boilerplate to write, but it's not too bad. You have
| to implement either a UIViewControllerRepresentable or a
| UIViewRepresentable (depends on your needs). Those
| protocols only needs two functions defined:
| makeUIView/makeUIViewController and
| updateUIView/updateUIViewController. For the simplest
| views and view controllers, you can leave the update
| definitions empty.
| xbar wrote:
| This is good advice that I should follow more.
|
| But it doesn't address the part where devs find SwiftUI buggy
| and non-functional where there is a promise of functionality.
| zerkten wrote:
| When you support a range of tools, or introduce a new one, you
| often do it to support different audiences. I'm not an iOS dev.
| Is it a case that SwiftUI is really intended for a different
| audience and set of use cases with no expectation of a 100%
| overlap with the UIKit use cases?
| tarentel wrote:
| It's marketed as a complete replacement of UIKit.
| aaaaaaaaaaab wrote:
| Trust me, noone at Apple believes that. Not even the
| SwiftUI team.
| zerkten wrote:
| What do the folks in the know believe it is?
| aaaaaaaaaaab wrote:
| Mostly a shiny tool to lure in beginners and web
| developers.
|
| Kind of like Duplo vs Lego.
| LeicaLatte wrote:
| If your devs say they are faster with SwiftUI, your app is
| probably dumber than you are willing to accept.
|
| I have been writing ObjC, Swift for 7 good years. Me or my team
| will never write anything important in SwiftUI until Apple starts
| to adopt it non trivially. Blogs, Twitter threads != production
| code. Teams hate workaround driven development.
| tarentel wrote:
| Is anyone using this really? My team is pretty excited about
| using it but I've been a little more hesitant mostly because I've
| not read of anyone using it at any sort of scale with success.
| Even for smaller project it still doesn't seem production ready.
| Willamin wrote:
| I'm using SwiftUI extensively when I get the opportunity. The
| team that I'm on has decided to shift our UIKit+Storyboards app
| towards leveraging SwiftUI more. It won't work for 100% of the
| app, but that's alright because there are easy-to-implement
| escape hatches back into UIKit.
|
| The worst part of the dev experience is that we are currently
| supporting back to iOS 13 (which is when SwiftUI was
| introduced). That means we can only really use the oldest
| SwiftUI components and modifiers; it's not too bad, but finding
| usable examples online is tricky sometimes (they often assume
| the latest).
| emehex wrote:
| I just finished a contract on an app with 400K users.
|
| It was in pretty bad shape when I got my hands on it. Last
| update: February 2020. Targeting iOS 11+, mostly UIKit, powered
| by Cocoapods with 25 dependencies, and 1.3M LOC.
|
| It took me 3 months to rewrite everything from scratch in
| SwiftUI, with 100% feature parity. Of the ~20 different
| view/components that I had to write, just one required me to
| dip into UIKit (with UIViewRepresentable to bridge).
|
| Now the app is iOS 14+, 5 dependencies (all managed with Swift
| Package Manager) and 6.5K LOC, with 0 crashes in the last
| month.
|
| SwiftUI is production ready.
| tomovo wrote:
| Wait, it went from 1.3M LOC to 6.5K? Was the UI layer really
| that bloated or are you counting the 3rd party dependencies?
| I envy you the 3 months without adding any "customer value"
| (not joking, I'd love that).
| emehex wrote:
| Yeah. 1,300,000 to 6,500 (not counting the dependencies).
| While the previous devs obviously had programming
| experience, it was clear they were quite green in
| Swift/iOS.
|
| Customer value was that the OG app was crashing like 1 in
| every 6 uses. Updated app was crash free. Plus, added two
| new features during the rewrite.
| rudedogg wrote:
| It is frustrating at times, but I like writing UI in code and
| it increases my productivity quite a bit. I'm using it to build
| an IDE (https://austinrude.com/devlog/zig-ide-2022-04/).
|
| I don't think I would have attempted a project this large
| without it. I had to fall back to AppKit/NSViewRepresentable
| for the tabview, text editor, and a couple other views. There
| are probably over a hundred SwiftUI views though. And I am
| hoping I can switch the tabview to SwiftUI after WWDC so it's
| easier to extend.
|
| About WWDC, I wonder if we'll see a CoreAnimation replacement
| this year that is exposed to SwiftUI views? I don't know what
| the implications would be, but it makes sense when you look
| back at how they've refused to offer/expose the underlying
| UIKit/AppKit APIs that SwiftUI is wrapping for some controls.
| emehex wrote:
| I'm an iOS contractor, and do most of my work in SwiftUI. Sure
| the framework has it's warts, but I honestly love it.
|
| Shameless plug -> I recently open-sourced an app showcasing how
| to use effectively use SwiftUI + MVVM:
| https://github.com/maxhumber/BreadBuddy
| alexashka wrote:
| If you like SwiftUI, I challenge you to a SwiftUI fizzbuzz:
|
| a square, screen width, 10x padding, red background.
|
| inside it, a little square, centered and a little square, top
| left corner, 10px padding, blue background for both.
|
| Tell me that was easy, so that I know you're lying :)
| saagarjha wrote:
| How's this? It's not quite "screen width" if you make the
| screen wider than it is tall, but I could make it stick to that
| if you really want I guess. struct ContentView:
| View { var body: some View { ZStack {
| Rectangle() .fill(Color.red)
| Rectangle() .fill(Color.blue)
| .frame(width: 100, height: 100) HStack {
| VStack { Rectangle()
| .fill(Color.blue) .frame(width:
| 100, height: 100) Spacer()
| } Spacer() }
| .padding(10) } .aspectRatio(1,
| contentMode: .fit) .padding(10) }
| }
| alexashka wrote:
| Your answer is wrong. You've failed the fizzbuzz :)
| emehex wrote:
| Perhaps you can post a photo of what you're looking for?
| Because your instructions aren't super clear :)
| saagarjha wrote:
| I generally expect interviewers to tell me what the problem
| is ;)
| alexashka wrote:
| My apologies, you've successfully passed FizzBuzz, in a
| rather unwieldy way by relying on nesting vstacks,
| hstacks and adding spacers.
|
| The larger point being - placing squares on a page went
| from drag and dropping and setting a few constraints, to
| now doing zstack/hstack/vstack/spacer wizardry.
| emehex wrote:
| Took me 5 minutes. Copy and paste this into a playground:
| https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c...
| b3morales wrote:
| Now please see how it looks on a device:
| https://postimg.cc/crtKHSTG
| [deleted]
| alexashka wrote:
| Your answer is wrong. You've failed the fizzbuzz :)
|
| Change frame (screen width) to 300, 500 to see why.
| emehex wrote:
| Good catch. Fixed with an extra ZStack.
| alexashka wrote:
| GeometryReader was not part of fizzbuzz. Replace
| geo.size.width * 0.1 with 10 to see your code break.
|
| Now tell me, _why_ did it break? Do you even know?
| Because I don 't.
|
| I don't know why half the shit works as it does, and I've
| written non-trivial SwiftUI code for 6 months. I did not
| have this problem with UIKit and interface builder.
| emehex wrote:
| GeometryReader is a pretty critical part of the SwiftUI
| framework. I'd recommend getting familiar with it!
|
| Saying "you can't use GeometryReader" would be like
| saying you can't use UIKit's Auto Layout...
| [deleted]
| bze12 wrote:
| Most of these negative comments are coming from veteran UIKit
| developers who then tried out SwiftUI. Of course they're only
| going to notice the things that are overwhelmingly harder
| compared to UIKit - they have years of bias. Imagine if SwiftUI
| came out first, then Apple released UIKit. Wouldn't there be
| another long complaint list from these developers?
|
| I started developing with UIKit for a year, hated it, then
| switched to SwiftUI and have built multiple apps over the past
| few years. IMO the "last 10%" bugs are not that big of a
| detractor compared to the benefits. Of course some of this is my
| bias; I'm more likely to spend time trying Stack Overflow hacks
| on SwiftUI bugs when the UIKit solution is better. I have to
| "work with the grain" sometimes if something just isn't possible
| in SwiftUI, but I'm fine making that tradeoff. I feel lucky not
| having the bias of years of UIKit, it's hard to let go of
| something when you're so used to it. I'm also lucky to not be
| working on apps with backwards compatibility issues, but I do
| think SwiftUI is the way to go for new consumer startups.
| makecheck wrote:
| Lots of great and specific points in these threads, many of which
| I have personally seen.
|
| SwiftUI was _really_ promising at first, and even fun to use
| (nothing like ripping out entire UI files or pages of code). Yet,
| issues were almost immediately apparent.
|
| A major concern is that it seems to take Apple a really long time
| to address even basic issues, e.g. years go by and things still
| broken since day 1 are there, while other things are randomly
| introduced. And of course, "Feedbacks" have the usual dice-roll
| effect: will you even _get_ a response, much less see any
| indication that the reported bug will ever be fixed? (Or will
| Apple just wait 2 years, close your bug as "probably fixed in
| this OS update, please confirm", and repeat the whole thing?)
|
| And the thing is, this is not hard to believe. If you auto-
| complete in SwiftUI (what else can you do, there is rarely good
| documentation?), some of the APIs are truly scary: levels of
| complexity and variation that really make me wonder if they can
| _truly_ test, much less _support_ , every variation of every API.
| I would strongly argue that some things just have _way_ too many
| options instead of a handful of clear starting points.
|
| SwiftUI also occasionally changes behaviors (e.g. subtle or gross
| layout differences). Worse, it is easy for Apple to not call any
| of these changes "breaking" because apparently you are just
| supposed to let SwiftUI figure out what is needed in any
| situation. Except that kind of "trust us, we'll come up with
| something" approach is not great for writing stable production
| software.
|
| The auto-generated hierarchies can do truly weird things. For
| example I realized at one point that an "auto-saved" window
| layout auto-generated preference names based not on a simple
| string but _the entire SwiftUI view hierarchy_ , which was _huge_
| and indecipherable and of course would become a _different_ value
| if _any_ part of the window or view hierarchy was modified. So I
| discovered I had dozens of preference settings scattered
| throughout my defaults, 99% of which were completely obsolete
| because they were based on previous incarnations of the view I
| was developing, _and_ they all had names that were almost
| impossible to type (so how do I delete them while preserving the
| rest?). What do you even do with that?
|
| Yet _another_ major concern is that SwiftUI is very dependent on
| Combine which is not _necessarily_ the future given other
| developments in the Swift language. So what if they just decide
| to, say, deprecate Combine and move further toward actors and
| async APIs? How much of SwiftUI might just fundamentally change
| in, say, WWDC this year, completely invalidating years of effort
| people have put into it?
| Willamin wrote:
| > deprecate Combine and move further toward actors and async
| APIs
|
| Combine is an abstraction to encapsulate changes in state over
| time, while actors and async APIs are abstractions to
| encapsulate concurrent behavior. I think these are orthogonal
| concerns, so they wouldn't likely drop one in favor of the
| other.
|
| > SwiftUI is very dependent on Combine
|
| As someone who's been writing SwiftUI a lot over the last year
| or two, I've only touched Combine a few times. Even then, I
| only tried it because I wanted to see how it compares to
| RxSwift, not because it was something I needed.
| saagarjha wrote:
| Yeah I've never used Combine and I've written a decent amount
| of SwiftUI. My impression is that Swift Concurrency is the
| future and will slowly get more and more adoption in the
| APIs.
| kitsunesoba wrote:
| > Yet another major concern is that SwiftUI is very dependent
| on Combine which is not necessarily the future given other
| developments in the Swift language. So what if they just decide
| to, say, deprecate Combine and move further toward actors and
| async APIs? How much of SwiftUI might just fundamentally change
| in, say, WWDC this year, completely invalidating years of
| effort people have put into it?
|
| If you're talking about Combine vs async/await, I think they'll
| continue to coexist because they fill different niches. In the
| UIKit app I'm responsible for I use both -- async/await for
| things like network calls and Combine for keeping UI state in
| sync with data.
| Larrikin wrote:
| My team has two green field apps that we started a few weeks ago.
| The leads on the iOS team and Android team both spent a week
| evaluating the new UI systems in each platform, SwiftUI and
| Jetpack Compose.
|
| The conclusion was that Apple made a huge mistake tying it the
| iOS version and effectively limiting updates and it's real world
| use for years at a time.
|
| Both leads liked the design paradigms, but we are only going to
| use Jetpack Compose since it's made of multiple libraries that
| are all backwards compatible with our minimum supported version.
| iOS will stick to UIKit since it works and is backwards
| compatible
| sethd wrote:
| > The conclusion was that Apple made a huge mistake tying it
| the iOS version and effectively limiting updates and it's real
| world use for years at a time.
|
| Exactly this. SwiftUI on iOS 13.x is practically unusable for
| anything above simple implementations, with some fairly major
| bugs that weren't fixed until iOS 14-15. Bugs aside, the lack
| of StateObject in SwiftUI (iOS) 13.x makes it a non-starter.
| jamil7 wrote:
| Yeah iOS is one thing as you can generally wait it out as Apple
| is pretty aggressive about upgrades there but on macOS I think
| this limitation has really killed it's viability, people just
| don't update their desktop OS.
| NonNefarious wrote:
| Not to mention that Apple just orphaned a shitload of
| perfectly viable computers (first-gen Retina iMacs, for
| example).
|
| I was also baffled to find that TestFlight can't be installed
| on pre-Monterey Macs. I mean... WTF? That makes no sense.
| Sure, we can pass DMGs around, but my company is new to Macs
| and standardizing our QA team on TestFlight on all devices
| would've been simple.
| seanalltogether wrote:
| I really wish Apple had spent more time updating the limitations
| of UIKit before introducing SwiftUI. Stylesheets are the most
| obvious piece missing, but even adding a simpler layout model
| would be a big quality of life improvement. I'm often faced with
| a storyboard where i have to blow away half the constraints to
| add in a new feature to the existing layout. On android I've
| never had to do this.
| bsaul wrote:
| i don't see how apple think swiftui can compensate for not being
| cross platform.
|
| At thid point, unless you really need to reach the absolute top
| of UX, there is no reason not to go for react native, or flutter.
|
| Knowing that videogames are already developped in cross platform
| tools, it only leave a very very small market IMHO.
|
| I had hopes that swiftui would be cross-platform ( or at least
| ios + web, since apple don't want to facilitate android
| adoption), but i don't think it's going to happen now..
| dgellow wrote:
| I looked a bit of the posts on Twitter, and wow, it's really
| polarized. People seem to either love it or hate it. Is SwiftUI
| still that controversial, or is it just an effect of people
| posting on Twitter?
| ben_w wrote:
| My experience of SwiftUI is that all of the love _and_ all of
| the hate is simultaneously correct.
|
| It makes some tasks much much easier, e.g. low vision users
| really benefit from variable font sizes, which Storyboards can
| do but it feels unnecessarily hard to do in a non-fragile way.
|
| I can also see the benefits of reactive UI over the Storyboard
| approach, especially with UICollectionView and UITableView.
|
| But...
|
| The code examples, even from WWDC slides and Apple docs, don't
| even always compile; the widgets are different enough it's not
| always clear how to get to the desired UI when you're starting
| from UIKit, and the integration between UIKit and SwiftUI (in
| both directions) isn't as easy as I'd like, and you have to
| keep resuming the canvas view because it's not smart enough to
| figure out for itself when the code now represents a valid
| view.
| kitsunesoba wrote:
| > It makes some tasks much much easier, e.g. low vision users
| really benefit from variable font sizes, which Storyboards
| can do but it feels unnecessarily hard to do in a non-fragile
| way.
|
| Code-only UIKit (no storyboards or XIBs) with autolayout
| handles this case pretty well in my experience. There's a few
| gotcha's but no more than with SwiftUI. You mainly just need
| to remember to use UIFont's preferredFont(forTextStyle:) when
| setting up labels and controls.
| viktorcode wrote:
| It's new and requires different mindset than UIKit. Many times
| I was thinking "it must be broken!" only to find out later that
| I was doing things wrong. I suspect many posts on Twitter
| follow the same pattern.
|
| My advise is to try it, and learn along the way. After a while
| the idea of going back to UIKit will become scary.
| wussboy wrote:
| It's not just the effect of Twitter. It's the whole point of
| Twitter.
| [deleted]
| draw_down wrote:
| ragnese wrote:
| > People seem to either love it or hate it. Or is that just an
| effect of people posting on Twitter?
|
| I'm sure that a big part of that is the effect of it being
| Twitter. How often do we feel the urge to post something online
| that we have no strong feelings about?
|
| More on topic, though: I'm a SwiftUI hater still. It's a cool
| concept, but there are two big problems with it, IMO:
|
| 1. It's totally out of place with the rest of the Swift
| programming language. They had to add new crap to the language
| to accommodate its declarative style, when Swift is (was)
| unapologetically imperative syntax-wise. It's an obvious bolt-
| on and leaves a really bad taste in my mouth.
|
| 2. It's still a very leaky abstraction, in that there's still a
| lot of stuff you have to reach into UIKit for, whether it's for
| uncommon UI design parts or for performance reasons. As a
| polyglot dev for my day job, I loathe leaky abstractions. I
| refuse to learn two "frameworks"/"paradigms"/whatever when I
| could just use one of them and ignore the other. I feel largely
| the same way about ORMs: it's guaranteed that I'm going to have
| to be considerate of the generated SQL queries regardless, so
| why do I have to be an expert at SQL _and_ whatever complexity
| is in the ORM around caching, flushing, transactions, default
| values, etc? Ain 't nobody got time for that.
| throwaway1777 wrote:
| Not to be super rude, but why are you a polyglot dev if you
| don't like learning multiple frameworks?
| ragnese wrote:
| I don't find that to be a rude question at all.
|
| I love being a polyglot dev and I love learning and using
| different programming languages, frameworks, and app
| platforms. The issue I have is with learning _redundant_
| frameworks that don 't actually give me more power.
|
| To continue berating ORMs, I am in charge of several
| different projects at work that communicate with SQL
| databases. The set of programming languages that span these
| projects is: Kotlin, PHP, Rust, and JavaScript (being
| phased out). I love getting to switch between these
| languages (just not _too_ frequently, lest the context
| switching kills my brain), and I feel like it helps me to
| see the strengths and flaws in each, and it 's just really
| fun to find effective patterns in each.
|
| Whether I use an ORM in all or none of those projects, I'm
| going to have to be competent with SQL. But if I decided to
| use an ORM for all four, I'd have to learn _five_ different
| ways to get data in and out of our databases. Rather than
| learning four redundant, _incomplete_ , data retrieval
| "languages" that sit on top of SQL, I rather learn...
| almost anything else.
|
| I have used lots of ORMs: The Symfony one for PHP whose
| name I can't recall, Magento's weird one for PHP, Hibernate
| (Java), Sequelize (JavaScript), and a few others in other
| languages. They all have subtle issues. And they _are_
| "issues" and not just different design choices- I'll never
| _ever_ accept that Hibernate /JPA/JDBC returning a `(int)
| 0` when it encounters a null result from a nullable integer
| SQL value is anything short of lunacy when Java has a
| native null value. And they all have stupid things like
| that. Learning those gotchas, bugs, abstraction leaks,
| performance problems, etc, is not the fun kind of learning
| for me- it's just tedious and frustrating.
|
| So, to bring it back to SwiftUI, I love that I manage an
| iOS app. I like learning about how iOS works, and I like
| working with Swift. It's still required that we know how to
| use UIKit APIs for non-trivial stuff, so why would I learn
| SwiftUI (and its problems and gotchas) so that I can do 75%
| of my work with SwiftUI and 25% with UIKit APIs? It's
| possible that it would make me an even better iOS dev, but
| I doubt it (at this point). I think my time is better spent
| learning something that will allow me to accomplish tasks
| with computers that I don't already know how to do.
| draw_down wrote:
| > Conundrum: do I spend the hours required to try different
| combinations of SwiftUI modifiers to hopefully find a fix for
| this layout issue, with potential of it breaking again in the
| future, or do I spend same hours porting to UIKit knowing I'll
| likely never have to touch it again
|
| Absolute no-brainer if you ask me. Set it and forget it. Use the
| cool stuff when it works, let others beta test.
| jmull wrote:
| This has pretty much been my experience:
|
| > "Hey I got 90% of what I wanted really quick! Neat!" "...oh
| turns out that last 10% is basically impossible, eh?"
|
| (Not impossible, but it's like transitioning from a pleasant
| stroll on a comfortable downhill trail to slogging through mud,
| and dense brush, with mosquitos and biting flys everywhere.)
| czhu12 wrote:
| Genuine question: is there still a good reason to build CRUD type
| apps in Kotlin / Swift in 2022 with stuff like React Native and
| Flutter out there?
|
| Not talking about award winning, unique apps that may require
| more device specific capabilities, rather the 90% of apps out
| there that just want to offer users an easier way to CRUD into a
| database.
| topspin wrote:
| Another genuine question: is there a good reason to use a
| closed source UI framework in 2022? Given the number of high
| quality, cross platform UI frameworks available today this
| should be a consideration.
|
| Inevitably, while developing a UI, I find it necessary to
| investigate some part of the framework implementation. This is
| impossible with a closed source framework. Indeed, many of the
| complaints that appear on this site seem like exactly the sort
| of mysterious behavior one faces and might be resolved with
| access to the source.
|
| SwiftUI is closed source, correct? I made an effort to discover
| the source and it doesn't appear to be available.
| JohnDeHope wrote:
| I've written architecture astronaut code of my own, so I saw this
| coming. Swift the language, and SwiftUI the gui toolkit, have a
| classic over-engineered magnum opus style to them. The generality
| and generic-ness just leak out all over the place. I also saw a
| bit of this early on in Dart and Flutter. From what I can tell
| they seem to have charted a better course and avoided getting
| stuck too deeply in their own perfection vision.
| [deleted]
| dep_b wrote:
| I just delivered a medium complexity CRUD driven module using
| SwiftUI for a very large application.
|
| Worked perfect for me, besides issues around navigation,
| especially showing alerts. Would use SwiftUI screens using UIKit
| navigation next time.
|
| Also more complex scenarios that sing combine can get a bit more
| hairy. The most important issue is that all changes are emitted
| at didSet so the new value is not known anywhere outside of the
| closure.
| akmarinov wrote:
| Has anyone gotten SwiftUI previews to work at all with a project
| that has more than 20 files or some dependencies?
|
| My project utilizes Firebase as the backend and as soon as you
| add that dependency - SwiftUI previews never compile, due to
| build time outs.
| mamcx wrote:
| > Has anyone gotten SwiftUI previews to work ... has more than
| _1_
|
| Not JetPack or SwiftUI works for even a simple view!. Is
| _incredible slow_ and still not true to how it will show up!
|
| I miss the way Delphi do it...
| tarentel wrote:
| Nope. We have a fairly complicated project, 20+ frameworks, the
| preview feature doesn't work. We're not using firebase either.
| bryansum wrote:
| Yes, I recently built an entire app with 70+ frameworks that
| works fine in Previews. The key is to isolate dependencies into
| their own modules, and also split those into interface / live
| implementation modules if needed if the live impl causes
| preview crashes. See
| https://www.pointfree.co/episodes/ep171-modularization-part-...
| emehex wrote:
| Are you using MVVM and mocking out your ViewModels?
| gh123man wrote:
| You are probably pulling firebase into your preview code
| somewhere. You should structure your previews to depend on mock
| implementations of your model (or mock data). It will make the
| previews much faster and more reliable.
|
| My app also uses firebase and SwiftUI with hundreds of files
| (views, view models, and more) with no problems.
| emllnd wrote:
| +1 on this
|
| Got working SwiftUI previews on a 50-100k LOC project with
| many big libs as dependencies, must be hundreds of files but
| havent counted. SwiftUI code is gaining share of the total UI
| code, probably around 20-30% now
|
| Mock data is a must.
|
| Need to be mindful of the preview build (+ preview simulator
| startup) time too, sometimes it will timeout but just
| building again (now warmer) will make it work
|
| Had some initial issues around processor arch (Intel vs
| M1/arm), think I'm still running XCode under rosetta
| otherwise it wouldnt work.
| ChrisMarshallNY wrote:
| I'm really looking forward to what comes of it, but I have chosen
| to do my current major project in UIKit.
|
| A couple of reasons:
|
| 1) The documentation for SwiftUI, when I started (about two years
| ago) was _awful_. I was shocked at how bad it was. I believe that
| it has since improved.
|
| 2) I knew of no major apps (even Apple ones) that had been done
| with it.
|
| I already knew that UIKit was up to the task, and held my nose,
| while I set things up. It's working out extremely well, but (of
| course) I'd like to rewrite the whole thing (a sure sign that I'm
| approaching ship).
|
| I like things like the MVVM pattern, but it's been my experience
| that it's really not such a good idea to implement it in UIKit,
| because UIKit was designed explicitly for MVC. I have learned
| that those ugly-ass UIViewControllers are really important, and I
| circumvent them at my peril.
|
| I'm able to release fairly basic Apple apps in UIKit, in just
| hours, so speed of development isn't compelling.
|
| What is compelling, is the ability to design a reactive system
| for a complex app (like the one I'm writing now). AppKit has
| allowed this for some time, and it's possible to force UIKit to
| do it (but it isn't really designed for that).
|
| I really wish that SwiftUI had been a bit more mature, when I
| started this system, but I would have also needed to rewrite the
| two server SDKs I use, anyway. It wouldn't have worked, no matter
| how hard I bang my heels together.
|
| But I'm looking forward to it.
|
| One thing that I've learned, is that it's really OK to wait for
| things to mature. Companies always screech about how we need to
| jump on the bandwagon, but that's all hype. I have taken OpenDoc
| courses at Apple DU. I also busted my ass, getting my app ready
| for Copland. I have _scars_ from Apple hype.
|
| I did take a big chance, by jumping directly into Swift, but that
| has turned out to be a good decision.
| JamesSwift wrote:
| > I like things like the MVVM pattern, but it's been my
| experience that it's really not such a good idea to implement
| it in UIKit, because UIKit was designed explicitly for MVC. I
| have learned that those ugly-ass UIViewControllers are really
| important, and I circumvent them at my peril.
|
| I dont understand this. MVVM is an extremely abstract pattern.
| It transcends the technology stack. How it is implemented on
| the platform differs, and yes you are not going to avoid the
| UIViewController when doing it on iOS. But you are still doing
| MVVM even if your V is actually a UIViewController.
|
| I use MVVM almost exclusively now, and I usually do it in a
| cross-platform framework (Xamarin/MAUI). The codebase is
| portable across both iOS and Android with no re-architecting of
| the high-level architecture pattern.
| ChrisMarshallNY wrote:
| I liked the "cut with the grain" comment, someone made
| earlier.
|
| The UIViewController _must_ be present in a UIKit app. Most
| classic UIKit apps have the lions ' share of code in
| UIViewControllers.
|
| It's entirely possible to basically use a "skeletal" one, and
| have the main code in the linkages between the Model and the
| View, but that makes the Storyboard Editor useless.
|
| I use the Storyboard Editor _a lot_. It is not my favorite
| editor, but it allows me to work incredibly quickly, and to
| make a really reflowable UI.
|
| I know that the app I'm working on now, is larger than any
| I've seen from SwiftUI (around 40 screens, and communicating
| with three servers in realtime, using a couple of SDKs). I am
| able to make it all work.
|
| I feel as if MVVM would make the parts of the app that link
| the UI to the servers a _lot_ more graceful (it 's a nasty
| state engine, right now -ick). I feel as if this kind of app
| is the kind of thing they had in mind, with SwiftUI.
|
| I do know that it's really important to derive subclasses,
| and extend ObjC classes, when using UIKit/AppKit/WatchKit,
| and I feel sorry for folks that avoid inheritance like the
| plague. It must be a fair bit of work. Looks like SwiftUI
| doesn't really need that at all, but I haven't spent enough
| time with it, yet, to know for sure.
|
| I have no doubt that I'll end up mastering it. I'm a quick
| study. I've spent 35 years, surfing the tech wave.
| cageface wrote:
| Yeah UIKit is deeply MVC. It may not be the most conceptually
| elegant but in my experience you're almost always better off
| cutting with the grain of the underlying platform's
| abstractions instead of trying to superimpose a new leaky
| abstraction on top of them.
|
| I worked on one large iOS codebase that went all in on the
| VIPER architecture and it was one of the most unweildy and
| baroque codebases I've ever had the misfortune to work in.
| bsaul wrote:
| i've been developping for 20 years, and 10 years on iOS as a
| freelance.
|
| I've seen all the horrors, and i can now safely claim that
| all the problems i've seen on iOS development come from not
| designing the model layer properly in their MVC app. Because
| most developers start by coding UIs and later end up
| wondering where to put that business logic and make it
| reusable.
|
| And now every time i see another pattern that claim to
| facilitate refreshing the UI upon model change ( and vice
| versa), i know it's going to be a failure.
| jkubicek wrote:
| > better off cutting with the grain of the underlying
| platform's abstractions
|
| That's a great little turn-of-phrase that I plan on stealing
| in the future. Apple's APIs will absolutely reward you for
| taking the time to step back, figure out how Apple _wants_
| you to use them, and try your hardest to use them in that
| way.
|
| An example from the olden days of iOS development: many of
| the apps I worked on went out of their way to avoid
| subclassing UIView, filling their view controllers with
| layout and interface updates that would have made much more
| sense in a view. If only they had read all the docs for
| UIView would they know that doing something like subclassing
| a button and tweaking a few methods would have done exactly
| what they wanted with a minimal amount of work.
| ChrisMarshallNY wrote:
| _> the VIPER architecture_
|
| _< Takes out a foil blanket. Hands you a flask. >_
| emehex wrote:
| VIPER is horrific at scale. Don't. Just don't.
| quux wrote:
| Could be worse, they could have adopted RIBs
|
| https://github.com/uber/RIBs
| throwaway1777 wrote:
| Or ComponentKit
| nyanpasu64 wrote:
| One recurring issue I see on native Android navigation is,
| when you open an image in a file manager, switch back to
| the file manager and open a second image in the same
| viewer, sometimes pressing Back takes you to the first
| image. As a specific example, in Foxy Droid, if you
| download 3 apps in the background, get 3 "app downloaded"
| notifications, and click each one in sequence, you have to
| press Back 3 times to get back to Foxy Droid's home screen.
| What's the best way to avoid this issue without
| reimplementing your own navigation system replacing
| activities?
| tadfisher wrote:
| Basically, don't use Intent flags you don't need to use.
| FLAG_ACTIVITY_NEW_TASK will launch the external activity
| in its own back stack according to its `launchMode`
| rules. If you just launch the Intent with no flags, the
| default behavior is to add the activity to your own task,
| which is usually what you want.
|
| The other half of the equation is: don't override Back
| behavior unless you "own" the current task (it's rooted
| at one of your activities). When handling "Up" navigation
| and deep-links, you want Back to behave like "Up" and go
| to the logical parent of the current screen. When being
| launched in someone else's task, "Up" should launch a new
| task at the logical parent and "Back" should perform the
| default behavior (usually, Activity.finish()).
| tarentel wrote:
| I apologize to the people who bought into this pattern but
| what was anyone thinking? Just reading through how it was
| supposed to be done set off so many red flags I never even
| considered it. There is so much useless abstraction it makes
| no sense.
| ChrisMarshallNY wrote:
| I think it was designed to break up app development into
| large, relatively unskilled, teams. The traditional UIKit
| model (and, I suspect, the SwiftUI model) is for small
| (maybe single IC), skilled, teams.
| cokeandpepsi wrote:
| It's sometimes impossible to fight the architecture
| astronauts, they can be deeply appalled at how software
| maps to their thinking and wish to bend it towards nonsense
| until it does
| madeofpalk wrote:
| > 2) I knew of no major apps (even Apple ones) that had been
| done with it.
|
| Probably not 'major' as in 'complex', but I believed the Apple
| Pay sheet is now Swift UI
| ChrisMarshallNY wrote:
| I think that most of the smaller Apple apps are now SwiftUI
| (and Catalyst).
|
| But the app I'm writing is a good deal more complex than most
| of the utility apps, and I seriously doubt that the complex
| apps are SwiftUI. I would not be surprised if many of them
| are still ObjC.
| tarentel wrote:
| > I like things like the MVVM pattern, but it's been my
| experience that it's really not such a good idea to implement
| it in UIKit, because UIKit was designed explicitly for MVC. I
| have learned that those ugly-ass UIViewControllers are really
| important, and I circumvent them at my peril.
|
| I agree with everything you've said but this. I've worked on 3
| very large app, one which is 85% using mvvm, the two others
| were still in experimentation phases with it and I am not sure
| where they've ended up. It's been a joy. The app is designed in
| a very reactive way and the data flow paths are very clearly
| defined and easy to follow.
|
| Don't get me wrong the other two apps were heavily MVC with a
| lot of delegation and that was fine. I could easily switch back
| to an architecture like that but it's very possible and quite
| easy to switch over to an mvvm pattern.
| ChrisMarshallNY wrote:
| I have heard many state that. It has not been my experience.
|
| It may be because I want a "pure" MVVM, and it has to be sort
| of "impure" to work with UIKit apps. In that case, it just
| adds more code. I'm a "the best code I write, is the code I
| don't write" kind of guy.
| kitsunesoba wrote:
| I've been dabbling in SwiftUI in an existing UIKit app from
| time to time for a while now and have similar feelings. Even if
| you get past the lack of docs, SwiftUI is missing just enough
| bits and pieces to make it a pain. I can usually get things
| about 90% to where they're supposed to be, and then I rewrite
| it in UIKit because that's the only way to get the fine details
| right without convoluted hackery. Lack of backwards
| compatibility doesn't help here -- several times something I've
| needed has only been available for iOS 14/15+.
|
| I think it has massive potential regardless, but yes it's going
| to need some time to fully bake (much as UIKit did).
|
| It's too bad that Cocoa Bindings never found their way from
| AppKit into UIKit. I understand their exclusion was likely due
| to CPU power limitations early on, but that hasn't been a
| problem for many years at this point.
| [deleted]
| catchclose8919 wrote:
| ...no comparison with Flutter or at least remarks of what would
| also apply to it?
| frou_dh wrote:
| Wouldn't be surprised if no one quoted there has ever used
| Flutter. The Apple dev comment-sphere is quite insular.
| pornel wrote:
| It's not a surprise there's zero overlap. The type of people
| who develop native Apple-only apps _really care_ about having
| proper first-class native UI down to every detail, not merely
| something close enough. As you can see, for many even Apple
| 's own SwiftUI isn't "native" enough, so at this level of
| detail using Google's generic UI framework is completely
| unthinkable.
|
| For cases where portability or development time is valued
| more than having perfect Apple-HIG-compliant UI polish, there
| are lots of better options. Since Apple has flattened their
| Aqua interface out of existence down to mostly just gray text
| labels, even Electron apps started looking good-enough.
| hdjjhhvvhga wrote:
| > there are lots of better options
|
| Could you give some examples? Most people I talked to
| really hate React Native, for example. Ionic doesn't seem
| to have gained enough momentum. You mention Electron, but
| the last time I checked it's only for the desktop, not
| mobile. Each year new options appear, but I'm not sure they
| are that great.
| pornel wrote:
| I had mostly desktops in mind where there are more widget
| toolkits to choose from. On mobile it's not so great
| indeed. Cordova is a mobile equivalent of Electron, but
| often you can get away with your own native app shell +
| WebView.
| finiteseries wrote:
| Flutter is almost exclusively used by web developers in my
| professional and personal experience which is odd considering
| the lack of JS.
|
| The types of companies that hire iOS developers and build iOS
| apps also hire android developers and build android apps,
| again, IME.
| MrDresden wrote:
| Work for a financial institution which hired iOS and Android
| developers and had them rewrite everything in Flutter.
| finiteseries wrote:
| It's the natural move, it's just odd I've mostly seen
| adoption using web developers so far.
| lonelyasacloud wrote:
| Lept onto it from React Native when it first came out. Really
| like the core approach to layout and you get a lot of stuff for
| very little effort (if you do it Apple's way). Whether it makes
| sense I think depends on the platforms being targetted.
|
| On recent versions of iOS it's capable of doing 99% of the stuff
| I'll ever want to do and it will look nice. Just as long as I
| don't want to step too far outside of what Apple thinks is the
| right way (tm).
|
| macOS - on the other hand - is far more more buggy/inconsistent
| e.g. Focus with List's of TextFields. It is also missing a lot
| pretty basic macOS functionallity e.g. no way to implement drag
| 'n' drop in Finder'eque recursive outline views, open tabs or
| windows - in fact window management and routing is just not much
| fun.
|
| So for iOS I'd not hesitate. It's good, better than React Native
| and getting better. It does't really feel like a half baked
| abstraction layer over the top of UIKit.
|
| For macOS on the other hand; it's much less clear. It's missing
| so much. And then there is the Catalyst auto-translate iOS app's
| stuff, which is kind of a worry that the grand plan is the moment
| it's feasible to dump it on macOS, it'll be dumped. So still not
| sure I'd use it for anything sizeable. Hopefully though will have
| a clearer picture of Apple's intents for the platform after the
| next WWDC.
| robert-boehnke wrote:
| I'm writing a component library[1] on top of SwiftUI and while
| there are ton of unsolved problems in SwiftUI, the separation of
| concern allows for much more productive workflows than were ever
| commonplace in UIKit.
|
| We're dropping into UIKit land quite frequently but for the user
| of the API, that remains implementation detail and while likely
| change as SwiftUI advances.
|
| Ironically, a "Stock iOS" style app like Mail or Contacts is much
| harder to pull off with SwiftUI than an app like AirBnB that
| brings has its own design aesthetic and establishes its own
| conventions - cooperating closely with your designers and keeping
| them aware of what's easy/hard is a much better use of your time
| than trying to rewrite a pixel perfect `UISearchController`
| clone.
|
| That said, navigation remains a complete mess and I hope that's a
| top priority for iOS 16.
|
| [1]: You might find this relevant to your interest if you write
| SwiftUI for a living: https://movingparts.io/variadic-views-in-
| swiftui
| PStamatiou wrote:
| You could write an opposite article featuring people using
| SwiftUI that have never touched UIKit or iOS code before and it
| would be nothing but glowing praise.
|
| That's kinda like my story. Covid started and I wanted to learn
| something new so I started with Swift/SwiftUI. 2 years later I've
| been doing tons of crazy custom stuff in my portfolio tracker app
| https://stocketa.com (not launched yet) - I kept a thread with my
| progress since the first day I started my journey:
| https://twitter.com/Stammy/status/1527288954935922688 (scroll
| up).
|
| This was last june but I wrote about my experience with SwiftUI
| at the time: https://paulstamatiou.com/getting-started-with-
| swiftui/
| tarentel wrote:
| It's quite a bit different experience working on an app by
| yourself and working on an app that has several hundred
| thousand lines of code that 10+ people are working on
| simultaneously. I've worked with a bunch of people that are
| complaining in this and the problems you face are quite a bit
| different.
|
| Your app looks sharp though I like it.
| lapcat wrote:
| > You could write an opposite article featuring people using
| SwiftUI that have never touched UIKit or iOS code before and it
| would be nothing but glowing praise.
|
| How can one properly evaluate it with no point of comparison?
|
| If you've never tasted chocolate, then vanilla might seem like
| the greatest flavor ever.
| PStamatiou wrote:
| The point of comparison is that it has given people the
| ability to develop their own iOS apps from scratch, when
| previously they could not as UIKit was too daunting and the
| tools were not as advanced (live preview with swiftui/etc).
| bowsamic wrote:
| SwiftUI is not less daunting than UIKit. In fact I would
| say that the SwiftUI "magic" is far scarier for beginners
| than IBOutlets and UIViewControllers
| rileyphone wrote:
| Beginners love magic, it lets them do things they
| otherwise couldn't do.
| bowsamic wrote:
| I don't agree, magic is confusing and scary. Especially
| in SwiftUI where it literally looks like it's invalid
| syntax if you're used to basic Swift.
| PStamatiou wrote:
| I watched a youtube video about VStacks and Spacers and I
| was having fun making real layouts my first hour in -
| with a fast, live preview environment. That was my "oh
| wow" moment. What's the equivalent with UIKit? Interface
| Builder is nothing like what's now possible with SwiftUI.
| I've tried IB in the past and it was not for me.
| b3morales wrote:
| > What's the equivalent with UIKit?
|
| UIStackView
|
| > I was having fun making real layouts my first hour in
|
| Good. Now take a pixel-perfect mockup of a new screen
| from your designer at work and implement that.
| saagarjha wrote:
| UIStackView is much more boilerplate to use than just a
| HStack/VStack. And I do a lot of design work in SwiftUI-
| it's really easy to get stuff on the screen and directly
| how you want it to look, even for a design mockup. I'll
| just not hook up interactivity and it works just fine for
| that kind of storyboarding. If you have a designer that
| wants you to follow their lead "to the pixel" then
| they're probably not doing their job of UI design very
| well-a good process works both ways, where you provide
| insight into what works well on the platform and they
| provide their own suggestions until you meet in the
| middle.
| PStamatiou wrote:
| > Good. Now take a pixel-perfect mockup of a new screen
| from your designer at work and implement that.
|
| I'm also a designer and have built many detailed screens
| with custom components/interactions in SwiftUI.
| tahnhnxfl wrote:
| I have been watching your progress on Stocketa and as an
| experienced iOS engineer who uses SwiftUI at work, I have
| been amazed by the speed with which you were able to
| build the app. The fact that you were able to ship a real
| app (with custom graph and polished animations) really
| speaks to how accessible SwiftUI is to new developers
| compared to UIKit.
|
| I work for mid size company with a fairly big app with
| millions of users and we did a complete re-write of the
| app in SwiftUI and I can say with confidence that once a
| SwiftUI view layer is built out, building features on top
| of that is incredibly fast compared to UIKit.
| spike021 wrote:
| >(live preview with swiftui/etc)
|
| I have a similar experience (started working from scratch
| on an iPhone app back in January with SwiftUI). Live
| preview is really awful. I had to basically disable it
| throughout my project. It'll crash for no reason and
| require a manual click on a button to reload, errors it
| spits out tend to be unintelligible, etc. I definitely
| wouldn't use live preview as an example of SwiftUI being
| advanced and not being daunting to use.
| [deleted]
| lapcat wrote:
| Fair enough. In fairness to the blog author, iOS developers
| with more experience are more likely to be known to him and
| others.
| b3morales wrote:
| It may have a easier ramp-up, but it also has a huge cliff
| at the end of the ramp. Once you step off the happy path
| you're in for an even more daunting experience than UIKit,
| because SwiftUI doesn't give you much to get below the
| magic when you need to. Also, previews are fairly
| constantly broken in my experience. Interface builder has
| its problems too, but at least it renders the nib every
| time.
| [deleted]
| yen223 wrote:
| I've tried both SwiftUI and Jetpack Compose (the equivalent
| framework for Android). While conceptually they are very similar
| frameworks, in practice I found that Jetpack Compose + Kotlin had
| a far superior development experience than SwiftUI + Swift.
|
| I genuinely cannot think of a single thing that SwiftUI does
| better than Jetpack Compose.
|
| There are a lot of fundamental design decisions in SwiftUI that
| are questionable, like their reliance on two-way binding (which
| makes non-trivial event handling very difficult to implement), or
| having Views be structures rather than functions (which then
| necessitated special ForEach views, because you can't use regular
| control flow mechanisms).
| emehex wrote:
| You can do control flow on SwiftUI Views? Checkout
| @ViewBuilder...
| C123Q wrote:
| [deleted]
| ChildOfChaos wrote:
| I haven't done much programing as a kid and i'm just starting to
| learn Swift/SwiftUI through the hacking with swift course,
| interesting to read the comments here as I didn't realize it was
| so hated?
|
| Seems fine to me for building apps but I don't really know
| enough.
| jeffreyrogers wrote:
| SwiftUI is good enough to make apps with. All tools/libraries
| have problems. You'll advance much faster by learning to work
| with their limitations than you will be trying to find the
| perfect framework to use at the start (it doesn't exist
| anyways).
| dcow wrote:
| I don't think it's hated.. don't get the wrong idea. You're
| just reading different anecdotes about how well it's worked for
| people in various different scenarios. There's no perfect
| solution.
| allenleein wrote:
| As a consumer social startup founder, iOS dev. We use 100%
| SwiftUI in our production app. We absolutely love it. It's way
| easier to maintain.
|
| App demo: https://www.notion.so/ale0sx/Miurror-
| Demo-62eaeed2679d4756a0...
| jkirsteins wrote:
| I recently wrote a full app (Wordle clone) in SwiftUI using the
| iPad Playgrounds app as a personal challenge. I didn't have a lot
| of experience with UIKit, and literally 0 with SwiftUI.
|
| There was definitely a lot of time spent looking why basic things
| are not working as expected. There are many counterintuitive
| things to it, I think, and some bugs.
|
| But overall, as a newbie to iOS development, it was a fairly nice
| experience. I am skeptical I could've iterated/developed
| something complete (despite the issues) as fast with UIKit.
|
| I only wish they made it open source. It feels like it would
| really benefit from being run more like the open source Swift
| frameworks, rather than this opaque update-once-a-year thing.
| samirsd wrote:
| built this https://mixtape.ai entirely in swiftui. some hiccups
| along the way but overall i don't regret it. the speed of
| iteration with swiftui is just incredible. you can A/B feature
| and ui combinations like there's no tomorrow.
| Shadonototra wrote:
| The complains sounds like people don't like to put the effort
|
| SwiftUI is the best UI/app framework on the market, nothing come
| close to it
|
| Fun fact, Miguel de Icaza (gnome/mono/MS) fell in love with it
|
| https://twitter.com/migueldeicaza/status/1372551091905236999
| dagmx wrote:
| I'm confused by this post. Is it just a random smattering of
| Twitter sentiment collected into one place?
| lapcat wrote:
| Yes. It's more or less a "link blog" with some commentary and
| always has been.
| emdowling wrote:
| You're not wrong; that is the blog's style. I enjoy the format
| for exposing me to a cross-section of opinions from across the
| internet, on topics I find interesting, with very little work
| on my part. That's probably more an indictment on Twitter's
| product stagnation than a shower of praise on this blog and
| it's author.
| b3morales wrote:
| Additionally, it's not always just Twitter: it can be news,
| or something from another blog as well.
| stasy wrote:
| From my understanding, you have to use SwiftUI differently than
| it is eventually intended. First, you build 90% of the app in
| SwiftUI, then you use UIKit for the other 10% that can't be done
| in SwiftUI. Eventually you will be able to do everything in
| SwiftUI, but for now, this strategy works pretty well.
| mark_l_watson wrote:
| I wrote a simple app last summer using SwiftUI and put it in the
| AppStore. Fairly easy after taking a short online class.
|
| I agree with many of the negative comments in the article and
| Apple should get busy resolving issues.
|
| That said, I really like the idea of Swift and SwiftUI and
| especially Apple's awesome deep learning support in apps.
| gh123man wrote:
| SwiftUI has been a game changer for me as a solo dev. Sure - you
| have to make tradeoffs like backwards compatibility, and some
| strange things are missing/don't work. But - it's been a force
| multiplier. You can break apart complex views into components by
| copy/pasting its body into a new `View` struct. It's so much
| simpler than ripping apart a storyboard into a XIB or fighting
| with layout constraints. The simplicity lets you try things and
| fail fast without too much of an investment in design complexity.
|
| I find that I can deliver features and iterate much faster and
| that makes up for the time I spend fixing edge case bugs or
| bridging to UIKit when I need an unsupported feature.
| ragnese wrote:
| I hear you, even though I've chosen to just deal with fighting
| the layout constraints. For what it's worth, I just use a
| zillion nested UIStackViews when I'm in "try things and fail
| fast" mode and it tends to work okay for just seeing if the
| overall thing works like I want. Then I go back and do more
| precise design work fiddling with spacing, alignment,
| compression pressure, etc.
| konschubert wrote:
| Another solo dev, and I can second your sentiment.
|
| I would like to add that I found SwiftUI to be extremely robust
| against developer mistakes. Things either work, or they give
| error messages. It's rare that a view is subtly broken.
| vimy wrote:
| Things were easier when it was just Objective-C and UIKit /
| AppKit. Swift killed my joy of making iOS apps.
| adamnemecek wrote:
| How is Objective-C easier than Swift.
| nicky0 wrote:
| Once you get past the square brackets notation, ObjC is a
| really delightfiul language to code in largely because of
| it's message-passing object system. In many ways Swift was a
| step forward, and more approachable for beginners, but for me
| it's also a few steps backwards for programmer happiness.
| woadwarrior01 wrote:
| If you know C, Objective-C is very little syntax on top of
| it. I learnt it over a weekend ~12 years ago by mostly
| reading Apple's programming guide[1] and then the Objective-C
| runtime reference[2] and just playing with some code and GDB.
| That was enough for me to lead a small team of iOS devs and
| we built slew of popular apps for the next two years. My
| background prior to that was in desktop GUI development using
| Qt and C++.
|
| I don't work in the iOS/macOS dev field anymore, but I've
| tried learning Swift in a similar fashion over weekends, to
| no avail. Incidentally, do you have any recommendations for
| learning Swift for someone coming from a C/ modern C++
| background?
|
| [1]: https://developer.apple.com/library/archive/documentatio
| n/Co... [2]: https://developer.apple.com/documentation/object
| ivec/objecti...
| kitsunesoba wrote:
| Objective-C can feel easier to different types of developers
| for different reasons.
|
| For disciplined developers who always dot their I's and cross
| their T's, it feels easier because they can write code with
| full "trust" from the compiler that the developer knows what
| they're doing.
|
| For undisciplined developers, it can feel easier because the
| compiler isn't calling them out on code smells and
| inattentiveness to nullability and types.
|
| I'd like to think I'm somewhere in the middle (as I suspect
| most devs are) and for me Swift feels easier in most
| respects, even with its everything-and-the-kitchen-sink
| nature compared to Objective-C's more spartan approach.
| DANK_YACHT wrote:
| Swift is very strict. Objective-C lets you get away with
| more. E.g. optionals in Swift are kind of annoying. if let,
| guard let, blah blah blah. I like Swift more than Obj-C, but
| Obj-C is a fine language in its own right. Definitely easier
| to write once you get a hang of the notation. Swift may have
| a more familiar syntax, but it forces you to think about more
| things when writing code.
| vimy wrote:
| Objective-C has an unusual syntax but is easy to master.
| Swift has an easy syntax but is hard to master.
| lapcat wrote:
| Some reasons:
|
| Objective-C compiles much faster. Fewer compiler errors.
| Fewer compiler crashes. Older projects still compile. The
| debugger is much more reliable. The entire Objective-C
| toolchain is more solid, because it's older, mature, and
| changes less.
|
| Also, easier compatibility with cross-platform C and C++
| source.
| [deleted]
| robertwt7 wrote:
| Looking at the documentation, it's just scary to jump in and put
| most of your effort on swiftUI
| emehex wrote:
| Yeah, the documentation isn't amazing... but the example apps
| and tutorials are great!
| https://developer.apple.com/tutorials/swiftui/
| mromanuk wrote:
| I'm doing an app integrally with SwiftUI, as always happen with
| new frameworks, if you stay in the happy path everything is nice
| and easy, but if you start tweaking things, you are lost in the
| forest really fast.
|
| To give you an example, it's quite easy to add the swipe to
| delete function (within a list) just adding .onDelete() but if
| you want to add swipe to delete to a LazyVStack (similar to a
| List) you need to implement the gesture detection and a few more
| things [0].
|
| From my POV, SwiftUI IS the future, declarative UIs are awesome,
| I'm confident that Apple will reach a point where all the
| quirkiness are mostly gone.
|
| 0: https://stackoverflow.com/questions/67585037/swiftui-
| ondelet...
| fatboy wrote:
| I'm probably just getting a bit old, but I like to layout my
| views manually. I've got a few helpers so I can write
| `view.left = otherView.right + 8` or `view.moveLeftEdge(to:
| margins.left` etc. I find it just so clear and easy to
| understand.
|
| I've not tried SwiftUI yet because my app needs to work on
| older devices than this allows, but it's also a solution for a
| problem I don't really have. It can't be as bad as AutoLayout
| at least.
| NonNefarious wrote:
| Except that doesn't scale for different devices, and will
| look ridiculous on the Mac when the user resizes the window.
|
| Non-Apple programmers are probably shocked to learn that to
| this day there's still no graceful way to scale an Apple UI
| up. You can't just set "scale symmetrically" on a view. It
| comes down to positioning things with multiplication factors
| and literally trying and retrying those decimal numbers on
| every goddamned control/label combo. Over and over and
| over...
|
| Then we needed to build a cross-platform desktop app, and
| went with Qt and QML. I expected to dislike QML, but no; it's
| really nice to work with, and our app looks great. QML has
| been around for years, so it's disappointing that SwiftUI has
| turned out to be such an apparent fiasco.
| anonymouse008 wrote:
| [Edit: Everyone read ChrisMarshallNY's comment, it's a less terse
| and more eloquent version of this :)]
|
| My humble belief is that once one understands the inner workings
| of UIKit, Swift UI is about half of the interactivity of UIKit
| (read interactivity not as animations or formatting, but actual
| user controls and inferences from intended actions).
|
| I had requirements to fully understand UITextView, then TextKit
| and NSLayout, then new ways to interact with text that I have no
| earthly idea how I would build my interactions in SwiftUI.
|
| In SwiftUI, you get a lot of bang for your buck, but if you want
| to build something truly remarkable, you need to get your hands
| dirty and codify your opinions with UIKit.
| fbanon wrote:
| SwiftUI was a mistake.
|
| The jury is still out on Swift itself.
| emehex wrote:
| Swift is a phenomenal language. Generics, Protocols, Protocol
| Extensions... all a delight to work with
| travisgriggs wrote:
| Some days I agree, some days definitely not. Would you care t
| elaborate in a meaningful way on your sentiment?
| kitsunesoba wrote:
| As someone who got his start in programming with Obj-C and
| AppKit, I'm totally sold on Swift. I'll still do small tools
| and the like with Obj-C sometimes but for projects with any
| complexity, Swift is my go-to. The number of stupid mistakes
| the Swift compiler catches and little QoL things like not
| having to maintain header files make it worth its comparative
| downsides.
| bowsamic wrote:
| The problem with SwiftUI is what Apple seems to consider its
| advantage: that it hides complexity from the developer (see their
| "Avocado toast maker" analogy in one of the WWDCs). The reason
| this is a problem is because sometimes you do need to break out
| of the paradigm, and doing so is basically always painful. At
| least with UIKit and AppKit you are always in full control.
| Complex apps will break out of the SwiftUI box all over the
| place, destroying the benefits. You can usually hack things to
| make it play with SwiftUI nicely, but it always feels like a
| hack.
|
| One example I had was trying to put an ObservableObject into
| UserDefaults for persistent storage. There's not really a nice
| way to do this. SwiftUI only knows how to store basic scalar
| values in UserDefaults. That kind of makes sense, because
| UserDefaults is only meant for small amounts of data, but what if
| I want to save a struct that has two fields? Trying to do this in
| SwiftUI is actually quite painful and that is a very simple
| example. Another pain point is app navigation which basically
| does not work properly at all.
|
| Though one very nice thing is that it's quite easy to use a
| SwiftUI view from UIKit
|
| Overall though, somehow a far worse experience than using
| something like React
| emehex wrote:
| Apple tried to solve this with @AppStorage, but if you lean on
| MVVM... it doesn't really work. Hoping we get some new CoreData
| + UserDefaults stuff this upcoming WWDC
| bowsamic wrote:
| No, @AppStorage just does scalars, as I said
| emehex wrote:
| "tried" being the operative word. But you really shouldn't
| be persisting an ObservableObject. You should extract what
| you need into a model and use Codable...
| bowsamic wrote:
| Why shouldn't I try and persist an ObservableObject? Has
| some Apple guru given you this secret information in a
| WWDC, or personally? It seems totally reasonable to do
| so. Observability is something you bestow upon a model,
| it shouldn't exclude it from persistence. You are talking
| nonsense to defend Apple's lazy approach. They simply
| have not covered this base, that's the actual non-Apple-
| fanboy explanation. Get it together
| emehex wrote:
| Observable/StateObjects help bridge between models and
| views... I'd recommend watching this WWDC session:
| https://developer.apple.com/videos/play/wwdc2020/10040/
| pcr910303 wrote:
| IMO SwiftUI feels limited b.c. it breaks itself away from the
| UIKit world: React succeeded because it is the DOM with all of
| raw HTML & CSS, a thin abstraction with official escape hatches.
| Mixing imperative and declarative code is natural and more
| abstractions can be built.
|
| Instead, SwiftUI adopted a whole new set of primitives that
| doesn't mix. Accessing the underlying UIView is discouraged, and
| wrapping up UIKit in SwiftUI feels like a legacy feature. IMO
| SwiftUI should have been a thin wrapper on UIKit.
| Willamin wrote:
| There are official escape hatches in SwiftUI to let you
| leverage UIKit. As someone actively working on a slow migration
| from UIKit to SwiftUI (where possible), it doesn't feel
| discouraging to wrap a UIKit view to use it in SwiftUI if
| necessary.
| pcr910303 wrote:
| That's more of a compatibility solution than an escape hatch.
| An official SwiftUI escape hatch should have access to the
| underlying imperative object, call methods on it, etc...
| Unfortunately the underlying 'things' in SwiftUI is
| implementation detail, inspecting the view hierarchy and
| finding the UIViews that implement a SwiftUI view is a hack.
| eunoia wrote:
| As I understand it, what you're asking for is fundamentally
| incompatible with the paradigm itself (at least in a clean
| way).
|
| The whole programming experience of declarative UIs is
| predicated on the fact that you're manipulating lightweight
| structs (really just state representations) that are
| rendered into heavyweight views by the system only where
| necessary (determined by diffing the state changes).
|
| React's refs are an attempted answer to this very problem,
| and they get nasty fast.
| pcr910303 wrote:
| > you're manipulating lightweight structs that are
| rendered into heavyweight views by the system
|
| Yes, and I'm arguing that not exposing the 'heavyweight
| views' to the programmers at all is a mistake.
| eunoia wrote:
| Yup, and my understanding of the problem is that if you
| expose the heavy weight views to the state layer
| (structs) and allow direct manipulation, render calls
| lose incompetency, the structs are no longer the source
| of state truth and the whole abstraction gets terribly
| leaky.
|
| Edit: once again I think it's important to look at the
| limitations and advantages of prior work in this area and
| I believe React refs to be a good case study in that.
| eunoia wrote:
| Oops autocomplete. Incompetency should be idempotency.
| hdjjhhvvhga wrote:
| > how I shipped an amazing full-featured cross-platform SwiftUI
| app in 10 minutes
|
| For anyone wondering: "cross-plaftorm" means Apple platforms, not
| real multiplatform like Flutter.
| austinl wrote:
| > "Hey I got 90% of what I wanted really quick! Neat!" "...oh
| turns out that last 10% is basically impossible, eh?" Adam Kaump
|
| I've been working on an app that's mostly SwiftUI for about a
| year now. It feels magical when it works, but I don't think I've
| saved time vs. using UIKit at this point due to all of the
| workarounds that I've needed to find.
|
| Particularly, SwiftUI List views are still loosely supported, and
| in some cases broken. Unfortunately for devs, lists are the
| cornerstone of many apps.
|
| For example, it's very difficult to get the content offset of
| list. You cannot put multiple buttons in a list row without
| breaking their tap targets. You can't change the background color
| of a grouped list without changing it globally (and it's very
| difficult to customize many SwiftUI components, like the
| navigation bar). It's difficult to control the spacing between
| sections in grouped lists. I could go on.
|
| Developers are stuck in a hard place right now. If you're
| starting an iOS app today, do you go with UIKit (and accept that
| your code will soon be considered legacy by Apple and many
| engineers?) Or do you go with SwiftUI, and accept that many
| things will be broken or impossible to make right?
| apozem wrote:
| As a solo, hobbyist iOS & macOS dev, I like SwiftUI. It's much
| easier to learn than all of UIKit and AppKit. Feels like React.
|
| That said, I find myself dipping down into AppKit and UIKit quite
| often. Any kind of complex views or UI interactions outside the
| happy path, just grab that UIViewRepresentable.
| joshuawright11 wrote:
| Context: I've been working with iOS full time since a few years
| before Swift came out.
|
| A few startups ago we built our app using SwiftUI 1.0. At that
| time, while 90% of it was fantastic, 10% was either unworkable or
| extremely unreliable, causing for some maddening bugs. The
| documentation was laughable so for these reasons I chose to do
| the app for a subsequent startup in UIKit.
|
| Fast forward to my most recent company; decided to give SwiftUI
| another shot (targeting iOS 14 & SwiftUI 2). I am 100% glad we
| did. It's been pretty incredible; we've built a reasonably
| complex banking app at a pace not possible with UIKit. The
| animations in particular are crazy good to work with; we've got
| some very complex animated flows that would have taken weeks and
| thousands of lines with UIKit... with SwiftUI it was about 5
| days.
|
| It's definitely not without its downsides; documentation is still
| slim at best, but there's plenty of blogs and resources
| (https://swiftui-lab.com/ is the most helpful IMO) available now.
| There are also still some maddening bugs that appear in
| production and take a day or two of head scratching only to
| discover it's a bug in the framework (most recently; using
| #available causes code to crash on the platform it's protecting
| against lol), but there are always workarounds. Still, time
| wasted on these has been vastly outweighed by the weeks / months
| of time saved.
|
| Finally, you can always use UIKit as an escape hatch through
| UIViewRepresentable.
|
| iOS 15 is at 85% adoption, so we plan to drop support for 14
| somewhat soon, which will give us an even more robust framework
| as well as async await APIs. Not feasible for most companies I
| know, but even supporting 14+ Will be pretty reasonable when iOS
| 16 drops in September.
| emehex wrote:
| I'm targeting iOS 14+ for most projects and planning to drop
| when iOS 16 drops as well. Thankfully async/await was back-
| ported to iOS 13 (can't live without it!)
| aplummer wrote:
| What kind of work are you doing with async/await that is so
| improved? Very interested in what kind of code on the client
| that is.
| cvwright wrote:
| I'm not the OP, but I'm updating my iOS app now to use
| async/await instead of callback hell for all of its
| networking code. It is much, much nicer.
|
| I also recently did some work with Vapor on the server
| side. Night and day difference there. The old Vapor
| EventLoop stuff was doable, if you squinted just right and
| concentrated really hard. The async/await version is as
| delightful as anything else I've ever used. Nearly as easy
| as writing Python.
| aplummer wrote:
| This is what I was expecting. I think for Vapor for
| example it's incredible because you are always in async
| land. For client code, because you are returning to the
| main thread quite a lot - I'm not seeing so many
| benefits.
| tarentel wrote:
| Same. I toyed with a bit for a networking stack but outside
| of that I haven't found anything super useful. I never went
| into production with it, the code I re-wrote was definitely
| cleaner but it wasn't really mind blowingly better that I
| felt the need to pursue it further.
| anonymouse008 wrote:
| Do you mind explaining exactly what animations would take that
| much work? I'm struggling to see how animations could ever take
| as long as estimated for UIKit
| ketzo wrote:
| The parent said "animated flows" and mentioned a banking app,
| so I'm betting a multi-page form with lots of transitions
| between a _lot_ of different state combinations.
|
| Again, just guessing, but I would imagine that it's managing
| that state and animating it in a sane way which requires LOTS
| of code, less so the animations themselves.
| NonNefarious wrote:
| How about explaining why you have a bunch of animations in a
| UI to begin with?
|
| Animations are so often an ill-advised, interaction-slowing
| pain in the ass for users that I'm curious about beneficial
| and non-annoying use cases.
| joshuawright11 wrote:
| Good question! I'm very much in alignment that most non-
| system animations get in the way / are just annoying.
|
| I think it depends on what the goal of the screen is. If
| the goal is to simple provide information to the user, it
| makes sense to have clean, simple, and snappy animations.
|
| However, I think there are also situations where the
| experience itself is the goal. i.e. give the user a
| visually pleasing graphic, animation, interaction, etc. In
| this case going a little wild with animations can be a good
| thing.
|
| Most in app situations should be the first (snappy, clean,
| useful). But selectively sprinkling a few instances of the
| second throughout your app can bring the experience to the
| next level.
|
| In our case, we wanted the rewards flow (it's a
| banking/brokerage app) to be a fun, gamified experience to
| separate us from typical banks. So we opted to add a very
| visual, interactive experience in this single part of the
| app. There's a demo video above. While it's certainly
| extra, I think it makes the core flow of the app a unique
| experience.
| joshuawright11 wrote:
| Here's a part of the flow I'm talking about; for context it's
| a debit card that rewards users with stock as they use it.
| The entire flow is SwiftUI (though the top of the pack
| ripping is PNG sequences so we did cheat a bit).
|
| https://streamable.com/56pha0
|
| (shameless plug; check us out at https://www.withapollo.com
| we're YCS21, just launched last week, and are hiring an iOS
| engineer!)
| anonymouse008 wrote:
| Ok, wow, yeah impressive!
|
| [Edit]: Thank you kind stranger.
| dean177 wrote:
| > though the top of the pack ripping is PNG sequences so
| we did cheat a bit
| saagarjha wrote:
| I just finished writing a little Mac app in SwiftUI for my
| personal use yesterday:
| https://github.com/saagarjha/EffectivePower
| (https://twitter.com/_saagarjha/status/1528937319171887104 for a
| slightly out-of-date screenshot). Here are my thoughts.
|
| The good:
|
| * Making all the graphs (they're drawn by hand!) was very nice
| and easy. The speed at which I could iterate with them was
| incredible, and I could just move code around and lay things out
| in a way that AppKit (or UIKit) would not allow, at all.
|
| * I could keep the code very clean, with each component being
| very specific and isolated. Plumbing bindings through made things
| very natural and I can imagine taking the code I made there and
| just plopping it into another project as-is.
|
| * The result is actually kind of nice, IMO? There's a lot of
| focus on whether SwiftUI works and stuff but not much focuses on
| what the end result is. I had an app in my mind that I wanted to
| make, and it was mostly possible to make it in SwiftUI. In some
| places I was pleasantly surprised that things I would have been
| hesitant to try before (slider in a toolbar!) "just worked".
|
| The middling:
|
| * I initially supported macOS 12.0 only. Someone asked me to
| backdeploy to 11.0, which was a little painful mostly because
| Material didn't exist back then and neither did support for
| initializing a color from a NSColor. I did kind of a lazy stab at
| it and the end result being fairly simple, but took about an hour
| to write:
| https://github.com/saagarjha/EffectivePower/blob/main/Effect....
| If I had to support 10.15 I think I would honestly rewrite large
| parts of the app in AppKit, maybe keeping just the graphs as view
| representables.
|
| * My data model has tens of thousands of elements. Ensuring the
| "reactivity" didn't cause a bunch of things to be recalculated
| when they shouldn't was a bit of a challenge. The place I have it
| now is very nice (I have them defined in such a way that they
| will never update unless they need a redraw) but this definitely
| does not come "for free", you'll find out about it after
| profiling and need to figure out how to fix it.
|
| * I wrote simple versions of things that don't seem to exist in
| SwiftUI but AppKit provides for free, such as magnification
| bouncing. It was like three lines of code to get something that
| seems reasonable, but with SwiftUI I'm never sure if this is a
| "we just didn't add it yet" thing or a "oh this is so simple in
| the framework that you should just write it yourself".
|
| The bad:
|
| * Things are broken and I don't know why. If you use
| magnification gestures the callbacks stop getting called. No
| indication why. I have some commented out code that would've used
| a table in the sidebar, but I had to use a List instead because
| it seems like SwiftUI does not properly update the table and it
| crashes with an assertion.
|
| * Documentation sucks but that's nothing new. There's a lot of
| things that work but you need to be clever at arriving to getting
| to that point. It's a fun challenge for a toy project but for a
| production thing I can see this being super frustrating.
|
| * If you mismatch a type somewhere the compiler is just going to
| time out rather than telling you what is wrong. Thankfully you
| can just go through and comment out large parts of the app to
| reduce the scope of where the error is coming from, but the fact
| that this is necessary is kind of annoying.
| bryansum wrote:
| One point that's not being discussed enough -- using SwiftUI
| (since it's heavily value-typed / struct-based) prevents a whole
| host of problems around retain cycles, typically the bugbear of
| iOS dev. I recently built an iOS app from scratch with recent
| grads with zero Swift experience (but had done React).
|
| It was ~2mo before they even had to _learn_ what a retain cycle
| was, and that was from using UIKit.
|
| Of course you still eventually see this if / when you use
| `@ObservedObjects` and their implementation, but in our case we
| were also using https://github.com/pointfreeco/swift-composable-
| architecture which hides this away as well.
| vxNsr wrote:
| > _Adam Kaump:
|
| "Hey I got 90% of what I wanted really quick! Neat!" "...oh turns
| out that last 10% is basically impossible, eh?"_
|
| This seems to be the story of apple in general. Very beautiful
| and easy to use as long as you stay on the path and don't go too
| far along lest you discover the 2nd mile is still under
| construction.
| Willamin wrote:
| That last 10% is easily accessible by reaching into UIKit.
| Crossing that boundary is much easier in practice than one
| might expect at a first glance of the docs for doing so.
___________________________________________________________________
(page generated 2022-05-25 23:02 UTC)