Tagged with swiftui

• Hiding the Keyboard Using FocusState in SwiftUI

  When you're entering text in a mobile app, it's a common expectation to tap outside of the text field to dismiss the keyboard.

  I've been implementing this in a current project using SwiftUI, and was surprised to find it fairly undocumented online, so I thought I'd write up my solution.

  There are articles talking about FocusState, which is available from iOS 15. This Hacking With Swift article is a great example. It shows how to use FocusState to dismiss the on-screen keyboard when tapping a button.

  But I haven't seen any articles talking about how to dismiss the keyboard using a background tap. And it's a really simple addition to the description in the Hacking With Swift approach.

  Just set an onTapGesture on the parent view:

  @FocusState private var isTextFieldFocused: Bool
  
  VStack { // or whatever your containing view is
      TextField
      ... // configure as normal
      .focused($isTextFieldFocused)
  }
  .onTapGesture {
      isTextFieldFocused = false
  }
  

  This almost feels too easy, so if you have any feedback on this approach, please let me know on Mastodon or on Bluesky.

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  19 February 2025

  • swiftui

• Be Careful Using SwiftUI's buttonStyle Modifier With List swipeActions

  SwiftUI has a really useful swipeActions modifier on List rows - see the SwiftUI docs here. It lets you add a swipe gesture to show action buttons on that row. For example, a delete button. (You've seen this in apps like Mail, where you swipe to get actions like Move or Archive/Delete.)

  When I was adding it to an app recently, I found a bit of a strange bug. I just couldn't get the swipeActions to work; the gesture did nothing.

  I discovered this article about swipeActions on samwize.com and it identified my bug:

  If you were to apply any button style (eg. system borderless or custom styles), then the button will NOT show up at all.

  The problem is, if you set a button style on a parent view, then it'll apply to all of the buttons within that view. That's usually a great thing about SwiftUI: you can apply a style to all subviews of a view by setting the modifier at a top level view. But for swipeActions to work, you'll have to explicitly use the modifier .buttonStyle(.automatic) on your buttons in swipeActions to set buttonStyle back to the default:

  .swipeActions {
  	Button {
  		// some action
  	} label: {
  		Label("Some Action", systemImage: "some.action.image")
  	}
  	.buttonStyle(.automatic)
  }
  

  I think I understand the source of the problem - the buttonStyle has to be .automatic for the buttons to be rendered properly in swipeActions, and if you have some custom style then it could be really awkward to render.

  But I strongly disagree with the solution the SwiftUI team have gone with, where the swipeActions modifier has no effect with a custom buttonStyle. Better to make the core action work, and break the styling, than to honour the styling and make the action silently fail.

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  10 February 2025

  • swiftui

• SwiftUI ButtonStyle

  A while ago, I created a button in SwiftUI. It's a simple button, but I want to be able to use this design in lots of places in my app. It has the app's theme colours, it has a particular font, it has a pill-shaped rounded appearance.

  I initially created this as a View, wrapping a Button with some customisations.

  struct PurpleButton: View {
      let buttonTitle: String
      let action: () -> Void
  
      var body: some View {
          Button(buttonTitle, action: action)
              .frame(maxWidth: .infinity)
              .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
              .font(.system(.title3, design: .rounded))
              .foregroundStyle(Color(.darkBackgroundText))
              .background(Color(.primary))
              .clipShape(Capsule())
      }
  }
  

  This gives me a PurpleButtonView, whose sole contents are a Button, styled how I want. But SwiftUI has a better way.

  By using a ButtonStyle, you can customise a Button's appearance without wrapping it, avoiding creating that extra view in the view hierarchy.

  struct PurpleButtonStyle: ButtonStyle {
      func makeBody(configuration: Configuration) -> some View {
          configuration.label
              .frame(maxWidth: .infinity)
              .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
              .font(.system(.title3, design: .rounded))
              .foregroundStyle(Color(.darkBackgroundText))
              .background(Color(.primary))
              .clipShape(Capsule())
      }
  }
  

  You can then create a Button in the normal, simple way, and apply the style.

  #Preview {
      Button("Press Me") { print("Button pressed") }
          .buttonStyle(PurpleButtonStyle())
  }
  

  You can clean this up a bit by creating an extension on ButtonStyle to define a static variable.

  extension ButtonStyle where Self == PurpleButtonStyle {
      static var purpleButton: Self {
          PurpleButtonStyle()
      }
  }
  
  #Preview {
      Button("Press Me") { print("Button pressed") }
          .buttonStyle(.purpleButton)
  }
  

  The extension works really well if you have a standard style but want to provide different customisations.

  extension ButtonStyle where Self == PurpleButtonStyle {
      static var purpleButton: Self {
          PurpleButtonStyle(.standard)
      }
  
      static var secondaryPurpleButton: Self {
          PurpleButtonStyle(.secondary)
      }
  
      static var cancelPurpleButton: Self {
          PurpleButtonStyle(.cancel)
      }
  }
  

  This pattern appears throughout SwiftUI. Styles are a great way to customise a component's appearance, often quite heavily, without having to wrap or try to subclass a core component.

  Resources

  That's quite a simple example for one button style. Here are some resources I found useful when learning about ButtonStyle:

  • Apple documentation on View styles
  • Apple documentation on ButtonStyle
  • Hacking With Swift
  • Use Your Loaf
    

    ---

    
    If you liked this article, please consider buying me a coffee to support my writing.

  6 September 2024

  • swiftui
  • tip

• Hiding A SwiftUI View From Switch Control

  I'm currently working on a project to enhance the accessibility of an app, and I'm learning a lot about how far iOS's accessibility support goes beyond a screen reader. There's a really cool technology called Switch Control that enables users to control their iPhones using an external tool, like a button, a game controller, or even a straw.

  I ran into a problem with supporting Switch Control when I was building a custom View component in SwiftUI. The component is essentially a label, and shouldn't be visible to Switch Control. But it wasn't easy to find out how to hide it. Switch Control is such a vague term that I got a lot of results for custom control components called switches, and some results about using a Nintendo Switch controller too.

  The solution to my problem was quite easy, once I found it. A one-line SwiftUI modifier:

  .accessibilityRespondsToUserInteraction(false)
  

  Here is the relevant part of the docs from Apple:

  Explicitly set whether this Accessibility element responds to user interaction and would thus be interacted with by technologies such as Switch Control, Voice Control or Full Keyboard Access.

  ---

  Find out more about Switch Control

  Switch Control is a really cool technology, but not widely known or talked about. Here are some interesting articles from people using it, if you want to find out more:

  • App accessibility for Switch Control from WWDC 2020.
  • I Used a Switch Control for a Day.
  • Switch Control Changed My World.
    

    ---

    
    If you liked this article, please consider buying me a coffee to support my writing.

  4 September 2024

  • accessibility
  • 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()
  }
  

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  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!

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  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")
  	}
  }
  

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  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.
    

    ---

    
    If you liked this article, please consider buying me a coffee to support my writing.

  25 January 2022

  • swiftui