I see that you force unwrapped response. Is the respose part of the data task completion block guarenteed to have a value? If yes, why is it optional in the first place?Thank you very much if you answer this, because I couldn't find a good explanation for it.

I'm facing this issue in Xcode 11.7

I'm also facing this issue in iOS 14.2. Here's a simple example that is causing Buttons to not be tappable when edit mode is on: struct ContentView: View { 		let items = ["A", "B", "C"] 		@State private var selectedItem: String? 		var body: some View { 				List(selection: $selectedItem) { 						Section(header: Text("Select an Item")) { 								ForEach(items, id: \.self) { item in 										Text(item) 								} 						} 						Button("Next") { 								print("You selected: \(selectedItem)") 						} 				} 				.listStyle(InsetGroupedListStyle()) 				.environment(\.editMode, .constant(.active)) 		} } Trying to tap on the button will not print the string to on the console. As soon as I set the edit mode to .constant(.inactive), the button is tappable again and the print works. I have tried replacing the the button with the following: Button("Next", action: {}) 		.onTapGesture { 				print("You selected: \(selectedItem)") 		} But this hack only triggers the tap if it is exactly on the button text. Any tap in the remaining area of the list row will not trigger the onTapGesture. I'm not sure if this is an incorrect implementation of single selection lists on my side or if it's a bug in SwiftUI.

I was able to view my crash logs in Xcode by downloading them from App Store Connect then right-click the .crash file and choose Open With > Xcode. After that the same behavior as clicking the Open in Project button from Xcode organizer; It will ask me which project to open and then I can view the crash report and trace it in code. This is just a workaround. I hope this original issue is fixed so that the same crashes in App Store Connect > TestFlight > Crashes appear inside Xcode > Organizer > Crashes.

ViktorEvil, your solution is correct. The problem you're getting an error is that you are initializing the Trail.scn file inside createTrail(color:geometry:) which is called inside spawnShape() which is called inside renderer(_:updateAtTime:), which causes your console to print the following: [SceneKit] Error: Scene <SCNScene: 0x2803f5500> is modified within a rendering callback of another scene (<SCNScene: 0x2803e0000>). This is not allowed and may lead to crash The solution to fix this is to initialize the SCNScene for the trail outside createTrail(color:geometry:). I got the hint from this StackOverflow answer - https://stackoverflow.com/a/52792424/10654098. So you need to declare a new variable in GameViewController: var trailScene: SCNScene! Then, create a function: func setupTrailScene() { &#9;&#9;trailScene = SCNScene(named: "Trail.scn")! } Then call this function in viewDidLoad(). Then modify your createTrail(color:geometry:) to use the instance variable trailScene instead of declaring the constant inside: func createTrail(color: UIColor, geometry: SCNGeometry) -> SCNParticleSystem { &#9;&#9; let node: SCNNode = (trailScene.rootNode.childNode(withName: "Trail", recursively: true)!)! &#9;&#9; let particleSystem: SCNParticleSystem = (node.particleSystems?.first)! &#9;&#9; particleSystem.particleColor = color &#9;&#9; particleSystem.emitterShape = geometry &#9;&#9; return particleSystem } I think this is the best workaround so far, which is to create a particle system node inside a .scn file and get the particle system from that node.

I'm also facing this issue and trying to find a solution for it. I don't think the nonce here is the same as Apple's nonce. I'm guessing this Content Security Policy directive is a separate thing that requires it's own nonce, hash, or the keyword unsafe-inline to be added somewhere. I'm continuing to find a solution to this problem with no luck so far. Note that I'm configuring the authorization object using the JavaScript APIs, not by using markup, and facing the same issue. html script type="text/javascript" src="https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js"/script div id="appleid-signin" data-color="black" data-border="true" data-type="sign in"/div script type="text/javascript" AppleID.auth.init({ clientId : '[CLIENT_ID]', scope : '[SCOPES]', redirectURI : '[REDIRECT_URI]', state : '[STATE]', nonce : '[NONCE]', usePopup : false }); /script I'm also using Google Chrome to test my Sign In with Apple implementation.

I know this question is very old, but I would love to know if that's possible.

I faced the same issue when adding a unit testing bundle target to my project after already signing and distributing it to the Mac App Store. I was using the "Automatically manage signing" checkbox for my main app target. To fix this I had to uncheck that box and check it again before adding the unit testing bundle. I don't know what happened under the hood, but this solved it for me.

I'm also looking for any workarounds to fix this behavior in iOS 14. I haven't tested iOS 15's ColumnNavigationViewStyle yet.

If you manage existing accounts for users such as education accounts or enterprise accounts. For example if you are a university that distributes accounts for students and want them to use the app only if they authenticate with the university account. Then it's OK to not implement Sign In with Apple. However, if you use MSAL to authenticate personal accounts ending with @outlook.com or similar, while the user have the ability to register an account using your own UI with an email and password, then I guess this makes MSAL the same as any other 3rd party authenticator and you have to provide Sign In with Apple as well.

I'm still seeing this issue in Xcode 12.5.1 I wonder if it was fixed in Xcode 13 beta or not, but I can install it on my computer.

As of Xcode 13.3 and iOS 15.4, the keyboard onboarding screen does not count as an interruption by the XCTest framework and does not trigger a call to the interruption handler closure of addUIInterruptionMonitor(withDescription:handler:). I created this convenient function that taps a keyboard key while also handling the keyboard onboarding screen. It should minimize the chances of failing a test that interacts with the keyboard. extension XCUIApplication { /// Taps the specified keyboard key while handling the /// keyboard onboarding interruption, if it exists. /// - Parameter key: The keyboard key to tap. func tapKeyboardKey(_ key: String) {     let key = self.keyboards.buttons[key]     if key.isHittable == false {         // Attempt to find and tap the Continue button         // of the keyboard onboarding screen.         self.buttons["Continue"].tap()     }     key.tap() } }

I'm also facing this issue in a brand new iOS project in Xcode 14 (14A309) with a minimum deployment target of iOS 16. I tried changing the Lock setting from the Identity Inspector's Document section for both the navigation controller and its navigation bar. I also tried manually assigning an empty delegate to my view controller's navigationController?.navigationBar property, but all of these attempts did not resolve this assertion message. I'm assuming it is simply an oversight; one of those harmful internal logs that should be hidden, but left visible by mistake, as it doesn't seem to cause any visual issues for me when using the default navigation controller scene in the storyboard. I hope it will be fixed or silenced in Xcode 14.1

I'm facing this exact same problem. And the only solution is to delete the certificate from Keychain Access, which lets Xcode prompt me to revoke it, then Xcode generates a trusted one the next time, then the cycle repeats and it happens every time. I don't understand the root cause and seem to be stuck to where @mungbeans latest findings are.

I'm also facing this issue in Xcode 14.1 If I put a breakpoint inside any async function and try to po any value in the local scope of the function, I get the cannot find in scope message. The workaround for now is to use the good old print() and print the values at run time. I hope there's a solution for this.