Replaced implicit animation modifiers with explicit animation ('withAnimation'), in order to animate all the affected views returned in the content view, thus preventing non-keyboard animation to stuck. (Attached sample project) KeyboardObservingSample.zip

Hi @nickffox, thank you for this project. 🙂 Your solution is so simple and elegant! I need a bit more flexibility and added an offset variable. What do you think about it?

I found a way to hide the keyboard through the window hierarchy:

extension View {
    func endEditing(_ force: Bool) {
        UIApplication.shared.windows.forEach { $0.endEditing(force)}
    }
}

But this is clearly not the best solution. I have not looked at all the code, but it will be sufficient to make this initializer public:

//Keyboard.swift
    public init(animationDuration: TimeInterval, height: CGFloat) {
      self.animationDuration = animationDuration
      self.height = height
    }

    var body: some View {
        KeyboardObservingView {
            NavigationView {
            }
            .onTapGesture {
                self.keyboard.state = Keyboard.State(animationDuration: 0,25, height: 0)
            }
       }
   }

Hello,

I was experimenting with your library and found one use-case it currently doesn't solve.

When you want some view to react on keyboard change with custom transition, you cannot currently do it. I iterated on the solution by @jaywardell, which always animated opacity. And I reimplemented it using view modifier.

Here is a typical use-case. I want to move some view out of the screen when keyboard appears:

How to use it:

Image(systemName: "app.badge")
    .hideOnKeyboard(transition: .offset(x: 0, y: -300))

Let me know what you think about the solution.

Fixes https://github.com/nickffox/KeyboardObserving/issues/5

$ pod lib lint --no-clean

 -> KeyboardObserving (0.2.0)
    - NOTE  | xcodebuild:  note: Using new build system
    - NOTE  | [iOS] xcodebuild:  note: Planning build
    - NOTE  | [iOS] xcodebuild:  note: Constructing build description
    - NOTE  | [iOS] xcodebuild:  note: Execution policy exception registration failed and was skipped: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" (in target 'KeyboardObserving' from project 'Pods')
    - NOTE  | [iOS] xcodebuild:  note: Execution policy exception registration failed and was skipped: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" (in target 'Pods-App' from project 'Pods')
    - NOTE  | [iOS] xcodebuild:  note: Execution policy exception registration failed and was skipped: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" (in target 'App' from project 'App')
    - NOTE  | [iOS] xcodebuild:  warning: Skipping code signing because the target does not have an Info.plist file and one is not being generated automatically. (in target 'App' from project 'App')

Pods workspace available at `/var/folders/hr/v4vtphl130zczzkbpdkbs7qm0000gn/T/CocoaPods-Lint-20191114-20444-soqu5a-KeyboardObserving/App.xcworkspace` for inspection.

KeyboardObserving passed validation.

KeyboardObservingView was causing stuttering behavior during live resize in mac catalyst

This could cause problems in cross-platform project (like mine) Since we don't need to observe the keyboard in mac anyway, we simply don't send back the modifications when in mac catalyst

• Simplified KeyboardObservingView to ignore bottom safe area, and simplified keyboard height calculation for consistency.
• Added KeyboardObserving ViewModifier, and convenience method keyboardObserving on View.

Thanks for creating this Nick. I had a use case which required a slight modification that I thought might be useful for others.

Let's say we have this:

struct TestView: View {
    
    @State var text: String = ""
    
    var body: some View {
        VStack(spacing: 0) {
            Color.blue.frame(height: 300)
            
            Color.red
            
            TextField("Type something", text: $text)
                .frame(height: 100)
                .foregroundColor(Color.white)
                .background(Color.black)
        }
        .keyboardObserving()
    }
}

Using the current KeyboardObserving, the result looks like this:

You can see it modifies the relative sizes of Blue and Red since Blue is constrained while Red is not.

When I wrote my own keyboard avoiders before SwiftUI, I found messing with the frames sometimes gave hard to debug results so I had always preferred to simply use a transformation on the underlying layer and translate everything up.

This gives the following result:

It may not be what your extension intends but thought it was a nice option to have.

• Added empty Example to the library.
• It will be useful if KeyboardObservingView will return Keyboard object as a parameter to ViewBuilder:

KeyboardObservingView { keyboard in 
//
}

I found the issue, when you adding @EnvironmentObject var keyboard: Keyboard to the View. This leads to the fact that the field values are cleared after changing the field on this view or on the next in the nav stack.

• @nickffox What do you think, about using Environment?:

struct KeyboardKey: EnvironmentKey {
    static let defaultValue: Keyboard = Keyboard()
}

extension EnvironmentValues {
    var keyboard: Keyboard {
        get {
            return self[KeyboardKey.self]
        }
        set {
            self[KeyboardKey.self] = newValue
        }
    }
}