Just to post an update since I bumped into this from google, with Xcode 12.4 and iOS 14.4 this issue is still going strong. In my case I got around it by a combination of restarts and reconnects PLUS I needed to connect my iOS device via cable instead of WiFi.

Just another report of same issue, Version 15.2 (15C500b) MacOS 13.6.3, Intel 16" Macbook Pro: ld: warning: building for 'macCatalyst', but linking in dylib (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa.tbd) built for 'macOS' ld: warning: building for 'macCatalyst', but linking in dylib (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL.tbd) built for 'macOS'

Unfortunately it's part of a pretty large project and I haven't been able to reproduce the issue with a simpler one. It's hard to understand what in my own code could be driving it though since I would assume the dictation service is just interacting with the text field and the keyboard plays no role except to be informed viaUITextInputDelegate-textDidChange after the text is entered. No other calls to the keyboard happen, and in any case the factors determining casing are the UITextInputTraits and context in the text field.

Some more data points. Many people have reported this post-dictation lowercasing problem starting a few years ago, which can be found for example searching Google for 'iphone dictation flipping case' and going to the Reddit results. At the time it occurred for all third-party keyboards and not the stock one. However now it does NOT occur for major third-party keyboards such as Gboard. Also, if I reproduce this, then switch to another keyboard without the problem, dictate there, and then switch back to my keyboard, the problem is gone. It seems like the dictation system is somehow asking the keyboard for information, presumably about the capitalization context in the text field, and for some reason my keyboard doesn't answer. After it gets the information from another keyboard though, it caches this and then uses it for subsequent dictations even in the absence of an answer. However this is puzzling because the keyboard subclasss is not responsible nor exposes any state relating to this – it is the responsibility of the text field which passes a proxy exposed as a proxy by the superclass.