User Profile

Place the .xcodesamplecode.plist in your foo.xcworkspace directory if you have a workspace named foo. If you are just working with a project, place it in your foo.xcodeproj dir.The content should be:<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array/> </plist>As soon as I did that, Xcode 11 immediately rendered my README file. It looked quite good too.I did not need to tweak the display mode for that file. Unfortunatley, local file navigation does not work, but external links do and the default browser in your system immediately navigates to them in a new tab. This content is also readonly, so I have to use MacDown to edit externally. Thankfully, saving the file immediately causes Xcode to re-render the new content.Good luck!

dpe.qa, We've been experiencing very similar issues as well since moving up to Xcode 11 (both on Mojave and Catalina).We are seeing deep DVTFramework and other CoreFoundation memory exceptions that are so far removed from user level code, I'm getting the funny feeling that the runtime environment is experiencing both memory and thread exhaustion. SInce we never *ever* saw any crashes this sever prior, I suspect the new iOS 13 APIs are expecting a less constrained environment. I have no formal proof for this assertion, but this pattern matches previous behavior I have seen on other *NIX based environments.Now, with that being said, for S&Gs we temporarily moved our large amount of XCTest Classes to run serially and they all run just fine. Even on a poky little Mac Mini. Unfortunately an integration takes hours, not minutes. So this isn't a long term solution for us. We can run in parallel on our new spiffy Mac Book Pros just fine. However, even there we're seeing unexpected behavior of a Simulator Clone "failing" to start and thus gives us a false negative report at the end of the integration.My suggestion is to dig into the run logs and see if you can find the actuall crash. Through the Bot system, I can navigate into the failed integration and actually download the entire .tgz of build/test logs. There should be 1+ .crash logs in that bundle that will immediatly give you the stack dump for the crash.