14 ms·

SwiftUI in 2022

• dgellow 4y 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?
  • wussboy 4y ago
    It’s not just the effect of Twitter. It’s the whole point of Twitter.
  • deleted 4y ago
    [deleted]
  • draw_down 4y ago
  • ragnese 4y 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.
    • throwaway1777 4y ago
      Not to be super rude, but why are you a polyglot dev if you don’t like learning multiple frameworks?
      • ragnese 4y 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.
    • 4y ago
  • ben_w 4y 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 4y 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.
  • viktorcode 4y 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.
• draw_down 4y 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.
• gh123man 4y 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.
  • ragnese 4y 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.
  • konschubert 4y 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.
• anonymouse008 4y 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.
• tikimcfee 4y 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.
  • ragnese 4y 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?
    • jshier 4y ago
      XIB? xib files are used in UIKit apps, alongside storyboards, but they're simply serialized views, not a different architecture or paradigm.
      • ragnese 4y 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.
    • happytoexplain 4y 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.
• tarentel 4y 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.
  • Willamin 4y 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).
  • rudedogg 4y 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 (https://austinrude.com/devlog/zig-ide-2022-04/ https://austinrude.com/devlog/zig-ide-2022-04/). I don’t think I would have attempted a project this large without it. I had to fall back to AppKit/NSViewRepresentable for the tabview, text editor, and a couple other views. There are probably over a hundred SwiftUI views though. And I am hoping I can switch the tabview to SwiftUI after WWDC so it’s easier to extend. About WWDC, I wonder if we’ll see a CoreAnimation replacement this year that is exposed to SwiftUI views? I don’t know what the implications would be, but it makes sense when you look back at how they’ve refused to offer/expose the underlying UIKit/AppKit APIs that SwiftUI is wrapping for some controls.
  • emehex 4y 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.
• JohnDeHope 4y 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.
  • deleted 4y ago
    [deleted]
• akmarinov 4y 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.
  • gh123man 4y 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 4y 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 4y 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
  • tarentel 4y ago
    Nope. We have a fairly complicated project, 20+ frameworks, the preview feature doesn't work. We're not using firebase either.
• catchclose8919 4y ago
  ...no comparison with Flutter or at least remarks of what would also apply to it?
  • frou_dh 4y ago
    Wouldn't be surprised if no one quoted there has ever used Flutter. The Apple dev comment-sphere is quite insular.
    • pornel 4y 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 4y 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 4y 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.
  • finiteseries 4y ago
• vimy 4y ago
  Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
  • deleted 4y ago
    [deleted]
  • adamnemecek 4y ago
    How is Objective-C easier than Swift.
    • lapcat 4y 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.
    • nicky0 4y 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.
    • woadwarrior01 4y 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]: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Co... [2]: https://developer.apple.com/documentation/objectivec/objective-c_runtime https://developer.apple.com/documentation/objectivec/objecti...
• stasy 4y 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.
• pcr910303 4y 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 4y 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 4y 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 4y 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 4y 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.
• vxNsr 4y 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 4y 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.
• ChrisMarshallNY 4y 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.
  • kitsunesoba 4y 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.
• PStamatiou 4y 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 https://stocketa.com https://stocketa.com (not launched yet) - I kept a thread with my progress since the first day I started my journey: https://twitter.com/Stammy/status/1527288954935922688 https://twitter.com/Stammy/status/1527288954935922688 (scroll up). This was last june but I wrote about my experience with SwiftUI at the time: https://paulstamatiou.com/getting-started-with-swiftui/ https://paulstamatiou.com/getting-started-with-swiftui/
  • lapcat 4y 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 4y 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).
      • lapcat 4y ago
        Fair enough. In fairness to the blog author, iOS developers with more experience are more likely to be known to him and others.
      • bowsamic 4y 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
• dagmx 4y ago
  I'm confused by this post. Is it just a random smattering of Twitter sentiment collected into one place?
  • lapcat 4y ago
    Yes. It's more or less a "link blog" with some commentary and always has been.
  • emdowling 4y 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 4y ago
      Additionally, it's not always just Twitter: it can be news, or something from another blog as well.
• robertwt7 4y ago
  Looking at the documentation, it’s just scary to jump in and put most of your effort on swiftUI
  • emehex 4y ago
    Yeah, the documentation isn't amazing... but the example apps and tutorials are great! https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/
• fbanon 4y ago
  SwiftUI was a mistake. The jury is still out on Swift itself.
  • travisgriggs 4y ago
    Some days I agree, some days definitely not. Would you care t elaborate in a meaningful way on your sentiment?
  • kitsunesoba 4y 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.
  • emehex 4y ago
    Swift is a phenomenal language. Generics, Protocols, Protocol Extensions... all a delight to work with
• apozem 4y 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.
• makecheck 4y 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?
  • kitsunesoba 4y ago
• Larrikin 4y 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
  • jamil7 4y 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 4y 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.
  • sethd 4y 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.
• yen223 4y 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 4y ago
    You can do control flow on SwiftUI Views? Checkout @ViewBuilder...
• mark_l_watson 4y 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.
• bowsamic 4y 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 4y 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 4y ago
      No, @AppStorage just does scalars, as I said
      • emehex 4y 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 4y 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 4y 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: https://github.com/maxhumber/BreadBuddy https://github.com/maxhumber/BreadBuddy
• seanalltogether 4y 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.
• C123Q 4y ago
  • deleted 4y ago
    [deleted]
• ChildOfChaos 4y 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.
  • jeffreyrogers 4y 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).
  • dcow 4y 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.
• mromanuk 4y 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: https://stackoverflow.com/questions/67585037/swiftui-ondelete-without-list https://stackoverflow.com/questions/67585037/swiftui-ondelet...
  • fatboy 4y 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 4y 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.
• joshuawright11 4y 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 (https://swiftui-lab.com/ https://swiftui-lab.com/ is the most helpful IMO) available now. There are also still some maddening bugs that appear in production and take a day or two of head scratching only to discover it’s a bug in the framework (most recently; using #available causes code to crash on the platform it’s protecting against lol), but there are always workarounds. Still, time wasted on these has been vastly outweighed by the weeks / months of time saved. Finally, you can always use UIKit as an escape hatch through UIViewRepresentable. iOS 15 is at 85% adoption, so we plan to drop support for 14 somewhat soon, which will give us an even more robust framework as well as async await APIs. Not feasible for most companies I know, but even supporting 14+ Will be pretty reasonable when iOS 16 drops in September.
  • emehex 4y 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 4y 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.
      • 4y ago
• alexashka 4y 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 4y 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) } }
  • emehex 4y ago
    Took me 5 minutes. Copy and paste this into a playground: https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c6da0b3 https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c...
    • deleted 4y ago
      [deleted]
    • alexashka 4y ago
      Your answer is wrong. You've failed the fizzbuzz :) Change frame (screen width) to 300, 500 to see why.
      • emehex 4y ago
        Good catch. Fixed with an extra ZStack.
        • alexashka 4y 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.
• deleted 4y ago
  [deleted]
• Shadonototra 4y 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 https://twitter.com/migueldeicaza/status/1372551091905236999 https://twitter.com/migueldeicaza/status/1372551091905236999
  • myko 4y ago
    I like SwiftUI but it is painful to use. Jetpack Compose is much more stable and ready for production, and it is backported to the vast majority of Android devices. Supporting iOS 13 with a SwiftUI app (a reasonable thing most customers will want) is essentially impossible to do without game breaking bugs between different point releases. It's really bad.
• austinl 4y 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?
• allenleee 4y 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: https://www.notion.so/ale0sx/Miurror-Demo-62eaeed2679d4756a0a7347c86d614af https://www.notion.so/ale0sx/Miurror-Demo-62eaeed2679d4756a0...
• jkirsteins 4y 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.
• jmull 4y 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.)
• hdjjhhvvhga 4y 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.
• saagarjha 4y ago
  I just finished writing a little Mac app in SwiftUI for my personal use yesterday: https://github.com/saagarjha/EffectivePower https://github.com/saagarjha/EffectivePower (https://twitter.com/_saagarjha/status/1528937319171887104 https://twitter.com/_saagarjha/status/1528937319171887104 for a slightly out-of-date screenshot). Here are my thoughts. The good: * Making all the graphs (they're drawn by hand!) was very nice and easy. The speed at which I could iterate with them was incredible, and I could just move code around and lay things out in a way that AppKit (or UIKit) would not allow, at all. * I could keep the code very clean, with each component being very specific and isolated. Plumbing bindings through made things very natural and I can imagine taking the code I made there and just plopping it into another project as-is. * The result is actually kind of nice, IMO? There's a lot of focus on whether SwiftUI works and stuff but not much focuses on what the end result is. I had an app in my mind that I wanted to make, and it was mostly possible to make it in SwiftUI. In some places I was pleasantly surprised that things I would have been hesitant to try before (slider in a toolbar!) "just worked". The middling: * I initially supported macOS 12.0 only. Someone asked me to backdeploy to 11.0, which was a little painful mostly because Material didn't exist back then and neither did support for initializing a color from a NSColor. I did kind of a lazy stab at it and the end result being fairly simple, but took about an hour to write: https://github.com/saagarjha/EffectivePower/blob/main/EffectivePower/Polyfills.swift https://github.com/saagarjha/EffectivePower/blob/main/Effect.... If I had to support 10.15 I think I would honestly rewrite large parts of the app in AppKit, maybe keeping just the graphs as view representables. * My data model has tens of thousands of elements. Ensuring the "reactivity" didn't cause a bunch of things to be recalculated when they shouldn't was a bit of a challenge. The place I have it now is very nice (I have them defined in such a way that they will never update unless they need a redraw) but this definitely does not come "for free", you'll find out about it after profiling and need to figure out how to fix it. * I wrote simple versions of things that don't seem to exist in SwiftUI but AppKit provides for free, such as magnification bouncing. It was like three lines of code to get something that seems reasonable, but with SwiftUI I'm never sure if this is a "we just didn't add it yet" thing or a "oh this is so simple in the framework that you should just write it yourself". The bad: * Things are broken and I don't know why. If you use magnification gestures the callbacks stop getting called. No indication why. I have some commented out code that would've used a table in the sidebar, but I had to use a List instead because it seems like SwiftUI does not properly update the table and it crashes with an assertion. * Documentation sucks but that's nothing new. There's a lot of things that work but you need to be clever at arriving to getting to that point. It's a fun challenge for a toy project but for a production thing I can see this being super frustrating. * If you mismatch a type somewhere the compiler is just going to time out rather than telling you what is wrong. Thankfully you can just go through and comment out large parts of the app to reduce the scope of where the error is coming from, but the fact that this is necessary is kind of annoying.
• czhu12 4y 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.
  • topspin 4y 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 4y ago
      SwiftUI is very closed source, yes.
  • pjmlp 4y 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, https://whatwebcando.today/ https://whatwebcando.today/
• deleted 4y ago
  [deleted]
• LeicaLatte 4y 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.
• dep_b 4y 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.
• samirsd 4y ago
  built this https://mixtape.ai https://mixtape.ai entirely in swiftui. some hiccups along the way but overall i don’t regret it. the speed of iteration with swiftui is just incredible. you can A/B feature and ui combinations like there’s no tomorrow.
• bze12 4y 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.
• lonelyasacloud 4y 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.
• bryansum 4y 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 https://github.com/pointfreeco/swift-composable-architecture https://github.com/pointfreeco/swift-composable-architecture which hides this away as well.
• bsaul 4y 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..
• robert-boehnke 4y 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: https://movingparts.io/variadic-views-in-swiftui https://movingparts.io/variadic-views-in-swiftui
• pjmlp 4y 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.