{"id":28108,"date":"2020-02-11T16:21:41","date_gmt":"2020-02-11T21:21:41","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=28108"},"modified":"2020-02-26T14:14:23","modified_gmt":"2020-02-26T19:14:23","slug":"more-about-swiftui","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/02\/11\/more-about-swiftui\/","title":{"rendered":"More About SwiftUI"},"content":{"rendered":"

Apple<\/a> (via Tony Arnold<\/a>):<\/p>\n

You’ll start by adding a macOS target to your project, and then reusing the shared data you created for the iOS app. With all of the assets in place, you’ll create SwiftUI views to display list and detail views on macOS.<\/p>\n

Follow the steps to build this project, or download the finished project to explore on your own.<\/p><\/blockquote>\n\n

Chris Eidhof<\/a>:<\/p>\n

\n

After a few months spent delving into SwiftUI, we decided to write a short book: it’s called Thinking in SwiftUI<\/a>. Since SwiftUI is still in its early days, the book focuses on the concepts behind the framework that we believe are essential to understand. It is not a reference for SwiftUI’s platform-specific APIs, but rather a guide to honing your intuition about how SwiftUI works.<\/p>\n<\/blockquote>\n\n

Nikita Prokopov<\/a> (Hacker News<\/a>):<\/p>\n

\n

First, the general approach SwiftUI is taking (reactive declarative data-driven UI framework) is really solid and considered state-of-the-art as of the current day of the year. No complaints here, great job, we all needed that, thank you Apple for releasing it. No, seriously. It’s a great tool and I’m looking forward to using it.<\/p>\n

But, a few things I noticed in SwiftUI concern me. I think they could illustrate points in the UI framework design that future systems could handle better. Without further ado, let’s start with the biggest problem in API design: commas!<\/p>\n<\/blockquote>\n\n

Will Townsend<\/a>:<\/p>\n

Today I’ll explain how to create your own Button Styles, and hopefully show you the difference between ButtonStyle<\/code> and PrimitiveButtonStyle<\/code>, and why you’d use one or the others.<\/p><\/blockquote>\n\n

Scott James Remnant<\/a> (via Joshua Emmons<\/a>):<\/p>\n

\n

One of the first things presented about SwiftUI is that its views choose their own sizes, and that once chosen, those choices cannot be overridden. This is such a simple statement that it would be easy to move on quickly to get to the good stuff.<\/p>\n

This would be a mistake, because this simple statement fundamentally changes everything you know about layout.<\/p>\n

[…]<\/p>\n

This doesn’t contradict what we’ve just learned about chosen sizes not being able to be overridden, it actually demonstrates another key principle we haven’t learned yet: a view receives a proposed size from its parent before it chooses its own size.<\/p>\n<\/blockquote>\n\n

Alexander Grebenyuk<\/a>:<\/p>\n

\n

SwiftUI no longer uses Auto Layout, gone all of the cruft introduced over the years. SwiftUI has a completely new layout system designed from the ground up to make it easy to write adaptive cross-platform apps. […] I can’t be more excited to dig deep into the SwiftUI layout system to see what it has to offer.<\/p>\n<\/blockquote>\n\n

Ole Begemann<\/a>:<\/p>\n

\n

SwiftUI’s layout algorithm may be simple on the surface, but the way the built-in views and view modifiers interact is tremendously complex (and largely undocumented).<\/p>\n<\/blockquote>\n\n

Javier<\/a>:<\/p>\n

\n

After spending some time testing the limits of alignment guides, I arrived at the conclusion that they do work. However, there’s confusion about what we expect from them. This confusion comes from not realizing there’s a whole set of implicit alignment guides in effect. When we ignore them, things do not go our way.<\/p>\n<\/blockquote>\n\n

Javier<\/a>:<\/p>\n

\n

In this short article, we are going to explore several aspects of View equality. We’ll see what happens when we make a view conform to Equatable, and what is the purpose of EquatableView and the .equatable() modifier.<\/p>\n<\/blockquote>\n\n

Javier<\/a>:<\/p>\n

\n

If you’ve been using SwiftUI for a while now, you probably hit the problem where you find yourself trying to update the state of a view from inside its body. Usually, Xcode complains during runtime. When it does, you are forced to put your update inside a DispatchQueue closure (not feeling too good about yourself) but you carry on anyway. Does this sound familiar? In this article, we’ll discuss why it sometimes is perfectly fine to apply that technique, but some other times, it’s a no-no (leading to CPU spikes or app crashes).<\/p>\n<\/blockquote>\n\n

Jared Sorge<\/a>:<\/p>\n

\n

In my last post<\/a> I talked about some of the struggles I’m having getting up to speed with SwiftUI. Let’s dive in to a couple of examples.<\/p>\n<\/blockquote>\n\n

Rob Whitaker<\/a>:<\/p>\n

\n

Apple has taken the chance to re-think how some of their accessibility tools work for developers, and they’ve baked in accessibility right from the very beginning. Apple’s accessibility teams have been an integral part of some of the decisions that have shaped SwiftUI. You can see this throughout your SwiftUI code.<\/p>\n<\/blockquote>\n\n

Mattt Thompson<\/a>:<\/p>\n

\n

It’s hard to overstate how much of a game-changer Xcode Previews are for iOS development, and we couldn’t be happier to incorporate them into our workflow.<\/p>\n<\/blockquote>\n\n

Kishikawa Katsumi<\/a>:<\/p>\n

\n

I published SwiftUI online playground<\/a>.<\/p>\n

You can try SwiftUI and see the rendering results insanely easily.😊<\/p>\n<\/blockquote>\n\n

Thomas<\/a>:<\/p>\n

\n

I tried to replicate my app’s GUI using SwiftUI. Couldn’t get the basic layout right: standard controls do not size themselves correctly. Also, popup buttons do not draw their menu correctly. SwiftUI is plain broken on macOS.<\/p>\n<\/blockquote>\n\n

I continue to hear about problems like this.<\/p>\n\n

Wooji Juice<\/a>:<\/p>\n

\n

If you want to make a Mac app, there are 4<\/em> primary APIs you could be using, in a sorta 2x2 grid: AppKit, UIKit (w\/Catalyst), SwiftUI-in-AppKit, SwiftUI-in-UIKit. It’s a complex mess of what each does\/doesn’t support — figuring out which to use for any given UI is trial & error<\/p>\n

I’ve been trying to make one relatively simple bit of UI (in a standalone testbed app) for days. Every time I think I’m on a roll, I bump into a different wall of missing functionality. I try different implementations. I try different designs that don’t need same features.<\/p>\n

It’s not even like you can say “Screw it, I’ll do everything old-school pure native AppKit and get access to everything”, cuz you’ll still be missing some things (e.g. SF Symbols aren’t supported, even tho they are all available on Mac since Catalyst apps can use them).<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n