For my macOS command tool, this goes away in macOS Sonoma. Your log looks identical to mine, but only occurred when writing to HEIF on macOS. Occurs in macOS Ventura 13.5 (22G74). Does not occur in macOS Sonoma 14.0 (23A5301h).

I had an issue with Xcode 15.0 beta 5 (15A5209g) where I received the blocking error The LLDB RPC server has crashed.. I was unable to run the Playground nor proceed. My project is a Swift Package & Playground and I found that removing the folder.swiftpm made the error go away. That directory has a folder structure that looks like Breakpoint XMLs. It's possible this was corrupted and causing the blocking error. Most of my research mentioned breakpoints were the problem. Hoping this helps someone in the future.

I attempted to use .addOverlay(:), and received the error in "This method is defined on MKMapView, and may not be available in this context.". Submitted FB12784156

I found this document useful: "Minimum OS Required" for Xcode from https://developer.apple.com/support/xcode/. It's a matrix that details Xcode Version, Minimum OS Required, SDK, Swift version plus other info.

Issue still exists under the same test conditions with Xcode Version 14.0 RC (14A309) which was released on Sep 7, 2022.

Issue still exists under the same test conditions with Xcode Version 14.0 beta 6 (14A5294g). Also tested with macOS 13 beta 6 (22A5331f).

Issue still exists under the same test conditions with Xcode Version 14.0 beta 5 (14A5294e).

Issue still exists under the same test conditions with Xcode Version 14.0 beta 4 (14A5284g).

We have encountered a similar crash on iOS 15.2 (device & simulator), but not on iOS 14.4 (simulator) and have filed Feedback Assistant: FB9812333. Our public tracking issue is https://github.com/roblabs/Maps-for-Messages/issues/1 Issue Uncaught exception NSInternalInconsistencyException while reviewing Apple Sample Code for iMessage apps. Fails in Xcode 13.2 with an iOS 15.2 device & Simulator. Same sample code works on iOS 14.4 simulator. Same sample code works on Xcode 12.5 with an iOS 14.5 simulator. Steps to reproduce This is reproducible with open source code. Since we are reviewing the open source code, we are not sure how to proceed. Review the sample code Creating a Sticker App with a Custom Layout posted at developer.apple.com. Test with Xcode Version 13.2 (13C90) Build for iOS 15.2 Simulator or iOS 15.2 device *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'the view returned from -collectionView:viewForSupplementaryElementOfKind:atIndexPath: does not match the element kind it is being used for. When asked for a view of element kind 'section-header-element-kind' the data source dequeued a view registered for the element kind 'Text'.' terminating with uncaught exception of type NSException The element kind reference, section-header-element-kind, is a string defined in the view controller class. iOS 14.4 simulator works While completing the same steps in an iOS 14.4 simulator, the Apple Sample code works. Test with Xcode Version 13.2 (13C90) Build for iOS 14.4 Simulator

Our team had a similar issue with Metal Compiler Warning in the Xcode console log. One side note is that even though the Xcode log says that it is a Warning, the Xcode Instruments tool says it's an Error. I was able to spend a 1/2 hour with two Metal engineers during WWDC Lab hours. The discussion with that team was useful and hopefully this helps others down the line: Be sure to test outside of Xcode, as Xcode does Extra Metal Validation. Here are two entries in our log related at the start of the Metal portion of the code. Metal GPU Frame Capture Enabled Metal API Validation Enabled In the Simulator, the container path changes, possibly every time (TBD), which could cause the Metal code to be re-compiled While using instrumentation via Xcode Instruments, be sure to watch for the MetalCompilerService in Instruments and the Console logs. Verify if the Metal Compiler Warnings go away in the condition after a reboot (“ this is expected to happen”).

If you check the video for Host and automate your DocC documentation, the discussion on Apache says that your web server should be able to customize requests including how to route them. Search the transcript for Vue.js web app. Quote from the transcript: if the request starts with /documentation/ or /tutorials/ then the server should respond with the index.html file that's located in the documentation archive There is a Node server, called serve that does just that. Using this server, I was able to locally host documentation & tutorials. # using https://www.npmjs.com/package/serve serve -h | grep requests #      -s, --single                        Rewrite all not-found requests to `index.html` My example usage for SlothCreator: # Build # path to Xcode 13 Beta, adjust when its out of Beta # having a known output builder folder is helpful when searching for the output /Applications/Xcode-beta.app/Contents/Developer/usr/bin/xcodebuild \ docbuild \ -scheme "SlothCreator" \ -derivedDataPath tmp/derivedDataPath # Serve # Find the Doc Archive, # then serve over port 4001 using https://www.npmjs.com/package/serve find tmp/derivedDataPath \ -name "*.doccarchive" \ -exec serve --listen 4001 --single {} \; # open in Safari open http://localhost:4001/documentation/SlothCreator open http://localhost:4001/tutorials/SlothCreator Bonus: would be nice to have this served over GitHub Pages

You can navigate to jwt.io which has a Debugger where you can paste & validate your token. Paste only test tokens as a security measure. The kid in your token generation scheme should be the 10 character key identifier that matches your private key. For example, if your MapKit JS Private Key File is B22B2BBB22.p8, then your MapKit JS Key ID is B22B2BBB22. Use that as your kid. From https://developer.apple.com/documentation/mapkitjs/creating_and_using_tokens_with_mapkit_js A 10-character key identifier (kid) key, obtained from your Apple Developer account. Response from jwt.io with your key that you pasted above. { "alg": "ES256", "typ": "JWT", "kid": "maps.liftme.pro" }

You can navigate to jwt.io which has a Debugger where you can paste & validate your token. Paste only test tokens as a security measure. As well, the jwt package has an option called expiresIn which you can set as {expiresIn: '364d'} to expire in about a year.

We had the exportArchive issue in Xcode Server (XCS) with a Xcode Project that has two schemes: iOS & tvOS. The iOS project was archiving fine from XCS, but the tvOS was not. We were certain that the signing credentials were properly set in Xcode Accounts. I'm not sure if this is the exact configuration others have, but hopefully these notes may help you. We were receiving the same error "exportArchive: Found no compatible export methods" while archiving a tvOS target in XCS. Build Service Error: exportArchive: Found no compatible export methods for: DVTFilePath:0x7fd42ffa1ae0:'/path/to/XCSBuilder/Integration-cfc0379b9feddb8619595042d58/tvOS.xcarchive' iOS archiving worked as expected and was located in the same Xcode Project. The only we to get the archiving to work for the tvOS scheme was to do the following: edit the Xcode Server Bot (XCS) for that tvOS scheme that wasn't archiving properly verify that Devices for the tvOS bot was only set to build for tvOS Devices only. The other options in the XCS Bot editor were to build with a tvOS Simulator or not. Once we turned off Simulator builds, archiving started working. Server API v19 Xcode 12.4 (12D4e), macOS 11.2.3 (20D91) We have a bunch of notes & examples on how to optimize XCS for your build process: https://github.com/roblabs/xcode-continuous-integration