There's no pod specification for pod 'Keyboard+LayoutGuide'.

This is a very handy framework!

Currently keyboardLayoutGuide automatically pins to safeAreaLayoutGuide.bottom.
There is a way to disable it getting a pointer to keyboardLayoutGuide and setting its usesSafeArea property to usesSafeArea.

Issue

There are two cases:

1. Currently you can't pin two existing views to the keyboardLayoutGuide, one taking safeArea into account, the second doesn't — keyboardLayoutGuide is a single instance property.
2. It's not very comfy. You should write something like:

let keyboardLayoutGuide = view.keyboardLayoutGuide // we don't know about the implementation, so we're holding a reference here
keyboardLayoutGuide.usesSafeArea = false
pinnedView.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.topAnchor).isActive = true

Solution

I prefer one from the following:

1. having a separate property for keyboardLayoutGuide with usesSafeArea = false

pinnedView.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.topAnchor).isActive = true
pinnedView.bottomAnchor.constraint(equalTo: keyboardLayoutGuideNoSafeArea.topAnchor).isActive = true

2. having a computed property returning KeyboardLayoutGuide with usesSafeArea turned off

pinnedView.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.topAnchor).isActive = true
pinnedView.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.topAnchor).isActive = true
pinnedView.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.noSafeArea.topAnchor).isActive = true

Achievable via extension like:

public extension KeyboardLayoutGuide {
    var noSafeArea: KeyboardLayoutGuide {
        self.usesSafeArea = false
        return self
    }
}

Currently, if the device is running iOS 11 or newer, the keyboardLayoutGuide.bottomAnchor is always equal to the view's safeAreaLayoutGuide.bottomAnchor.

Sometimes it is nice to be able to pin views to the bottom of the screen, instead of the bottom of the safe area. It would be nice if there was a setting or parameter for determining whether or not the keyboardLayoutGuide uses the safe area.

On iOS 12, the interactive keyboard dismissal in a scroll view does not fire the keyboardWillChangeFrameNotification until the pan gesture ends, so any views constrained to keyboardLayoutGuide.topAnchor remain static throughout the interactive part of the animation.

I am not sure if this worked properly prior to iOS 12.

Nice library!

I have an issue though. There is extra space like shown:

I'm using it like this (inside NSLayoutConstraint.activate([]))
accessoryView.bottomAnchor.constraint(equalTo: view.keyboardLayoutGuide.topAnchor)

Notification.keyboardHeight == screenHeight when you move the floating keyboard

Update to 4.2 please.

I have issue in height initial the app in the chat

view.inputViewContainer.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.topAnchor).isActive = true

Regards!!

Layout guides are not updated if dismiss mode is interactive, is there a way to fix this?

Hello,

First of all congrats for the lightweight and great implementation. It's the best i've seen so far.
There is a bug where when switching the first responder from a normal textfield to a secured textfield, a weird animation is performed. This is cause because for some reason the keyboardWillChangeFrame notification is called not once but three times, the first one being a weird value. In order to fix this, we just have to perform the change animated only when the duration specified in the notification is greater than 0.

Here is a screen recording of the bug: https://my.pcloud.com/publink/show?code=XZO6ibkZ92g9nOy76gbtm7VTohGNg0GDcq27

Hi. I have been using this library for every project I have worked on. Never really had a problem. However this last project we decided using SnapKit.

I have set this button to be aligned with the keyboard. Button does change its position when the keyboard is opened or closed but not along with the keyboard. It just changes its frame at a moment.

Does anyone have any suggestions?

There are cases, when keyboard doesn't intersect view controller's view: e.g. view controller is shown modally with modalPresentationStyle == .formSheet on iPad, however keyboardLayoutGuide is shrinked by the height of the keyboard.

It appears to officially support keyboardLayoutGuide from iOS15+.
view.keyboardLayoutGuide causes errors 'keyboardLayoutGuide' is only available in iOS 15.0 or newer

Reference: https://developer.apple.com/documentation/uikit/uiview/3752221-keyboardlayoutguide

Hi,
firstly, thanks for great library!
I have one question - is it possible to bring back support for other dependency managers? SPM is great and all, but it is not yet suitable for all use cases (e.g. libraries with mixed Swift/Obj-C or with resources). Because of that, lots of projects can't switch to it yet and potentially having two dependency managers (e.g. Cocoapods + SPM) might do more harm than good (e.g. resolving some subdependencies) and confuse other developers.

If that's not something you want to do, then I think it would be good idea to remove Carthage and Cocoapods badges from README

When building an app with KeyboardLayoutGuide from Swift Package Manager in Xcode 13 beta 3 that does not use app extensions, compiler errors related to API availability in app extensions are emitted.

Reproduction Steps

• Create a new iOS project in Xcode 13 beta 3
• Add KeyboardLayoutGuide at latest version (1.7.0) using Swift Package Manager
• Build the app

Result: multiple errors on UIApplication.shared usage:

'shared' is unavailable in application extensions for iOS: Use view controller based solutions where appropriate instead.

Other Notes

This appears to be expected behavior in Xcode 13 beta 3 with Swift Package Manager, based on this Apple Developer Forums thread and this Swift forums post. The Apple engineer in the second link recommends dealing with this by marking declarations as unavailable to app extensions when they use APIs that are unavailable to app extensions.

Update: It looks like the Swift team is reconsidering how this behaves. I'll update this issue as we hear more from them.

The constraint is set but updated incorrectly in an MSMessagesAppViewController.

Great idea for a library.

It works great with the exception that it seems to add an extra safe area to the height of the guide when the keyboard is opened. I think it's because the height in the keyboard notification event takes the safe area into account. Am I understanding safe area wrong?