Open Radar

 
Summary:
With the addition of shared pasteboards across multiple devices, UIPasteboard has become slow, due to the nature of network requests.

This may be acceptable if the user taps on 'Paste' somewhere in the app and then waits for the content to transfer. But there are many other use cases where the program first needs to have a look at the content in the pasteboard before presenting anything to the user. This is not possible.

If you call e.g. `-[UIPasteboard string]` and it detects a string in the pasteboard of another device, this sometimes shows an alert view to the user informing him about the fact that data may take some time to transfer to the current device. Furthermore it also locks the main thread (rdar://28787338). This again is okay if the user just tapped 'paste', but if this was triggered by some part of the app to programmatically check things in the pasteboard, this is not suitable and totally destroys the user experience.

Therefore calls like `-[UIPasteboard loadStringWithCompletionHandler:]` or `-[UIPasteboard loadURLWithCompletionHandler:]` are necessary. These should not trigger any UI and don't block the main thread, while processing the request.

Steps to Reproduce:
Look at the header of `UIPasteboard`.

Expected Results:
There is some kind of asynchronous API available.

Actual Results:
There is nothing like that available.

Version:
iOS 10

Notes:


Configuration:
Xcode 8

Attachments: