| < How to hide the home indicator and other system UI | How to dynamically change between VStack and HStack > |
How to stop system gestures from interfering with your own
Updated for Xcode 14.0 beta 1
New in iOS 16
SwiftUI’s defersSystemGestures() modifier lets us request that our gestures take precedence over the system’s own built-in gestures. This is important in various places, such as games where the user might be swiping around a lot, or when you place your own gestures at the screen edges.
As an example, you might be using a drag gesture to let the user control the value of some input – perhaps they are getting fine control over a color, maybe they are working with audio such as a theremin, or maybe it’s a game where they are swiping to move their character around. Here we could use defersSystemGestures() like this:
struct ContentView: View {
@State private var input = 0.0
var body: some View {
Text("Current value: \(input)")
.frame(maxWidth: .infinity, maxHeight: .infinity)
.contentShape(Rectangle())
.gesture(
DragGesture().onChanged { value in
input = value.location.y - value.startLocation.y
}
)
.defersSystemGestures(on: .vertical)
}
}
Download this as an Xcode project
On iOS that does three distinct things:
- If the user pulls down from the top, rather than Control Center appearing immediately they’ll see a little tab that needs to be pulled again – it’s much harder for them to active Control Center by accident.
- The home indicator will fade to a lower opacity, and if the user drags directly on that faded home indicator then it will fade back in. They can then swipe up again to get to the task switcher or home screen.
- If the user swipes up from the bottom but to either side of the home indicator, our drag gesture will happen instead.
SPONSORED You know StoreKit, but you don’t want to do StoreKit. RevenueCat makes it easy to deploy, manage, and analyze in-app subscriptions on iOS and Android so you can focus on building your app.
Sponsor Hacking with Swift and reach the world's largest Swift community!
Similar solutions…
