I found that the answer is to make sure you are assigning your custom UIInputView directly to the UIInputViewController.inputView property, rather than adding it as a subview of .inputView. See my slightly longer answer here: https://developer.apple.com/forums/thread/778827 Hope this helps someone!

I found that the answer is "yes": your custom UIInputView object should be assigned directly to your custom UIInputViewController.inputView property. Make sure that your custom UIInputView has translatesAutoresizingMaskIntoConstraints == YES. iOS will automatically size the keyboard area (ie, .inputView) as the device rotates, etc. You can create a UILayoutGuide and add it to your custom UIInputView (with constraints to each edge), then have all of the subviews setup constraints to the layout guide. I'll also note that assigning my custom UIInputView directly to .inputView also made this warning go away: -[UIInputViewController needsInputModeSwitchKey] was called before a connection was established to the host application. This will produce an inaccurate result. Please make sure to call this after your primary view controller has been initialized. I hope this helps someone.

I found that what matters is how the "client" app creates the item on the pasteboard and what kind of objects it includes in the item. For example, with Google Chrome on the Mac (version 85), if you highlight the URL of the current page in the address bar and copy that text to the clipboard, my iPhone (iOS 14) will just show the pasteboard item as having public.text and public.utf8-plain-text (and com.apple.is-remote-clipboard). In that case, of course, the iPhone UIPasteboard.general will show that it .hasStrings but not .hasURLs. But if I "right-click" a link in Safari on the Mac and choose "Copy Link", then Safari will create a pasteboard item with text and also with public.url. These objects show up on the iPhone, and thus UIPasteboard.general.hasURLs == true.