_______               __                   _______
       |   |   |.---.-..----.|  |--..-----..----. |    |  |.-----..--.--.--..-----.
       |       ||  _  ||  __||    < |  -__||   _| |       ||  -__||  |  |  ||__ --|
       |___|___||___._||____||__|__||_____||__|   |__|____||_____||________||_____|
                                                             on Gopher (inofficial)
   URI Visit Hacker News on the Web
       
       
       COMMENT PAGE FOR:
   URI   SwiftUI in 2022
   DIR   text version
       
       
        pjmlp wrote 2 days ago:
        Not to steal the thread, on the other side of the fence it feels
        similar.
        
        Jetpack Compose performance is a pain versus traditional Android views,
        hence some performance related talks at Google IO 2022.
        
        The UWP, WinUI 2.0, WinUI 3.0 mess, that makes it more fun to keep
        using Forms/WPF/MFC than adopt them.
        
        Makes one wonder where are those teams coming from, with what resources
        are they dealing with, that in the end we get such quality.
       
        robert-boehnke wrote 3 days ago:
        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:
        
   URI  [1]: https://movingparts.io/variadic-views-in-swiftui
       
        bsaul wrote 3 days ago:
        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..
       
        bryansum wrote 3 days ago:
        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 [1] which hides this away as well.
        
   URI  [1]: https://github.com/pointfreeco/swift-composable-architecture
       
        lonelyasacloud wrote 3 days ago:
        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.
       
        bze12 wrote 3 days ago:
        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.
       
        samirsd wrote 3 days ago:
        built this [1] 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.
        
   URI  [1]: https://mixtape.ai
       
        dep_b wrote 3 days ago:
        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.
       
        LeicaLatte wrote 3 days ago:
        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.
       
        czhu12 wrote 3 days ago:
        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.
       
          pjmlp wrote 2 days ago:
          It makes no sense with any of them.
          
          For CRUD stuff we do regular Web applications, naturally with the
          necessary optimizations for mobile Web, in the process you can also
          make use of PWA features for mobile devices.
          
          Try it out on your device,
          
   URI    [1]: https://whatwebcando.today/
       
          topspin wrote 3 days ago:
          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.
       
            b3morales wrote 2 days ago:
            SwiftUI is very closed source, yes.
       
        saagarjha wrote 3 days ago:
        I just finished writing a little Mac app in SwiftUI for my personal use
        yesterday: [1] ( [2] 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: [1]
        /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.
        
   URI  [1]: https://github.com/saagarjha/EffectivePower
   URI  [2]: https://twitter.com/_saagarjha/status/1528937319171887104
   URI  [3]: https://github.com/saagarjha/EffectivePower/blob/main/Effectiv...
       
        hdjjhhvvhga wrote 3 days ago:
        > 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.
       
        jmull wrote 3 days ago:
        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.)
       
        jkirsteins wrote 3 days ago:
        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.
       
        allenleein wrote 3 days ago:
        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:
        
   URI  [1]: https://www.notion.so/ale0sx/Miurror-Demo-62eaeed2679d4756a0a7...
       
        austinl wrote 3 days ago:
        > “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?
       
        Shadonototra wrote 3 days ago:
        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
        
   URI  [1]: https://twitter.com/migueldeicaza/status/1372551091905236999
       
        alexashka wrote 3 days ago:
        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 :)
       
          BakaRakuda wrote 4 hours 30 min ago:
          I'm late to the party, but how about this:
          
            struct ContentView: View {
              var body: some View {
                ZStack {
              Color.red
              Color.blue
                .frame(width: 50, height: 50)
                .padding(10)
              Color.blue
                .frame(width: 50, height: 50)
                .position(x: 50/2, y: 50/2)
                .padding(10)
                }
                .aspectRatio(1, contentMode: .fit)
                .padding(10)
              }
            }
       
          saagarjha wrote 3 days ago:
          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 3 days ago:
            Your answer is wrong. You've failed the fizzbuzz :)
       
              emehex wrote 3 days ago:
              Perhaps you can post a photo of what you're looking for? Because
              your instructions aren't super clear :)
       
              saagarjha wrote 3 days ago:
              I generally expect interviewers to tell me what the problem is ;)
       
                alexashka wrote 3 days ago:
                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.
       
                  andrekandre wrote 2 days ago:
                  actually thats a good point
                  
                  i wonder how one could go about implementing custom layout in
                  swiftui, something like `layoutSubViews` so we could
                  implement something simplified like:
                  
                    View(layout: .grid) { ... }
                  
                  or
                  
                    View(layout: .stack(.vertical)) { ... }
       
                  saagarjha wrote 2 days ago:
                  I think I'd ideally want to do this with some alignment
                  constraints but I don't see this as being far more difficult
                  than setting constraints manually. Doing this correctly is
                  actually somewhat non-trivial because you'll want the square
                  to respond to rotation appropriately, etc. which will require
                  less-than-or-equal constraints.
       
          emehex wrote 3 days ago:
          Took me 5 minutes. Copy and paste this into a playground:
          
   URI    [1]: https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c...
       
            b3morales wrote 3 days ago:
            Now please see how it looks on a device:
            
   URI      [1]: https://postimg.cc/crtKHSTG
       
            alexashka wrote 3 days ago:
            Your answer is wrong. You've failed the fizzbuzz :)
            
            Change frame (screen width) to 300, 500 to see why.
       
              emehex wrote 3 days ago:
              Good catch. Fixed with an extra ZStack.
       
                alexashka wrote 3 days ago:
                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 3 days ago:
                  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...
       
        joshuawright11 wrote 3 days ago:
        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 ( [1] 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.
        
   URI  [1]: https://swiftui-lab.com/
       
          anonymouse008 wrote 3 days ago:
          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
       
            NonNefarious wrote 3 days ago:
            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 3 days ago:
              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 3 days ago:
            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). [1] (shameless plug; check us out
            at [2] we're YCS21, just launched last week, and are hiring an iOS
            engineer!)
            
   URI      [1]: https://streamable.com/56pha0
   URI      [2]: https://www.withapollo.com
       
              anonymouse008 wrote 3 days ago:
              Ok, wow, yeah impressive!
              
              [Edit]: Thank you kind stranger.
       
                dean177 wrote 3 days ago:
                > though the top of the pack ripping is PNG sequences so we did
                cheat a bit
       
            ketzo wrote 3 days ago:
            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.
       
          emehex wrote 3 days ago:
          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 3 days ago:
            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 3 days ago:
              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 3 days ago:
                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 3 days ago:
              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.
       
        mromanuk wrote 3 days ago:
        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:
        
   URI  [1]: https://stackoverflow.com/questions/67585037/swiftui-ondelete-...
       
          fatboy wrote 3 days ago:
          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 3 days ago:
            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.
       
        ChildOfChaos wrote 3 days ago:
        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.
       
          dcow wrote 3 days ago:
          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.
       
          jeffreyrogers wrote 3 days ago:
          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).
       
        seanalltogether wrote 3 days ago:
        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.
       
        emehex wrote 3 days ago:
        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:
        
   URI  [1]: https://github.com/maxhumber/BreadBuddy
       
        bowsamic wrote 3 days ago:
        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 3 days ago:
          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 3 days ago:
            No, @AppStorage just does scalars, as I said
       
              emehex wrote 3 days ago:
              "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 3 days ago:
                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 3 days ago:
                  Observable/StateObjects help bridge between models and
                  views... I'd recommend watching this WWDC session:
                  
   URI            [1]: https://developer.apple.com/videos/play/wwdc2020/100...
       
        mark_l_watson wrote 3 days ago:
        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.
       
        yen223 wrote 3 days ago:
        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 3 days ago:
          You can do control flow on SwiftUI Views? Checkout @ViewBuilder...
       
        Larrikin wrote 3 days ago:
        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 3 days ago:
          > 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 3 days ago:
          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 3 days ago:
            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.
       
        makecheck wrote 3 days ago:
        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 3 days ago:
          > 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.
       
            andrekandre wrote 2 days ago:
            > Combine is an abstraction to encapsulate changes in state over
            time
            
            so is
            
   URI      [1]: https://github.com/apple/swift-async-algorithms
       
            saagarjha wrote 3 days ago:
            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 3 days ago:
          > 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.
       
        apozem wrote 3 days ago:
        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.
       
        fbanon wrote 3 days ago:
        SwiftUI was a mistake.
        
        The jury is still out on Swift itself.
       
          emehex wrote 3 days ago:
          Swift is a phenomenal language. Generics, Protocols, Protocol
          Extensions... all a delight to work with
       
          kitsunesoba wrote 3 days ago:
          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.
       
          travisgriggs wrote 3 days ago:
          Some days I agree, some days definitely not. Would you care t
          elaborate in a meaningful way on your sentiment?
       
        robertwt7 wrote 3 days ago:
        Looking at the documentation, it’s just scary to jump in and put most
        of your effort on swiftUI
       
          emehex wrote 3 days ago:
          Yeah, the documentation isn't amazing... but the example apps and
          tutorials are great!
          
   URI    [1]: https://developer.apple.com/tutorials/swiftui/
       
        dagmx wrote 3 days ago:
        I'm confused by this post. Is it just a random smattering of Twitter
        sentiment collected into one place?
       
          emdowling wrote 3 days ago:
          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 3 days ago:
            Additionally, it's not always just Twitter: it can be news, or
            something from another blog as well.
       
          lapcat wrote 3 days ago:
          Yes. It's more or less a "link blog" with some commentary and always
          has been.
       
        PStamatiou wrote 3 days ago:
        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 [1] (not
        launched yet) - I kept a thread with my progress since the first day I
        started my journey: [2] (scroll up).
        
        This was last june but I wrote about my experience with SwiftUI at the
        time:
        
   URI  [1]: https://stocketa.com
   URI  [2]: https://twitter.com/Stammy/status/1527288954935922688
   URI  [3]: https://paulstamatiou.com/getting-started-with-swiftui/
       
          tarentel wrote 3 days ago:
          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 3 days ago:
          > 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 3 days ago:
            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).
       
              spike021 wrote 3 days ago:
              >(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.
       
              b3morales wrote 3 days ago:
              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.
       
              bowsamic wrote 3 days ago:
              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 3 days ago:
                Beginners love magic, it lets them do things they otherwise
                couldn't do.
       
                  bowsamic wrote 3 days ago:
                  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 3 days ago:
                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 3 days ago:
                  > 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 3 days ago:
                    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.
       
                      hmlongco wrote 2 days ago:
                      Then again, you can eliminate a lot of that boilerplate.
                      I have a demo app up where I generate UIViews using
                      resultBuillder such that you get a very SwiftUI-like
                      experience using UIKit views.
                      
   URI                [1]: https://github.com/hmlongco/Builder
       
                      b3morales wrote 2 days ago:
                      > UIStackView is much more boilerplate to use than just a
                      HStack/VStack.
                      
                      It is. It's also far more flexible in return.
                      
                      But the point is that if someone has to ask this question
                      then they don't have enough experience with UIKit to be
                      comparing SwiftUI and UIKit.
       
                    PStamatiou wrote 3 days ago:
                    > 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 3 days ago:
                      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.
       
              lapcat wrote 3 days ago:
              Fair enough. In fairness to the blog author, iOS developers with
              more experience are more likely to be known to him and others.
       
        ChrisMarshallNY wrote 3 days ago:
        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 3 days ago:
          > 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 2 days ago:
            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.
       
              JamesSwift wrote 2 days ago:
              > The UIViewController must be present in a UIKit app. Most
              classic UIKit apps have the lions' share of code in
              UIViewControllers.
              
              I dont think you understand the point I'm making. Just because
              Apple has created a framework that has something called
              UIViewController which has child UIViews doesnt matter when using
              a pattern called MVVM. The V is just the _visual_ representation
              of the pattern. It could be a terminal console if you want, it
              doesn't have to be the "underlying" view of the platform! Don't
              fight the platform to align its idea of the view with a specific
              thing called a View in the pattern.
              
              EDIT: and yes IB is an issue if you want to be programmatic. I do
              all my views in code.
       
                ChrisMarshallNY wrote 2 days ago:
                Actually, I understood just fine. I’ve been doing this kind
                of thing for a while. I’m not even disagreeing. I understand
                where you are coming from.
                
                It’s just Apples and oranges.
                
                I write in Swift, as a native developer of Apple software. I
                won’t go into all the reasons I do what I do (actually,
                I’ve covered a lot, in this thread). I have my reasons, and
                there’s nothing wrong with my approach. I get a lot done,
                very quickly, and at a fairly high Quality level.
                
                Life is a compromise. We always need to make trade-offs.
       
          tarentel wrote 3 days ago:
          > 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 3 days ago:
            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.
       
          madeofpalk wrote 3 days ago:
          > 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 3 days ago:
            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.
       
          cageface wrote 3 days ago:
          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.
       
            JamesSwift wrote 2 days ago:
            UIKit isnt even deeply MVC. Its purely C. The Controller is the god
            object by design, but also because the first 10 years of iOS
            tutorials never took the time to even split out a single View. So
            that became the gateway for everyone learning the platform, and is
            what they imitated.
            
            Its not much better today overall, but is usually not an issue
            within companies themselves.
       
            bsaul wrote 3 days ago:
            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 3 days ago:
            >  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.
       
            quux wrote 3 days ago:
            Could be worse, they could have adopted RIBs
            
   URI      [1]: https://github.com/uber/RIBs
       
              nyanpasu64 wrote 3 days ago:
              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?
       
                aaaaaaaaata wrote 2 days ago:
                Build a PWA =^]
       
                tadfisher wrote 3 days ago:
                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()).
       
              throwaway1777 wrote 3 days ago:
              Or ComponentKit
       
            tarentel wrote 3 days ago:
            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.
       
              cokeandpepsi wrote 3 days ago:
              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
       
              ChrisMarshallNY wrote 3 days ago:
              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.
       
            ChrisMarshallNY wrote 3 days ago:
            > the VIPER architecture
            
            < Takes out a foil blanket. Hands you a flask. >
       
              emehex wrote 3 days ago:
              VIPER is horrific at scale. Don't. Just don't.
       
          kitsunesoba wrote 3 days ago:
          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.
       
        vxNsr wrote 3 days ago:
        > 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 3 days ago:
          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.
       
        pcr910303 wrote 3 days ago:
        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 3 days ago:
          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 3 days ago:
            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 3 days ago:
              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 3 days ago:
                > 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 3 days ago:
                  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 3 days ago:
                    Oops autocomplete. Incompetency should be idempotency.
       
        stasy wrote 3 days ago:
        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.
       
        vimy wrote 3 days ago:
        Things were easier when it was just Objective-C and UIKit / AppKit.
        Swift killed my joy of making iOS apps.
       
          adamnemecek wrote 3 days ago:
          How is Objective-C easier than Swift.
       
            DANK_YACHT wrote 3 days ago:
            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.
       
            kitsunesoba wrote 3 days ago:
            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.
       
            vimy wrote 3 days ago:
            Objective-C has an unusual syntax but is easy to master. 
            Swift has an easy syntax but is hard to master.
       
            woadwarrior01 wrote 3 days ago:
            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]
            
   URI      [1]: https://developer.apple.com/library/archive/documentation/...
   URI      [2]: https://developer.apple.com/documentation/objectivec/objec...
       
            nicky0 wrote 3 days ago:
            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.
       
            lapcat wrote 3 days ago:
            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.
       
        catchclose8919 wrote 3 days ago:
        ...no comparison with Flutter or at least remarks of what would also
        apply to it?
       
          finiteseries wrote 3 days ago:
          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 3 days ago:
            Work for a financial institution which hired iOS and Android
            developers and had them rewrite everything in Flutter.
       
              finiteseries wrote 3 days ago:
              It’s the natural move, it’s just odd I’ve mostly seen
              adoption using web developers so far.
       
          frou_dh wrote 3 days ago:
          Wouldn't be surprised if no one quoted there has ever used Flutter.
          The Apple dev comment-sphere is quite insular.
       
            pornel wrote 3 days ago:
            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 3 days ago:
              > 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 3 days ago:
                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.
       
        akmarinov wrote 3 days ago:
        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 3 days ago:
          > 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...
       
          bryansum wrote 3 days ago:
          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
          
   URI    [1]: https://www.pointfree.co/episodes/ep171-modularization-part-...
       
          emehex wrote 3 days ago:
          Are you using MVVM and mocking out your ViewModels?
       
          tarentel wrote 3 days ago:
          Nope. We have a fairly complicated project, 20+ frameworks, the
          preview feature doesn't work. We're not using firebase either.
       
          gh123man wrote 3 days ago:
          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 3 days ago:
            +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.
       
              andrekandre wrote 2 days ago:
              one other solution is to build a sub project that links to a
              subset of minimum dependencies needed for ui development and
              build your swiftui stuff there...
              
              it will be lightning fast compared to large xcode project... and
              it might even be better architecturally too, since you'd have to
              factor out lower level logic (view models or whatever) anyways
       
        JohnDeHope wrote 3 days ago:
        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.
       
        tarentel wrote 3 days ago:
        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.
       
          emehex wrote 3 days ago:
          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 3 days ago:
            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 3 days ago:
              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 3 days ago:
          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
          ( [1] ).
          
          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.
          
   URI    [1]: https://austinrude.com/devlog/zig-ide-2022-04/
       
          Willamin wrote 3 days ago:
          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).
       
        tikimcfee wrote 3 days ago:
        $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.
       
          tolmasky wrote 3 days ago:
          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:
          
   URI    [1]: https://twitter.com/stroughtonsmith/status/15294383578346332...
       
          tarentel wrote 3 days ago:
          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.
       
          zerkten wrote 3 days ago:
          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 3 days ago:
            It's marketed as a complete replacement of UIKit.
       
              aaaaaaaaaaab wrote 3 days ago:
              Trust me, noone at Apple believes that. Not even the SwiftUI
              team.
       
                zerkten wrote 3 days ago:
                What do the folks in the know believe it is?
       
                  aaaaaaaaaaab wrote 3 days ago:
                  Mostly a shiny tool to lure in beginners and web developers.
                  
                  Kind of like Duplo vs Lego.
       
          xbar wrote 3 days ago:
          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.
       
          ragnese wrote 3 days ago:
          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?
       
            happytoexplain wrote 3 days ago:
            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.
       
              Willamin wrote 3 days ago:
              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 3 days ago:
                Thanks, I didn't know that!
       
                ragnese wrote 3 days ago:
                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 3 days ago:
                  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.
       
              ragnese wrote 3 days ago:
              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 3 days ago:
                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 3 days ago:
                  Fair enough. I saw your reply to the grandfather comment and
                  I asked some follow up questions there. Thank you. :)
       
            jshier wrote 3 days ago:
            XIB? xib files are used in UIKit apps, alongside storyboards, but
            they're simply serialized views, not a different architecture or
            paradigm.
       
              ragnese wrote 3 days ago:
              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.
       
        anonymouse008 wrote 3 days ago:
        [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.
       
        gh123man wrote 3 days ago:
        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.
       
          konschubert wrote 3 days ago:
          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.
       
          ragnese wrote 3 days ago:
          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.
       
        draw_down wrote 3 days ago:
        > 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.
       
        dgellow wrote 3 days ago:
        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?
       
          viktorcode wrote 3 days ago:
          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.
       
          ben_w wrote 3 days ago:
          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 3 days ago:
            > 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.
       
          ragnese wrote 3 days ago:
          > 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.
       
            zethraeus wrote 2 days ago:
            > 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.
            
            Woah now, that's interesting! In my mind swift has had awesome
            support for functional programming paradigms since launch. I
            understand it to be leaning in about as far as it can given that
            it's built with first class support for Obj-c oriented frameworks.
            
            What makes you feel like it's unapologetically imperative?
       
            throwaway1777 wrote 3 days ago:
            Not to be super rude, but why are you a polyglot dev if you don’t
            like learning multiple frameworks?
       
              ragnese wrote 3 days ago:
              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.
       
          wussboy wrote 3 days ago:
          It’s not just the effect of Twitter. It’s the whole point of
          Twitter.
       
       
   DIR <- back to front page