We were able to resolve this issue. Our problem was that for some provisioning profiles an older, still valid signing certificate was selected. This appeared to be no issue with Xcode 12, but is one with Xcode 13. Selecting the newest signing certificate for each provisioning profile fixed the issue.

Here are images from the sample project: Opening the modal sheet closes the find bar.

I saw the exact same issue. The app has shortcuts configured and uses in-app intent handling. Using these intents with widgets works without issues on the home screen, but not on the Lock Screen. The configuration UI does not show up. The issue seems to be the in-app intent handling for me. Documentation states that an intent extension is required for widgets. As soon as I added one for handling the intent used by the widget, the configuration showed up. This also applies to Widgets for macOS. I don't know why in-app intent handling is allowed for Homescreen widgets but not for the lock screen & macOS.

I see the same issue, no firebase in use. Filed as FB12236547. Adding -ld64 (using the old linker?) works fine for now.

I was not able to activate Siri on my iPad on this screen. However, upon every restart, the iPad asked which WiFi to join. You can just hit continue without joining any WiFi. This will skip the activation step. If the device auto-joins a WiFi, you can tap the Lock-button, which makes a menu appear. From there you can choose WiFi settings. You can hit the info button on the WiFi the device joined and hit Forget this Network.

With SwiftUI's List I found that using Label instead of an HStack and .tint instead of .foregroundColor works, at least on macOS 15. For other lists, like embedding a SwiftUI cell inside an NSTableView, this does not work. However, since macOS 14 there is the backgroundProminence environment value which does exactly what you ask for.

I ran into this issue as well, filed a feedback as well and linked yours. When dignosing the issue to find a fix for this, I doug a bit in the UIKit code. Turns out, UITextView has a (private) method -(BOOL)startAutoscroll:(CGPoint)point which basically takes the input and calculates whether the view should scroll while selecting text. This method uses both contentInset and textContainerInset to inset the visible rect of the text view. To me this looks like a bug, as textContainerInset should not affect the viewport in a way that contentInset does.