{"id":42459,"date":"2024-03-11T16:45:23","date_gmt":"2024-03-11T20:45:23","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42459"},"modified":"2025-12-16T15:48:32","modified_gmt":"2025-12-16T20:48:32","slug":"mac-dialog-in-auto-layout-vs-swiftui","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/03\/11\/mac-dialog-in-auto-layout-vs-swiftui\/","title":{"rendered":"Mac Dialog in Auto Layout vs. SwiftUI"},"content":{"rendered":"<p><a href=\"https:\/\/christiantietze.de\/posts\/2024\/03\/swiftui-challenge-port-from-auto-layout-to-swiftui\/\">Christian Tietze<\/a> (<a href=\"https:\/\/mastodon.social\/@ctietze\/112056461100585931\">Mastodon<\/a>):<\/p>\n<blockquote cite=\"https:\/\/christiantietze.de\/posts\/2024\/03\/swiftui-challenge-port-from-auto-layout-to-swiftui\/\">\n<p>On Mastodon, we had a discussion about whether you are more or less productive with SwiftUI or UIKit\/AppKit. <a href=\"https:\/\/layer8.space\/@teilweise\/112053743588688616\">Der Teilweise (@teilweise@layer8.space) chimed in<\/a> with an actual, measurable benchmark: a flexible-width window, with reflowing text, and equal-size buttons. Doable in 10 minutes. Can SwiftUI beat this?<\/p>\n<p>[&#8230;]<\/p>\n<p>Here&rsquo;s the <a href=\"https:\/\/github.com\/DivineDominion\/10min-Window-AutoLayout\">reference implementation<\/a> on GitHub.<\/p>\n<p>[&#8230;]<\/p>\n<ul>\n  <li>Richard Kolasa <a href=\"https:\/\/iosdev.space\/@notkoalas\/112056933483899940\">got pretty far<\/a> in 6mins, but the default SwiftUI window has too much free movement :)<\/li>\n  <li>Mike Apurin <a href=\"https:\/\/hachyderm.io\/@auramagi\/112057426851975548\">points out<\/a> that window resizing is hell (<a href=\"https:\/\/gist.github.com\/auramagi\/c505b2c4493090e1dc7a4132c08ae0b1\">Code<\/a>).<\/li>\n  <li>Ryan Lintott <a href=\"https:\/\/mastodon.social\/@ryanlintott\/112058221729989102\">shared<\/a> a solution that reflows the text and increases window height properly (<a href=\"https:\/\/gist.github.com\/ryanlintott\/06e25c3945224b4dd5e3d821ef5027ec\">Code<\/a>). Uses <a href=\"https:\/\/github.com\/ryanlintott\/FrameUp\">his FrameUp library<\/a> to help with the layout.<\/li>\n<\/ul>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@auramagi@hachyderm.io\/112057463322600176\">Mike Apurin<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@auramagi@hachyderm.io\/112057463322600176\"><p>Debating whether SwiftUI is &ldquo;production-ready&rdquo; in 2024 is an eye-roll argument, though. It has, limitations, sure, but what doesn&rsquo;t?<\/p><\/blockquote>\n\n<p>&ldquo;Production-ready&rdquo; is probably not the right question. It is clearly being used in production. But you could look at how easy it is to make standard Mac layouts that were straightforward with the old system. In this particular example, it seems like sort of the anti-Perl: easy things made hard but possible. If you look at the SwiftUI layouts in Apple&rsquo;s apps, they generally don&rsquo;t sweat these <a href=\"https:\/\/toot.community\/@betalogue\/110736462246333560\">details<\/a>. SwiftUI <a href=\"https:\/\/toot.community\/@betalogue\/110742769485936479\">started on watchOS<\/a>, which doesn&rsquo;t really have resizable windows and where buttons are usually full width and stacked vertically. On the other hand, there are certain types of layouts and data flow that are easier in SwiftUI.<\/p>\n\n<p><a href=\"https:\/\/hachyderm.io\/@auramagi\/112057426851975548\">Mike Apurin<\/a>:<\/p>\n<blockquote cite=\"https:\/\/hachyderm.io\/@auramagi\/112057426851975548\">\n<p>Sadly, the way <code>windowResizability<\/code> works makes it impossible to implement this without a <code>GeometryReader<\/code> or a <code>Layout<\/code>, and even then it&rsquo;s a bit janky. SwiftUI needs something like the compression resistance priority here.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/layer8.space\/@teilweise\/112059620349587254\">Der Teilweise<\/a>:<\/p>\n<blockquote cite=\"https:\/\/layer8.space\/@teilweise\/112059620349587254\">\n<p>Today I&rsquo;d say SwiftUI has its pros and cons. I still doubt that it is better than UIKit\/AppKit. It&rsquo;s (just) different.<\/p>\n<p>I like the good things about Autolayout more than I like the good things in SwiftUI. And I hate the bad things in SwiftUI passionately while I have made peace with the bad things in UIKit.<\/p>\n<p>(We all thought Autolayout errors were the worst possible &#8230;)<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@isaiah\/112061125036378419\">Isaiah Carew<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@isaiah\/112061125036378419\"><p>there is, of course, no way to build a UI that changes with content using springs and struts. it&rsquo;s all  top-down constraints.<\/p><p>that said, here&rsquo;s my quick UI:<\/p><ul><li>keeps the buttons the same size.<\/li><li>maintains correct spacing.<\/li><li>margins don&rsquo;t scale, just buttons.<\/li><\/ul><p>there&rsquo;s not much to it, so it went pretty fast.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@stroughtonsmith\/110512181525685982\">Steve Troughton-Smith<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@stroughtonsmith\/110512181525685982\"><p>I added an AppKit target to the @broadcastsapp codebase just to experiment, and of 245 source files only 11 are portable  All the pre-existing SwiftUI code is uncompilable, because even basic things like size classes don&rsquo;t have a macOS equivalent or translation. I continue to believe that the AppKit SwiftUI target is simply a dead end and needs to be rolled into the Universal app platform instead. I don&rsquo;t want to continue with this bringup experiment at all.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.justtact.com\/@jaanus\/110581564242314245\">Jaanus Kase<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.justtact.com\/@jaanus\/110581564242314245\">\n<p>Another thing that &ldquo;should be easy in macOS SwiftUI but isn&rsquo;t&rdquo;:<\/p>\n<p>Reopening a window after closing it, with the correct position, size and split view pane sizes.<\/p>\n<p>It works correctly if I quit the app and restart. Window is restored with previous metrics (automatically stored in UserDefaults).<\/p>\n<p>It does not work correctly if I close the window and click on the Dock icon which opens a new window. I expect the new window to have same metrics as the one I just closed, but nope.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@onmyway133\/110583747206860210\">Khoa<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@onmyway133\/110583747206860210\">\n<p>This same code runs fine on Mac but causes severe hangs on iOS<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/krzyzanowskim\/status\/1673736525824114690\">Marcin Krzyzanowski<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/krzyzanowskim\/status\/1673736525824114690\"><p>Not me implemented 90% of functionality with the new SwiftUI API, only to learn the missing 10% is impossible because it&rsquo;s missing configuration, and now rewriting it to something else.<\/p><p>it&rsquo;s just annoying that SwiftUI API is so very closed. one can rarely add missing piece without reimplementing a thing from the ground. That aspect is very much the opposite of UIKit etc.<\/p><p>I would say it&rsquo;s &ldquo;make easy things easy, and hard things impossible&rdquo; philosophy<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@siracusa\/110611106375982347\">John Siracusa<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@siracusa\/110611106375982347\"><p>My SwiftUI view and its containing NSHostingView\/NSWindow are not getting along, and I think it&rsquo;s an Apple bug.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@marcoarment\/110686631993631622\">Marco Arment<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@marcoarment\/110686631993631622\"><p>Seems like everyone here is stumped, just like I was.<\/p><p>Does SwiftUI REALLY not support basic table-cell animation after four years? I assume it&rsquo;s me, not the framework&#8230;<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/tanmays\/status\/1677559051406680067\">Tanmay<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/tanmays\/status\/1677559051406680067\">\n<p>SwiftUI is terrible when it comes to reliability for building any custom interactive component. Random things just break in the next release. If you want to build fluid, interactive designs for iOS that are rock stable, stick with UIKit.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@marioguzman\/110722225613599243\">Mario Guzm&aacute;n<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@marioguzman\/110722225613599243\"><p>Still experimenting with SwiftUI for Macintosh layouts because some of the toolbar item placement options and controls just don&rsquo;t have the flexibility they do in AppKit.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@vandal\/110752426596363254\">Luc Vandal<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@vandal\/110752426596363254\"><p>Keyboard shortcuts for toolbar items not showing when holding the &#x2318; key on iPad: am I doing something wrong or is it just another &ldquo;not yet supported in SwiftUI&rdquo; thing?<\/p><p>So of course the solution was obvious (sarcasm)! Adding .labelStyle(.titleAndIcon) to the Label is the way to go. So many SwiftUI dark patterns&#8230;<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/www.swiftjectivec.com\/meta-threads-ios-interface-in-swiftui\/\">Jordan Morgan<\/a>:<\/p>\n<blockquote cite=\"https:\/\/www.swiftjectivec.com\/meta-threads-ios-interface-in-swiftui\/\">\n<p>In my previous <a href=\"https:\/\/swiftjectivec.com\/Snip-Context-Menu-Preview-Shape-in-SwiftUI\/\">snip<\/a>, I used a cheeky Threads knockoff interface to demonstrate the subject matter. It occurred to me how crazy it is <em>that I can even do this<\/em>. SwiftUI has done away with so much work that used to be pervasive in interface programming, interface builder or not.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@chbeer\/110827530259758257\">Christian Beer<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@chbeer\/110827530259758257\"><p>SwiftUI is awesome for starters&#8230; just until you get some strange error on a ForEach: &ldquo;Cannot convert value of type &#x201A;[XYZ]&lsquo; to expected argument type &lsquo;Range&lt;Int&gt;&rsquo;&rdquo; that worked perfectly until you wrote the wrong action code in a Button somewhere.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/merowing_\/status\/1688969167553105921\">Krzysztof Zab&#x142;ocki<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/merowing_\/status\/1688969167553105921\"><p>So many weird bugs in SwitUI, e.g. adding <code>contextMenu<\/code> steals all touches from the underlying view instead of just around that view, thus making overlay components break underlying UI interactions&#8230;<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@oskargroth\/110840619825503937\">Oskar Groth<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@oskargroth\/110840619825503937\">\n<p>No macOS SwiftUI component has let me down as much as List. Just when you think you&rsquo;ve got it working well, there is always some tiny issue relating to reorder, DisclosureGroup expansion, highlight or layout.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@mattiem\/110870848228766398\">Matt Massicotte<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@mattiem\/110870848228766398\">\n<p>I&rsquo;ve been doing some experimentation with SwiftUI on macOS 14. Things are working amazingly well. I have yet to find anything weird, broken, or nonfunctional. Interop with AppKit world is excellent.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@chockenberry\/110873196128994764\">Craig Hockenberry<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@chockenberry\/110873196128994764\"><p>Here&rsquo;s a surprisingly hard thing to implement in SwiftUI: a panel that contains a resizable image that looks right on both iOS and tvOS..<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/ruby.social\/@collin\/110878388177616093\">Collin Donnell<\/a>:<\/p>\n<blockquote cite=\"https:\/\/ruby.social\/@collin\/110878388177616093\">\n<p>Things are easier in SwiftUI, except debugging, debugging sucks.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/bynkiidotcom.wordpress.com\/2023\/09\/07\/school-project-fun\/\">John C. Welch<\/a>:<\/p>\n<blockquote cite=\"https:\/\/bynkiidotcom.wordpress.com\/2023\/09\/07\/school-project-fun\/\">\n<p>I&rsquo;ll be adding to this post as I go along as a way of documenting some of the &ldquo;fun&rdquo; bits of SwiftUI[&#8230;]<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@clarko\/111032331162953677\">Clarko<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@clarko\/111032331162953677\">\n<p>Really frustrating to spend the day reworking on macOS UI, getting it really responsive and snappy, and then the exact same SwiftUI code on iOS and iPadOS runs like sludge.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/github.com\/orchetect\/SettingsAccess\">Steffan Andrews<\/a> (<a href=\"https:\/\/www.reddit.com\/r\/SwiftUI\/comments\/16ibgy3\/settingslink_on_macos_14_why_it_sucks_and_how_i\/\">Reddit<\/a>):<\/p>\n<blockquote cite=\"https:\/\/github.com\/orchetect\/SettingsAccess\"><p>Apple completely removed the ability to open the SwiftUI Settings scene using legacy <code>NSApp.sendAction()<\/code> method using the <code>showSettingsWindow:<\/code> (macOS 13) or <code>showPreferencesWindow:<\/code> (macOS 12 and earlier) selectors. The only available method of opening the Settings scene (apart from the <em>App menu &#x2192; Settings<\/em> menu item) is to use the new <a href=\"https:\/\/developer.apple.com\/documentation\/swiftui\/settingslink\"><code>SettingsLink<\/code><\/a> view.<\/p><p>This presents two major restrictions:<\/p><ol><li>There is no way to detect when the user has clicked this button if additional code is desired to run before or after the opening of the <code>Settings<\/code> scene.<\/li><li>There is <strong>no<\/strong> way to programmatically open the <code>Settings<\/code> scene.<\/li><\/ol><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@benedictc@mas.to\/111409130260901400\">BenedictC<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@benedictc@mas.to\/111409130260901400\"><p>I blame the annual cycle in part for the fundamental problems in Swift and SwiftUI. There&rsquo;s a proposal to add a feature for property specific inits (a bonkers idea). It exists to patch a problem with macros, which fixed a problem with property wrappers, which were added to allow SwiftUI to subvert value type semantics. I believe if Apple had spent more time dog fooding SwiftUI it would be very different. No amount of pausing to fix bugs will allow Apple to fix the fundamentals.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@chbeer\/111142249628250810\">Christian Beer<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@chbeer\/111142249628250810\">\n<p>I still can&rsquo;t get over the fact that in SwiftUI you can&rsquo;t create a Table with a dynamic set of columns. And I don&rsquo;t mean reordering or resizing. I mean: you can&lsquo;t use <code>if<\/code> or <code>ForEach<\/code> when creating table columns. &#x2639;&#xFE0F;<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@chbeer\/111079949911767468\">Christian Beer<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@chbeer\/111079949911767468\"><p>We&rsquo;re in year 4 of SwiftUI and building a good multiplatform document based app is still hard to impossible.<\/p><p>Building a VERY simple document based app, with DocumentGroup and TextEditor, like the sample is easy. But doing more than that is hard: DocumentGroup with NavigationSplitView? Forget it. Customizing document creation? Forget it&#8230;<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@ctietze\/111419171851824710\">Christian Tietze<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@ctietze\/111419171851824710\"><p>Today is the day on which I realize:<\/p><p>I like working in SwiftUI more than I like building programmatic interfaces in AppKit.<\/p><p>It&rsquo;s not even close. I&rsquo;m really annoyed by all the wiring[&#8230;]<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/iosdev.space\/@nemesisprime\/111422082249469745\">Dandy Griffin<\/a>:<\/p>\n<blockquote cite=\"https:\/\/iosdev.space\/@nemesisprime\/111422082249469745\">\n<p>This chain speaks to me so much! I&rsquo;m in the process of reducing SwiftUI usage in my only macOS app because it just seems to fall apart. I find AppKit tedious, but reliable, and there&rsquo;s ~always~ a solution. Even hacky solutions in AppKit\/UIKit never feel as fragile or hacky as SwiftUI hacks.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/ohanaware.com\/blog\/2024\/01\/Lovin'-SwiftUI.html\">Sam Rowlands<\/a> (<a href=\"https:\/\/twitter.com\/Sam_Ohanaware\/status\/1741664579145667014\">tweet<\/a>):<\/p>\n<blockquote cite=\"https:\/\/ohanaware.com\/blog\/2024\/01\/Lovin'-SwiftUI.html\">\n<p>SwiftUI has really helped make Mac development more exciting (for me), and further cements how far outa the race Xojo is. At this point, I don&rsquo;t think there is anything Xojo can do to catch up, but I believe they know that already.<\/p>\n<p>Sure it&rsquo;s not without it&rsquo;s downfalls, adapting some of the work flows to the SwiftUI way, can be a massive paradigm shift, and sometimes feels like hacky spaghetti code. Alerts for instance feel unnatural, but I can see why they&rsquo;ve done them this way.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@marcoarment\/111477507905262362\">Marco Arment<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@marcoarment\/111477507905262362\"><p>Sometimes, I wonder if I&rsquo;ve made a huge mistake by tackling a giant rewrite of my 10-year-old ObjC\/UIKit app in Swift\/SwiftUI that&rsquo;ll probably end up costing me ~1.5 years of development time.<\/p><p>Then I try to do ANYTHING with ANY new API in the old codebase from Objective-C and UIKit.<\/p><p>It quickly becomes apparent that this rewrite was not much of a choice &mdash; it&rsquo;s a necessity.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/Sam_Ohanaware\/status\/1751427827923374564\">Sam Rowlands<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/Sam_Ohanaware\/status\/1751427827923374564\"><p>SwiftUI Mac, changing focus from one TextField to another marks the document as &ldquo;Edited&rdquo;, even when the text wasn&rsquo;t changed in either TextField.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@chbeer\/111969037024277649\">Christian Beer<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@chbeer\/111969037024277649\"><p>We achieved a lot more stable code with Swift (in comparison to Objective-C; I know it&rsquo;s discussable)&#8230; but we lost so much with SwiftUI!<\/p><p>SwiftUI\/EnvironmentObject.swift:90: Fatal error: No ObservableObject of type BottomBarViewModel found. A View.environmentObject(_:) for BottomBarViewModel may be missing as an ancestor of this view.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@chbeer\/112019289604763595\">Christian Beer<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@chbeer\/112019289604763595\"><p>Theoretically SwiftUI previews in Xcode are a good idea. But if it takes A LOT longer to just view this preview than to start the app and navigate to that view, or even &ldquo;Failed to launch app &ldquo;XCPreviewAgent.app&rdquo; in reasonable time&ldquo;&#8230; it&rsquo;s just not helpful.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/layer8.space\/@teilweise\/112019586392073512\">Der Teilweise<\/a>:<\/p>\n<blockquote cite=\"https:\/\/layer8.space\/@teilweise\/112019586392073512\">\n<p>One of the things I hate about SwiftUI is the crappy visual editor. It&rsquo;s light years behind what we had for Storyboards. It&rsquo;s not even as good as the original Interface Builder was.<\/p>\n<p>Even in Visual Studio (201x!) editing of Windows Forms is way better. And that, too, parses code to build the UI! Change a line of code in the *.Designer.cs, switch the view: Boom, there&rsquo;s you UI.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/krzyzanowskim\/status\/1677628085217243137\">Marcin Krzyzanowski<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/krzyzanowskim\/status\/1677628085217243137\"><p>I didn&rsquo;t expect that, but SwiftUI.TextEditor lagging on edit for relatively short text. I can feel it lag while I&rsquo;m typing letters.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/Sam_Ohanaware\/status\/1766070231334617526\">Sam Rowlands<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/Sam_Ohanaware\/status\/1766070231334617526\"><p>I came to the conclusion that SwiftUI.textEditor refreshes the entire content each time, I think the same happens for TextField also. Wrapped NSControls don&rsquo;t suffer from the same problems.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/twitter.com\/mpweiher\/status\/1766078064990040171\">Marcel Weiher<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/mpweiher\/status\/1766078064990040171\">\n<p>Well, refreshing everything each time is kind of the underlying model.<\/p>\n<\/blockquote>\n\n<p>See also: <a href=\"https:\/\/atp.fm\/539\">Accidental Tech Podcast<\/a>.<\/p>\n\n<p>Previously:<\/p>\n<ul>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/02\/13\/dragging-from-a-list-with-swiftui\/\">Dragging From a List With SwiftUI<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/12\/05\/keyboardcowboy-3-19\/\">Keyboard Cowboy 3.19<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/08\/23\/timestory-dev-journal\/\">TimeStory Dev Journal<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/08\/11\/appkit-vs-swiftui-stable-vs-shiny\/\">AppKit vs. SwiftUI: Stable vs. Shiny<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/07\/06\/swiftui-data-flow-2023\/\">SwiftUI Data Flow 2023<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2022\/07\/13\/interfacebuilder-swift\/\">InterfaceBuilder.swift<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2022\/06\/17\/thoughts-on-swiftui-after-wwdc-2022\/\">Thoughts on SwiftUI After WWDC 2022<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2022\/05\/31\/swiftui-equal-and-ideal-sizes\/\">SwiftUI Equal and Ideal Sizes<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2020\/08\/06\/emulating-equal-size-constraints-in-swiftui\/\">Emulating Equal-Size Constraints in SwiftUI<\/a><\/li>\n<\/ul>\n\n<p id=\"mac-dialog-in-auto-layout-vs-swiftui-update-2024-03-14\">Update (2024-03-14): See also: <a href=\"https:\/\/ifnotnil.com\/t\/not-sure-how-i-feel-about-this\/3884\">If Not Nil<\/a>.<\/p>\n\n<p id=\"mac-dialog-in-auto-layout-vs-swiftui-update-2024-04-08\">Update (2024-04-08): <a href=\"https:\/\/eclecticlight.co\/2024\/04\/07\/last-week-on-my-mac-swiftui-wrangling\/\">Howard Oakley<\/a>:<\/p>\n<blockquote cite=\"https:\/\/eclecticlight.co\/2024\/04\/07\/last-week-on-my-mac-swiftui-wrangling\/\"><p>Another fundamental problem I&rsquo;ve run into is the app life cycle. Many Mac apps start with a brief initialisation phase, during which they might check required resources, look online for app updates, and load app-wide preferences and menus. Once those are complete or under way, the app turns to the task of opening documents and their windows, perhaps. Then, when the user quits the app, there&rsquo;s a completion phase in which any last changes to settings are made, and the app gracefully exits. When using AppKit, these are normally accomplished in an AppDelegate, but <a href=\"https:\/\/developer.apple.com\/documentation\/swiftui\/nsapplicationdelegateadaptor\">Apple cautions against that<\/a> for SwiftUI. In a box marked <strong>Important<\/strong>, it states: &ldquo;Manage an app&rsquo;s life cycle events without using an app delegate whenever possible.&rdquo;<\/p><p>For someone porting an app from AppKit to SwiftUI, that comes as a bit of a bombshell, and implies that Apple hasn&rsquo;t worked out exactly how to convert common AppDelegate functions into SwiftUI&rsquo;s App protocol. After five years, that&rsquo;s more than a little unhelpful.<\/p><\/blockquote>\n\n<p id=\"mac-dialog-in-auto-layout-vs-swiftui-update-2024-06-04\">Update (2024-06-04): <a href=\"https:\/\/mastodon.social\/@ryanlintott\/112558883942683530\">Ryan Lintott<\/a> (via <a href=\"https:\/\/layer8.space\/@teilweise\/112558919668729223\">Der Teilweise<\/a>):<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@ryanlintott\/112558883942683530\">\n<p><a href=\"https:\/\/github.com\/ryanlintott\/FrameUp\">FrameUp<\/a> updated to v0.8!<\/p>\n<p>New <code>.equalWidthPreferred()<\/code> and <code>.equalHeightPreferred()<\/code> modifiers.<\/p>\n<\/blockquote>\n<p>This looks like a great way of easily handling a common case. Something like this should be built into SwiftUI.<\/p>\n\n<p id=\"mac-dialog-in-auto-layout-vs-swiftui-update-2024-06-12\">Update (2024-06-12): <a href=\"https:\/\/x.com\/DylanMcD8\/status\/1798525286692106681\">Dylan<\/a>:<\/p>\n<blockquote cite=\"https:\/\/x.com\/DylanMcD8\/status\/1798525286692106681\">\n<p>My biggest problem with SwiftUI right now is how terribly under-performant it is. Apple&rsquo;s most powerful iOS device ever, powered by the cutting-edge M4 chip, can&rsquo;t do this layout animation without horrible choppiness and hangs.<\/p>\n<\/blockquote>\n\n<p id=\"mac-dialog-in-auto-layout-vs-swiftui-update-2024-12-17\">Update (2024-12-17): <a href=\"https:\/\/github.com\/siracusa\/SwiftUIUntruncatedText\">John Siracusa<\/a>:<\/p>\n<blockquote cite=\"https:\/\/github.com\/siracusa\/SwiftUIUntruncatedText\">\n<p>The goal of this demo is to have all three lines of text visible in the green box (which is within the red box) even as the window is resized. Also, toggling the number of lines of text should shrink and grow the both the green and the red boxes so that they are just big enough to contain all the lines of text.<\/p>\n<p>(<em>Ideally<\/em>, the window itself would also shrink and grow in response to the number of lines of text changing, but one thing at a time.)<\/p>\n<\/blockquote>","protected":false},"excerpt":{"rendered":"<p>Christian Tietze (Mastodon): On Mastodon, we had a discussion about whether you are more or less productive with SwiftUI or UIKit\/AppKit. Der Teilweise (@teilweise@layer8.space) chimed in with an actual, measurable benchmark: a flexible-width window, with reflowing text, and equal-size buttons. Doable in 10 minutes. Can SwiftUI beat this? [&#8230;] Here&rsquo;s the reference implementation on GitHub. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2024-03-11T20:45:27Z","apple_news_api_id":"123af4bf-4f13-46a3-8c07-ec7a765285ee","apple_news_api_modified_at":"2024-12-17T14:15:45Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAABg==","apple_news_api_share_url":"https:\/\/apple.news\/AEjr0v08TRqOMB-x6dlKF7g","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[200,69,30,2385,2868,74,71,901,1812],"class_list":["post-42459","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-autolayout","tag-cocoa","tag-mac","tag-macos-14-sonoma","tag-nsuserdefaults","tag-opensource","tag-programming","tag-swift-programming-language","tag-swiftui"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/42459","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=42459"}],"version-history":[{"count":8,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/42459\/revisions"}],"predecessor-version":[{"id":46182,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/42459\/revisions\/46182"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=42459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=42459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=42459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}