Tuesday, [1]May [2]24, [3]2022 [[4]Tweets] [[5]Favorites]
          [6]SwiftUI in 2022
          [7]Jake Sawyer:
            Even if you already know a bit (or a lot) of SwiftUI, [8]Stanford’s
            course is incredible, amazing, wonderful, AND FREE!
          [9]Nick Lockwood:
            Half the iOS devs on my TL keep posting stuff like “here’s how I
            shipped an amazing full-featured cross-platform SwiftUI app in 10
            minutes and the other half are like “Button presses have been
            broken in SwiftUI for 16 months and Apple hasn’t responded to my
          [10]Greg Pierce:
            My SwiftUI development process starts with a clear definition of
            the problem and ends in a recursive loop of Google searches trying
            to figure out why the thing I did to fix A broke B, and the thing
            I did to fix B, broke C, etc.
          [11]Jonathan Badger:
            As a newbie to the framework, I enjoy the instant feedback that
            the canvas preview provides with each code modification and am
            thoroughly impressed by the elegance and simplicity of SwiftUI’s
            design. That being said, I have run into odd behaviors and
            challenging problems that make me want to tear my hair out at
            times. One such issue, which at first seems trivial, is how to
            dismiss the keyboard when a user taps an area on the screen that
            is outside the bounds of a [12]TextField or [13]TextEditor view.
            Here, I will discuss a few of the common issues surrounding
            keyboard dismissal and provide two solutions and workarounds that
            I have found after an embarrassing amount of googling and combing
            of [14]StackOverflow
          [15]Christian Selig:
            Has anyone done a nice blog post on integrating SwiftUI as parts
            of an existing UIKit app and having them communicate nicely? (Many
            posts are all or nothing) Integrating it for bits and pieces
            sounds fun, but a bit intimidating. 😬
          [16]Scott Anguish:
            It’s a nightmare. That’s what we found.
          [17]Steve Troughton-Smith:
            SwiftUI remains incompetent at basic layout, something Playgrounds
            users are going to find out the hard way… 😅
          [18]Ron Avitzur:
            I’m stuck diagnosing an infinite loop in SwiftUI layout for code
            that worked on macOS 11.
          [19]Steve Troughton-Smith:
            I’m really excited about using SwiftUI in my apps.
            SwiftUI is an unreliable mess that needs to be treated with oven
            mitts, and I won’t be increasing my reliance on it anytime soon.
            That dichotomy is what makes the SwiftUI story so frustrating.
          [20]Oskar Groth:
            We’re halfway into SwiftUI 3 and this is yet another example where
            it fails to provide us with a properly working default control.
          [21]Ron Avitzur:
            Today in C++ → Swift: macOS 12 SwiftUI Focus
            .focused($focus, equals: .mathBlock(id)) is not setting the first
            responder to my NSViewRepresentable NSView.
            Should I expect it to?
            Anyone have insight into how AppKit first responder interacts with
            Swift Focus for custom views?
          [22]Adam Kaump:
            “Hey I got 90% of what I wanted really quick! Neat!” “…oh turns
            out that last 10% is basically impossible, eh?”
          [23]Marco Arment:
            I like a lot of it. But it’s not simple, easy, or mature.
            Its conceptual elegance and clean presentation-slide code are
            quickly ruined by common real-world needs.
            And you frequently slam HARD into walls that you just can’t
          [24]Steve Troughton-Smith:
            I really do feel like every time I use SwiftUI, even in the
            simplest of places, it’s burying mines in my code that will be set
            off at some point in the future
            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
          [25]Simon B. Støvring:
            I wouldn’t use SwiftUI for core parts of a complex app yet but
            it’s safe to say that Runestone wouldn’t have so many settings if
            it wasn’t for SwiftUI. It’s so simple to build settings screens
            that look decent with SwiftUI.
          [26]Josh Avant:
            Today, 2.5 years after release, there’s still validly a
            more-than-small amount of opinion that SwiftUI is not even
            Production Ready for mature, complex applications.
            If you have to make the choice today, I say choose UIKit.
            (Unless your app isn’t intended to be mature, complex)
          [27]Helge Heß:
            There is very much to like about SwiftUI (and almost all my recent
            apps use it), but e.g. that it can’t do a very core and basic
            thing like navigation in its 3rd iteration properly is just
            embarrassing. 🤷‍♀️
          [28]Helge Heß:
            The real difference is that one may have been missing API you’d
            want (not really), while SwiftUI has API all over but the provided
            stuff isn’t just bad but simply doesn’t work. Often even depending
            on context - i.e. it is an inconsistent mess from an API
          [29]Sam Deane:
            SwiftUI lists can get really slow, due to all the clever diffing
            that goes on for animation.
            There is [30]a workaround, but it seems that it stops working if
            you put the list inside a NavigationView.
          Let’s use value types instead of objects and then allocate a UUID for
          each one since they no longer have pointer identity.
          [31]Paul Haddad:
            It’s still terrible, takes at least twice as long to do anything
            for results that IMO are not as good as UIKit.
          [32]Hoà V. DINH:
            I’m going to rewrite an app that I wrote with SwiftUI back to
            regular Swift + UIKit because I’m hitting so many blockers when
            refining the details.
          [33]Marin Todorov:
            💯 internet points for @steipete for making a landing page for this
            SwiftUI crasher that you didn’t cause and can’t fix 👌🏼
          [34]Russell Ivanovic:
            Let’s play a little game called “Will the SwiftUI preview load?”.
            It’s ok if you’re not an Apple Developer, you can play along!
          [35]Marco Arment:
            A day building in SwiftUI:
            I would like a search bar in the navigation bar like every app
            Oh that requires iOS 15
            I would like it to activate when presented
            Can’t do that without rebuilding with UIKit hacks
            I would like it not to hide itself
            Can’t do that, go back to UIKit
            For every hour SwiftUI’s niceness has saved me, I’ve probably lost
            two more hours to the slow and buggy tooling, scouring the web to
            make up for its non-discoverability and poor documentation,
            hacking around its brick-wall limitations, or giving up and
            rewriting things in UIKit.
          [36]Phillip Caudell:
            Writing SwiftUI is like riding a bicycle downhill on a beautiful
            sunny day.
            Until the bike suddenly explodes, killing you.
            It makes building a production app in SwiftUI extremely difficult
            when the basic system controls don’t work.
            There’s so much to love about SwiftUI, but still after several
            years the basics are still buggy as hell.
          [37]Ken Kocienda:
            A tool like SwiftUI which can’t easily handle simple and
            well-understood tasks isn’t likely to scale to more complex and
            experimental tasks without seemingly endless frustration.
          [38]Steve Troughton-Smith:
            Abstracting developers from the ‘real’ goings-on is also a means
            of control on Apple’s part, to shrink us down into a little
            sandbox we can’t break out of. Can’t compete with system apps if
            we only have toy APIs
          [39]Michael Love:
            Seems like an especially self-destructive policy on Apple’s part
            in this case, because it’s not clear they have much of a vision
            for what to actually do with AR apps and by abstracting us away
            they’re going to make it impossible for developers to help come up
            with one.
          [40]Ron Avitzur:
            Today in AppKit → SwiftUI:
            .keyboardShortcut(.upArrow) does not work with
            but .leftArrow and .rightArrow do work
            .upArrow works with .buttonStyle(BorderlessButtonStyle()).
            Filed under: I do not even want to know the explanation behind
          [41]Kyle Howells:
            I can’t help feeling SwiftUI was a massive mistake for Apple.
            I keep seeing blog posts and articles of people trying to write
            native iOS or macOS apps, using SwiftUI, abandoning it as: too
            buggy/much work/effort/not worth it. And then switching to
            Electron & React Native.
            If Apple had just spent its effort on updating UIKit, adding more
            standard UI components modern apps use/need.
            Improving Xcode’s tooling, bug fixes. They’d have 1 really nice
            "reliable" toolset for people to use.
          [42]Kyle Howells:
            This is my main issue with SwiftUI. It’s a high level black box.
            With UIKit I can: drop down to UIControl easily if I want to
            replace UIButton; make my own table view, drop down to CALayer’s,
            customise the CALayer a view uses, etc....
          [43]Kyle Howells:
            And there in lies the problem of why I can never see SwiftUI is a
            real/full replacement for any UI framework.
            Either it needs to allow you full control to build the thing.
            Or it needs to be a high level abstraction over top the real
            Currently it’s sort of both badly.
          [44]Ron Avitzur:
            @FocusedValue as seen in macOS menus is not changing reliably when
            switching windows despite my best attempts. However, setting a
            global in response to NSWindow.didBecomeKeyNotification seems to
            work just fine.
          [45]Majd Taby:
            We WERE going to include a SwiftUI component in our next update,
            but alas, I just rewrote it in UIKit.
            This was a result of three situations:
            1. Incomplete APIs in SwiftUI limiting our capabilities
            2. Coordinating the SwiftUI layout updates with UIKit ones was
            difficult and caused animation problems
            3. Our data model wasn’t designed for SwiftUI, and thus caused a
            lot of CPU thrash
          [46]Jordan Singer:
            Learning SwiftUI unleashed creativity inside of me like no
            language ever has and brought joy back to building user
            Here’s a thread of my experiments to show you what’s possible, to
            learn from, and code to remix👇
          [47]Rony Fadel:
            SwiftUI forces you to think more deeply about architecture
            compared to UIKit.
            Abstraction hijackings (e.g. getting a reference to and
            conditional casting a parent or sibling vc) are not possible by
            virtue of how SwiftUI works.
          [48]Ron Avitzur ([49]tweet):
            Is it possible to set the isAlternate property on an NSMenuItem in
            the macOS menubar to implement dynamic menu items in a SwiftUI
            document-based app which uses CommandMenu to construct the menus?
          [50]Steve Troughton-Smith:
            The harsh reality of SwiftUI in 2022 is that it doesn’t enable a
            competent dev to build a better app. It gives you a
            lesser-than-native, less-reliable, less-compatible, less
            debuggable app — a two-tier system where 3rd-parties may never be
            able to compete with Apple’s own
            Short of major advancement at WWDC22 wrt to reliability,
            configurability & back-compat, I’m not sure SwiftUI will ever be
            the right technology for my apps. Its priorities are clearly
            elsewhere, and that’s OK. But that isn’t the future of anything,
            just a lower entry point
          [51]Rony Fadel:
            SwiftUI + Introspect gets us that much👌 closer, but I agree that
            we’re not there yet. Right now SwiftUI is a reactive shell on top
            UIKit with a number of gaping holes (Lists, Navigation, View
            presentation etc..)
          [52]Russell Ivanovic:
            As long as you’re ok with ignoring Autolayout errors. I get tonnes
            of those in my SwiftUI views and it’s like “what would you like me
            to do with that info…exactly?”
          [53]Damien Petrilli:
            The Joy of SwiftUI:
            Animation in simulator:✅
            Animation in Swift Playgrounds on iPad:✅
            Animation in the App: freeze and lag.
            100% same code.
          [54]Khoa Pham:
            Just finished refactoring a 115+ screens #SwiftUI app to UIKit
            navigation. Every screen has its own UIViewController and is
            Feels so good
            As long as SwiftUI is still based on UIKit, using UIKit is a safer
          [55]Ron Avitzur:
            Looks like it is back to UIKit for the UIPanGestureRecognizer for
          [56]Simon B. Støvring:
            Many seem to either like SwiftUI or believe that it’ll get better
            down the road and be the future of UI development on iOS and
            Is there a possibility that SwiftUI is simply a bad idea for these
            platforms? That it won’t work?
            I’m starting to fear that as we’re adopting SwiftUI in our apps,
            we’re also compromising too much. Our UIs are getting simpler but
            more buggy. We’re becoming slobby.
            Maybe it’ll all work out in the end. I hope it will. But this is a
            fear that I currently have.
          [57]Steve Troughton-Smith:
            To my surprise (not.), yet another SwiftUI regression has begun to
            screw with my apps, this time affecting tab-focus and text fields.
            Appears to have cropped up either in the latest SDK or most recent
            macOS release. Worked fine when I shipped (& for 2 years), now
            does not.
            I think once I bail on SwiftUI that’ll be it for me for quite a
            while. I’ll check back in in 5, 8 years, like I did with Swift,
            and maybe it’ll be tolerable then. I have a lot of development in
            me before then, and I just can’t base any of it around SwiftUI
            Unlike early Swift, which was just clumsy to write but could still
            make a 1:1 version of your ObjC app, early SwiftUI is radioactive
            and eats holes in everything it touches. I feel like Apple will be
            paying this one off for a veery long time
          [58]Steve Troughton-Smith:
            One place I can recommend SwiftUI: as a preview wrapper for UIKit
            views & view controllers. This element is hugely useful even to
            developers who don’t use SwiftUI for any of their code
          [59]Kyle Hughes:
            In March I removed the last traces of SwiftUI from an app, going
            back to 100% UIKit. I needed block element support in attributed
            In March I also released a 100% SwiftUI app.
            Perhaps they are both good.
          [60]Chris Eidhof:
            I was trying to create an NSImage out of a simple SwiftUI View.
            Turns out to be surprisingly difficult: dataWithPDF is completely
            broken, cacheDisplay(in:to:) has strange artifacts and good old
            CGWindowListCreateImage works as expected.
          [61]Ron Avitzur:
            Today’s API eldritch horror experience trying to implement the
            macOS Paste menu item so that it is enabled or disabled
            appropriately depending on what is on the clipboard.
            In AppKit, this is very easy.
            In SwiftUI, I’m lost in a maze of twisty APIs...
          [62]Kuba Suder:
            This talk is a bit of a mindfuck… I’m gonna have to watch it more
            than once. Is it just me, or is it… kinda unintuitive that the
            lifecycle of state variables in that subview depends on whether
            you write this as if/else or with ternary operator “?:” ?
          [63]Marcin Krzyzanowski:
            overpromise under-deliver in one screen. the title itself is
            almost an oxymoron
          [64] Steven Curtis:
            Imagine using a version of Xcode with a [65]major memory leak
            attached to SwiftUI. If it’s Xcode 13 I think that’s fine, they’ll
            fix in in 13.1. What do you mean, they only fixed it in Xcode
            I want to decouple navigation from views. I don’t want to use
            UIHostingController as I would like to create a completely native
            SwiftUI App. I need to have easy access to views using
            deep-linking where the screens depend on complex state, and can be
            accessed from multiple parts of the App.
          [66]James Thomson:
            Since installing 12.4, all the labels for my SwiftUI pickers have
            vanished. Affects my existing versions too. This is a Mac-idiom
            Catalyst app.
            That’s really not great 🙁
          [67]Ron Avitzur:
            Replacing a SwiftUI ScrollView/VStack with a List View was
            straightforward and provides swipe-to-delete, and drag-to-reorder
            rows. However, it also made scrolling the view impossible.
            Breakpoint on scrollTo does not fire. I fail to understand this.
          [68]Paola Mata:
            All these hacks and workarounds for making SwiftUI do basic shit…
          See also: [69]The evolution of SwiftUI.
            * [70]How to Open a Window in SwiftUI
            * [71]SwiftUI Performance Tips
            * [72]Lifetime of State Properties in SwiftUI
            * [73]Micro.blog Moving iOS App to React Native
            * [74]How to Find Why a SwiftUI View Is Updating
            * [75]The Persistent Gravity of Cross Platform
            * [76]1Password 8 for Mac Early Access
            * [77]SwiftUI Examples for macOS
            * [78]Shortcuts for Mac
            * [79]Apple Documentation and SwiftUI for Mac
            * [80]SwiftUI Layout Explained
            * [81]What Is Not So Great About SwiftUI
            * [82]The State of SwiftUI
            * [83]Emulating Equal-Size Constraints in SwiftUI
          Update (2022-05-25): [84]Steve Streza:
            SwiftUI will be great once it’s production ready. Maybe that will
            be this year. Until that happens though, this post remains a
            spectacular cautionary tale of what happens when you go down that
          [85]Martin Pilkington:
            There is a very strong argument to make that declarative UI
            frameworks are always going to be a case of “faster to get to
            good, difficult to get to great”
            Building great software requires fine-grained control over the UI,
            but that’s kind of the antithesis of declarative UI.
            That isn’t to say you can’t have parts of UI be built
            declaratively, just that you can’t handle every case people will
            have with a full declarative framework
          [86]Aleksandar Vacić:
            I expected such issues back in 2019 (the talk I gave at
            Pragmaconf) but did not see them taking this long to clear up.
            The black box design and complete dependence on Apple to fix
            issues did not turn out good.
          [87]Michael Brown:
            This absolutely does not reflect my experience of using SwiftUI.
            In the 8 months that I’ve been using it intensively the time it
            has saved me is immeasurable compared to the problems encountered.
            It is unquestionably better than using UIKit (which I have used
            since 2010).
            I have built a production app for a bank in SwiftUI (released in
            March 2021) but I can relate to all of things described.
          [89]Benedikt Terhechte:
            Doesn’t even mention how invalid layouts crash SwiftUI apps at
            SwiftUI is such a bummer. While I agree with the feelings that it
            makes UI development so fun and freeing, when you start running
            into issues, then the magic is shattered and you’re back to the
            harsh reality that computers are all broken.
          [91]Sam Deane:
            I do still like SwiftUI a lot, and am using it in production apps.
            I ended up making [92]this to fix the List issues. It is crude but
            effective and does just enough of what I need.
            I do still regularly hit brick walls, but a lot of the time I find
            them to reflect a strongly opinionated design philosophy, rather
            than just an accidental omission.
            In other words, someone is deliberately preventing you from doing
            something they don’t think you should do.
          [93]R. Mark Volkmann:
            I have never used UIKit and am a relatively new user of SwiftUI.
            So far I love it.
          [94]Steve Troughton-Smith:
            After @jamesthomson’s tweet, it was with trepidation I upgraded to
            macOS 12.4 to see how the changes to SwiftUI have broken my own
            apps. Sure enough, all the labels have been removed from my
            pickers, in the shipping version of Pastel.
          See also: [95]Hacker News.
          [96]John Gruber ([97]tweet):
            I’d like to see leaps-and-bounds improvements announced this year.
          Update (2022-05-26): [98]Luc Vandal:
            Overall, my experience with SwiftUI has been mostly positive. Of
            course there were times I wanted it to die in a but I was able to
            develop & release an app that is on the App Store & actually
          [99]Kevin Hayes:
            I’m not blind to its bugs and limitations but it’s definitely a
            net positive for me. It’s working out well in 1Password 8 for iOS,
            and my side projects are SwiftUI too.
          [100]Francisco Tolmasky:
            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
          [101]Richard Turton:
            If you are working with an existing UIKit codebase and are
            SwiftUI-curious when it comes to adding or updating new features,
            this article should help answer your questions. I’m going to cover
            some of the technical details of how SwiftUI works and how state
            is managed, some tips on integrating SwiftUI into your existing
            code, and some common pain points.
          [102]iOS [103]iOS 15 [104]Mac [105]macOS 12 Monterey [106]Programming
          [107]Swift Programming Language [108]SwiftUI [109]Top Posts
          [110]6 Comments
          someone May 24, 2022 3:40 PM
          It's funny to see all those efforts to use SwiftUI while Apple still
          hasn't even updated some of its apps in Monterey to use view-based
          [111]Ron AvitzurMay 24, 2022 8:41 PM
          While I am amused by this collection of my snarkiest
          Tweets-from-the-trenches during my year-long learning curve rewriting
          everything from scratch in Swift & SwiftUI, to be fair, in the end, I
          am about to ship ye olde Graphing Calculator on macOS and iOS written
          entirely in Swift & SwiftUI, which reduced the source code from
          152,000 lines of C++, AppKit, and UIKit to 29,000 lines of
          Swift/SwiftUI, which I am very pleased with. Public TestFlight for the
          new version is at [112]https://t.co/zwoQwOTkYg for macOS. Contact me
          to try it on iOS.
          [113]NeilMay 24, 2022 9:10 PM
          Isn't the real issue that Apple is not transparent about SwiftUI's
          current limitations? Something that Chris Eidhof mentioned here [69]https://www.swiftbysundell.com/podcast/116/
          [113]NeilMay 24, 2022 9:16 PM
          Or is it just that cross-platform frameworks have a hard time handling
          very subtle user interactions as illustrated by Don Norman's 7 stages
          of action model?
          Sören May 25, 2022 1:45 AM
          I see three issues here.
          * Declarative code is always elegant when it works, and agonizing when
          it doesn’t. Debugging imperative code step by step is easy; analyzing
          why declarative code isn’t doing what you expected, not so much.
          * I don’t think SwiftUI per se was a mistake. It’s where the industry
          is headed. (See e.g. Flutter and Jetpack Compose.) I do think that,
          three years in, it still feels like more of a preview than a 3.0. Is
          the team understaffed? The dogfooding lacking? I don’t know.
          * The quality issues, especially with regressions, are hard to excuse
          and a serious issue if Apple wants to slow the exodus towards Electron
          and Flutter.
          Kristoffer May 26, 2022 3:12 AM
          It's like a case study of the Stockholm syndrome. Everyone being so
          careful to laude Swift UI and then launching into a list of buts
          Stay up-to-date by subscribing to the [114]Comments RSS Feed for this
          Leave a Comment
          E-mail (will not be published)
          Web site
          [115]← [116]→
          [119]Tag Cloud
          [109]Top Posts
          [121]Recently Updated
          [122]RSS / [123]Comments
          [124]Apple News
          Support this site via [126]Patreon.
          Try my Mac apps:
          [130]ToothFairyToothFairy[130]ToothFairyCopyright © 2000–2022 [131]Michael
          1. https://mjtsai.com/blog/2022/05/
          2. https://mjtsai.com/blog/2022/05/24/
          3. https://mjtsai.com/blog/2022/
          4. https://mjtsai.com/tweetnest/2022/05/24
          5. https://pinboard.in/search/u:mjtsai?query=%22May+24%2C+2022%22
          6. https://mjtsai.com/blog/2022/05/24/swiftui-in-2022/
          7. https://twitter.com/Naxum/status/1456061292402204678
          8. https://cs193p.sites.stanford.edu
          9. https://twitter.com/nicklockwood/status/1466813486416240647
          10. https://twitter.com/agiletortoise/status/1468970329808666633
          11. https://www.dabblingbadger.com/blog/2020/11/5/dismissing-the-keyboard-in-swiftui
          12. https://developer.apple.com/documentation/swiftui/textfield
          13. https://developer.apple.com/documentation/swiftui/texteditor
          14. https://stackoverflow.com
          15. https://twitter.com/ChristianSelig/status/1471286155157069827
          16. https://twitter.com/sanguish/status/1471288411290021893
          17. https://twitter.com/stroughtonsmith/status/1471375259513282564
          18. https://twitter.com/RonAvitzur/status/1471685654434045952
          19. https://twitter.com/stroughtonsmith/status/1471905823341359114
          20. https://twitter.com/oskargroth/status/1471820726772678660
          21. https://twitter.com/RonAvitzur/status/1472259552439508996
          22. https://twitter.com/adamkaump/status/1473381003154632707
          23. https://twitter.com/marcoarment/status/1473386393443446790
          24. https://twitter.com/stroughtonsmith/status/1480039605378465792
          25. https://twitter.com/simonbs/status/1481038719188672515
          26. https://twitter.com/joshavant/status/1481067320994938880
          27. https://twitter.com/helje5/status/1483211769359261697
          28. https://twitter.com/helje5/status/1483238845420294146
          29. https://twitter.com/samdeane/status/1484144142150217732
          30. https://www.hackingwithswift.com/articles/210/how-to-fix-slow-list-updates-in-swiftui
          31. https://twitter.com/tapbot_paul/status/1485707873434939398
          32. https://twitter.com/dinhvh/status/1489663022624743428
          33. https://twitter.com/icanzilb/status/1490045181105745937
          34. https://twitter.com/rustyshelf/status/1490561446362873857
          35. https://twitter.com/marcoarment/status/1491048767000399872
          36. https://twitter.com/phillipcaudell/status/1491712806986600455
          37. https://twitter.com/kocienda/status/1491815698674249734
          38. https://twitter.com/stroughtonsmith/status/1491816643122679808
          39. https://twitter.com/elkmovie/status/1491817428929683462
          40. https://twitter.com/RonAvitzur/status/1491871709607051283
          41. https://twitter.com/Freerunnering/status/1492001501979553798
          42. https://twitter.com/Freerunnering/status/1492656382952235008
          43. https://twitter.com/Freerunnering/status/1492673029607985152
          44. https://twitter.com/RonAvitzur/status/1492729491155685376
          45. https://twitter.com/jtaby/status/1493997898538749954
          46. https://twitter.com/jsngr/status/1495061809694449664
          47. https://twitter.com/ronyfadel/status/1496540785487003648
          48. https://developer.apple.com/forums/thread/685797
          49. https://twitter.com/RonAvitzur/status/1497597262792314883
          50. https://twitter.com/stroughtonsmith/status/1502033870904045568
          51. https://twitter.com/ronyfadel/status/1502066373505212418
          52. https://twitter.com/rustyshelf/status/1502113392513138688
          53. https://twitter.com/DamienPetrilli/status/1505500932175446017
          54. https://twitter.com/onmyway133/status/1510194193616015362
          55. https://twitter.com/RonAvitzur/status/1510704004338135041
          56. https://twitter.com/simonbs/status/1512414399453184007
          57. https://twitter.com/stroughtonsmith/status/1512998310990127110
          58. https://twitter.com/stroughtonsmith/status/1513023555365134339
          59. https://twitter.com/KyleHughes/status/1513601035410935814
          60. https://twitter.com/chriseidhof/status/1514118840015372291
          61. https://twitter.com/RonAvitzur/status/1514349787960647681
          62. https://twitter.com/kuba_suder/status/1523655175688589312
          63. https://twitter.com/krzyzanowskim/status/1522995884979482625
          64. https://stevenpcurtis.medium.com/swiftui-still-isnt-production-ready-39c6ee60f391
          65. https://developer.apple.com/forums/thread/691415?page=4
          66. https://twitter.com/jamesthomson/status/1526552860690993154
          67. https://twitter.com/RonAvitzur/status/1528112744574033920
          68. https://twitter.com/PaolaNotPaolo/status/1528638970778816512
          69. https://www.swiftbysundell.com/podcast/116/
          70. https://mjtsai.com/blog/2022/05/23/how-to-open-a-window-in-swiftui/
          71. https://mjtsai.com/blog/2022/04/19/swiftui-performance-tips/
          72. https://mjtsai.com/blog/2022/03/29/lifetime-of-state-properties-in-swiftui/
          73. https://mjtsai.com/blog/2022/02/10/micro-blog-moving-ios-app-to-react-native/
          74. https://mjtsai.com/blog/2021/12/21/how-to-find-why-a-swiftui-view-is-updating/
          75. https://mjtsai.com/blog/2021/09/06/the-persistent-gravity-of-cross-platform/
          76. https://mjtsai.com/blog/2021/08/11/1password-8-for-mac-early-access/
          77. https://mjtsai.com/blog/2021/07/19/swiftui-examples-for-macos/
          78. https://mjtsai.com/blog/2021/06/08/shortcuts-for-mac/
          79. https://mjtsai.com/blog/2021/02/26/apple-documentation-and-swiftui-for-mac/
          80. https://mjtsai.com/blog/2020/12/24/swiftui-layout-explained/
          81. https://mjtsai.com/blog/2020/11/30/what-is-not-so-great-about-swiftui/
          82. https://mjtsai.com/blog/2020/09/18/the-state-of-swiftui/
          83. https://mjtsai.com/blog/2020/08/06/emulating-equal-size-constraints-in-swiftui/
          84. https://twitter.com/SteveStreza/status/1529189751063859205
          85. https://twitter.com/pilky/status/1529217321398673408
          86. https://twitter.com/radiantav/status/1529248785116893184
          87. https://twitter.com/mluisbrown/status/1529412686978629634
          88. https://twitter.com/matthewfx/status/1529419703374184448
          89. https://twitter.com/terhechte/status/1529422786665467904
          90. https://twitter.com/vinibaggio/status/1529427265968300035
          91. https://twitter.com/samdeane/status/1529433920491737091
          92. https://github.com/elegantchaos/FastList
          93. https://twitter.com/mark_volkmann/status/1529494317873647617
          94. https://twitter.com/stroughtonsmith/status/1529438357834633216
          95. https://news.ycombinator.com/item?id=31504354
          96. https://daringfireball.net/linked/2022/05/25/swiftui-may-2022
          97. https://twitter.com/daringfireball/status/1529587368331980801
          98. https://twitter.com/lucvandal/status/1529652411345817601
          99. https://twitter.com/KevinBHayes/status/1529657787885801473
          100. https://news.ycombinator.com/item?id=31505201
          101. https://martiancraft.com/blog/2022/05/swiftui-quickstart/
          102. https://mjtsai.com/blog/tag/ios/
          103. https://mjtsai.com/blog/tag/ios-15/
          104. https://mjtsai.com/blog/tag/mac/
          105. https://mjtsai.com/blog/tag/macos-12/
          106. https://mjtsai.com/blog/tag/programming/
          107. https://mjtsai.com/blog/tag/swift-programming-language/
          108. https://mjtsai.com/blog/tag/swiftui/
          109. https://mjtsai.com/blog/tag/top-posts/
          110. https://mjtsai.com/blog/2022/05/24/swiftui-in-2022/#comments
          111. http://PacificT.com
          112. https://t.co/zwoQwOTkYg
          113. https://twitter.com/glotcha
          114. https://mjtsai.com/blog/2022/05/24/swiftui-in-2022/feed/
          115. https://mjtsai.com/blog/2022/05/24/the-apple-gpu-and-the-impossible-bug/
          116. https://mjtsai.com/blog/2022/05/24/corey-b-marion-rip/
          117. https://mjtsai.com/blog/
          118. https://mjtsai.com/blog/archives/
          119. https://mjtsai.com/blog/tag-cloud/
          120. https://twitter.com/mjtsai
          121. https://mjtsai.com/blog/recently-updated/
          122. https://mjtsai.com/blog/feed/
          123. https://mjtsai.com/blog/comments/feed/
          124. https://apple.news/TOe8IoEHXTDKknwyO8gNRTQ
          125. https://mjtsai.com/blog/2022/05/24/swiftui-in-2022/trackback/
          126. https://www.patreon.com/mjtsai
          127. https://c-command.com/dropdmg/
          128. https://c-command.com/eaglefiler/
          129. https://c-command.com/spamsieve/
          130. https://c-command.com/toothfairy/
          131. mailto:mjt@mjtsai.com