v8tr/keyboardavoidanceswiftui

How to move SwiftUI view up when keyboard appears https://www.vadimbulavin.com/how-to-move-swiftui-view-when-keyboard-covers-text-field/

keyboardavoidanceswiftui's Issues

Errors with MergeMany (Xcode 12.4)

Hi @V8tr , I was looking at your article since I am trying to have a common behavior between iOS 13 and iOS 14 regarding the keyboard and I got these errors when I add the extension Publishers:

• MergeMany(willShow, willHide) Conflicting arguments to generic parameter 'Upstream' ('Publishers.MapKeyPath<NotificationCenter.Publisher, CGFloat>' vs. 'Publishers.Map<NotificationCenter.Publisher, CGFloat>')
• .eraseToAnyPublisher() Conflicting arguments to generic parameter 'Self' ('Publishers.MergeMany<Publishers.MapKeyPath<NotificationCenter.Publisher, CGFloat>>' vs. 'Publishers.MergeMany<Publishers.Map<NotificationCenter.Publisher, CGFloat>>')

I am using Xcode 12.4 and my project must support iOS 13 and 14.

Seems that the latest version of Swift MergeMany changed behavior. I am trying to find a solution and create a PR, but I create this issue in case you found the solution :)

Thanks a lot for your contribution to the community :)

Keyboard Scroll View Fix fails

Not sure if it is an iOS 17 issue but it appears none of the Keyboard fixes work. It always seems to move the view even if the TextField is not in the way of the keyboard.

Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-04-13.at.09.03.46.mp4

Difference in behavior between iOS 13 and 14

The screenshot shows two simulators for iPhone 8: one running iOS 13.7 and the other 14.4. The code is identical between them, run from Xcode directly. I have verified the same behavior on a physical iOS 14 device.

In case it matters, the text field is actually hidden, and is in a ZStack with the button on the bottom, to make sure it forces the button to move up above the keyboard. During normal operation, the keyboard is never hidden, though of course we can do so in the simulator.

ViewModifier increases height of view on load.

I applied the View Modifier on a HStack that includes a TextField and a Button. Although the keyboard adaptivity works fine, the initial height has increased and my content has been centred automatically.

            HStack(alignment: .bottom) {
                TextField("Write a Comment", text: $newComment)
                    .padding(.all, 10)
                    .font(.system(size: 12))
                    .background(Color.gray.opacity(0.1))
                    .cornerRadius(10)
                Button(action: {
                    print(self.newComment)
                }) {
                    Image(systemName: "paperplane.fill")
                        .font(.system(size: 20))
                }
                .disabled(newComment.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty)
            }
        .keyboardAdaptive()
            .padding(.all, 10)

UITextView as FirstResponder

Maybe I am missing something, but I'm having an issue that my SwiftUI view loads with a UITextView and in makeUIView I set to view.becomeFirstResponder.

When the view loads, the keyboard is shown immediately and the keyboardAdaptive does not push the view up. If I click the microphone button, then cancel it, keyboardAdaptive kicks in and moves up the view.

What should I be doing to have keyboardAdaptive run on load when a UITextView that needs to be immediately moved up is the FirstReponder.

You might be asking, why don't I just have the view moved up to begin with, but since the app runs on iPad and MacOS, a keyboard is not always always presented if there is a physical keyboard attached.

Tapping between TextFields breaks keyboard avoidance

To reproduce the issue, use 2 TextFields in need of keyboard awareness and tap the lower one. The scroll here will be correct, but tap the upper TextField while the keyboard is still showing and the bottom padding will be too little resulting in a (partially) hidden TextField. This issue seems to be caused by focusedTextInputBottom in the ViewModifier which is calculated based on the already scrolled View.

If I find the time I will look into this further myself. My current solution is taking the bottomPadding at the time of the calculation into account (in the ViewModifier):

var focusedTextInputBottom = UIResponder.currentFirstResponder?.globalFrame?.maxY ?? 0
focusedTextInputBottom` += self.bottomPadding

It seems to fix the problem, but I'm not sure about possible side effects and if this calculation is always right.

Broken on form

Looks like the solution doesn't adapt in a Form

Form {
//add text fields

}.keyboardAdaptive()

```
that's how I built my form as soon as I tap the text field it is not visible anymore on the screen.

Globalframe does not return the global frame in all cases