Tagged with swiftui

• UI Previews in Xcode 15

  Apple keeps reminding us that the best way to write new apps is with SwiftUI. But for those of us who are working on existing apps, UIKit is often still the reality.

  SwiftUI has had previews in Xcode from the start. It's a great feature, because it helps you see your UI code while you're writing it. You can sort of get it working with UIKit too, but it's a bit hacky and it never feels to me like it's meant to work.

  Now, Previews support UIKit and SwiftUI equally well, with the new #Preview macro. (This also simplifies creating previews on SwiftUI, which makes me happy.) Here's how to create a preview of a UIViewController:

  #Preview {
      MyViewController()
  }
  

  And here's how to create a preview of a SwiftUI View:

  #Preview {
      MyView()
  }
  

  Really simple, and there's no difference between SwiftUI and UIKit. Really cool to see!

  This code below contains two previews, a SwiftUI one and a UIKit one. You can have these side by side in the same file and it works nicely.

  import UIKit
  import SwiftUI
  
  class MyViewController: UIViewController {
      override func viewDidLoad() {
          super.viewDidLoad()
  
          let label = UILabel(frame: view.bounds)
          label.text = "Hello, world!"
          label.font = UIFont.preferredFont(forTextStyle: .title1)
          label.textAlignment = .center
          view.addSubview(label)
      }
  }
  
  struct MyView: View {
      var body: some View {
          VStack {
              Text("Hello, world!")
                  .font(.title)
          }
          .padding()
      }
  }
  
  #Preview("UIKit") {
      MyViewController()
  }
  
  #Preview("SwiftUI") {
      MyView()
  }
  

  7 June 2023

  • xcode
  • wwdc23
  • uikit
  • swiftui

• Making SwiftUI Buttons with Equal Widths

  I've been writing some SwiftUI recently for my run tracking app and I hit a really annoying problem.

  It's really common to have two buttons, one above another, and to have those buttons be the same size. However, when I tried to do this by laying out Buttons in a VStack, they wrapped to the smallest width needed to fit the labels. That meant that every button was a different width.

  

  I wasn't especially surprised about this. It makes sense for the default behaviour to be for the Button s to take up as much space as they need and no more. But I knew my use case was pretty common, so I went looking for ways in which I could make it work. And there are a few, it turns out. It's a common use case, but not one especially well-supported in SwiftUI...

  My first ports of call were the articles on exactly this subject on Swift by Sundell and Hacking with Swift. I trust these two sources to have good solutions, and I usually find they have something that works cleanly.

  Then I saw that there are all sorts of solutions to this, including using GeometryReader and even PreferenceKey! Seems a bit messy. But I knew one of the solutions would work, right?

  Nope.

  I tried every option and got no further forward. My Buttons were even clipping in some cases so that they lost their rounded edges. Clearly SwiftUI was trying to do something, because it seemed like the Buttons were being sized up then cut back down to their original sizes, losing the rounded edges in the process. But it wasn't doing what the articles suggested.

  

  So I went back to Google. And I found this article by Sarun Wongpatcharapakorn. In it I found something interesting:

  [W]e need to apply .frame(maxWidth: .infinity) before we apply a button style.

  I'd been using that approach, setting the frame on the Button as described in the quote, then setting .fixedSize(horizontal: false, vertical: true) on the containing VStack. So this seemed relevant to my problem.

  But when does the button style get applied? I wasn't explicitly applying a style, but as someone fairly new to SwiftUI I assumed that it wouldn't matter in which order I applied modifiers to my views. Turns out that was naive! And I don't understand the logic of my solution either.

  Here's my first Button code, which clips the images:

  struct PurpleButton: View {
      let buttonTitle: String
      let action: () -> Void
  
      var body: some View {
          Button(buttonTitle, action: action)
              .font(.system(.title3, design: .rounded))
              .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
              .foregroundColor(.white)
              .background(.purple)
              .frame(maxWidth: .infinity)
              .clipShape(Capsule())
      }
  }
  
  // Preview, where I generate the images in the screenshots throughout the article.
  // The `fixedSize` modifier is used in here for an example.
  struct PurpleButton_Previews: PreviewProvider {
      static var previews: some View {
          VStack {
              PurpleButton(buttonTitle: "Hello I am a button", action: {})
              PurpleButton(buttonTitle: "Hello I am a button with a longer title", action: {})
              PurpleButton(buttonTitle: "Hello", action: {})
          }
          .padding()
          .fixedSize(horizontal: false, vertical: true)
      }
  }
  

  And here's the fixed Button: I moved the frame(maxWidth: infinity) modifier before the .background modifier gets applied.

  struct PurpleButton: View {
      var body: some View {
          Button(buttonTitle, action: action)
              .font(.system(.title3, design: .rounded))
              .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
              .foregroundColor(.white)
              .frame(maxWidth: .infinity)
              .background(.purple)
              .clipShape(Capsule())
      }
  }
  

  That generated what I wanted! But why?

  

  That's still after the font and foregroundColor are applied, so which styling modifiers count towards "applying a button style"?

  In the final version of the code, at the bottom of this article, I've moved the frame and padding to be set first, then the colour and style modifiers afterward, to group things more logically.

  I've written this up so that I have a solution when I come to do this again, and hopefully to help anyone else who hits this same problem. But also in the hope that I can follow this up with a better explanation of why this happened! If you understand what I was doing wrong here, and why the order of the modifiers mattered in such a strange way (some styling modifiers got in the way of the layout system but others were fine?) then please let me know!

  I am enjoying using SwiftUI a lot of the time, but when you hit things like this which just make no sense it really does make me question learning it.

  ---

  Code Snippet

  Here's the final working code for my custom Button, and a preview that shows it:

  import SwiftUI
  
  struct PurpleButton: View {
      let buttonTitle: String
      let action: () -> Void
  
      var body: some View {
          Button(buttonTitle, action: action)
              .frame(maxWidth: .infinity)
              .font(.system(.title3, design: .rounded))
              .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
              .foregroundColor(.white)
              .background(.purple)
              .clipShape(Capsule())
      }
  }
  
  struct PurpleButton_Previews: PreviewProvider {
      static var previews: some View {
          VStack {
              PurpleButton(buttonTitle: "Hello I am a button", action: {})
              PurpleButton(buttonTitle: "Hello I am a button with a longer title", action: {})
              PurpleButton(buttonTitle: "Hello", action: {})
          }
          .padding()
          .fixedSize(horizontal: false, vertical: true)
      }
  }
  

  ---

  Update
  
  Sean Heber explained to me on Mastodon what’s happening here. His thread explains it really well, so I won’t try to paraphrase it, other than to say that the order of modifiers matters because they don’t actually *modify* the `View`s, they create new ones…
  
  Here’s the link to his thread. Thanks Sean!

  1 November 2022

  • swiftui

• List Sections in SwiftUI

  I'm aware that I'm very late to this party. But this is still really cool.

  In SwiftUI, if you want to create a table view (which is actually called a List, in SwiftUI terminology) section, you can just pass in a view for the header and footer, and list the views that should be inside it. In UIKit, this is multiple lines of calls to the UITableViewDelegate. In SwiftUI, it's all just a handful of lines of code!

  List {
  	Section(header: Text("My Section").bold(), footer: Text("Footer information about my section")) {
  		Text("Row 1")
  		Text("Row 2")
  		Text("Row 3")
  	}
  }
  

  22 April 2022

  • swiftui

• SwiftUI State Links

  I've been playing around with SwiftUI recently. It's been fun to learn in many ways, but managing state is one of the more confusing aspects of it.

  There are many property wrappers for managing state in SwiftUI. When do you use @State, @ObservedObject, @EnvironmentObject etc?

  Here are a few links to blog posts that can explain it pretty well:

  • The obligatory Swift By Sundell post.
  • The obligatory Hacking With Swift post.
  • This article from Jared Sinclair is another cool guide.

  25 January 2022

  • swiftui