I have the following code I use to grab text that a user has copied to the clipboard from outside the app so they can paste it in within the app:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
if ([pasteboard hasStrings])
{
NSString *text = pasteboard.string;
}
This has always worked fine, until iOS14 I notice I've been getting crashes because pasteboard.string is nil despite hasStrings being true.
I looked into the documentation and discovered that indeed, it's possible for pasteboard.string to be nil:
The value stored in this property is an NSString object. The associated array of representation types is UIPasteboardTypeListString, which includes type kUTTypeUTF8PlainText. Setting this property replaces all current items in the pasteboard with the new item. If the first item has no value of the indicated type, nil is returned.
I take this mean to that some sort of string that is not kUTTypeUTF8PlainText is in the clipboard and that's why pasteboard.string is nil, but is this the correct interpretation?
I'm just confused as to what exactly is happening here and am unsure what to tell my user if I reach the case where pasteboard.string is nil?
-[UIPasteboard hasStrings] == YESonly means the items in pasteboard have type ofpublic.utf8-plain-textor any other types that indicates it's a string.But
-[UIPasteboard string]can still returnnilif object of classNSStringcannot be constructed from any data provided byitemProviders.Here is an example to reproduce the situation you are in:
First implement a test class that conforms to
NSItemProviderWritingThen put the test object into pastboard