Post not yet marked as solved
Are you sure that the Xcode console should be <private> for private arguments? They don't seem to be for the WWDC 2023 session on the subject, which matches the "unstructured" behavior in Xcode 14.
If we can't see the private strings and values in Xcode, then there's no point in logging at all. If we have to use the privacy: .public modifier to see them in the Xcode 15 console, then we're also exposing the data to the system log.
I think you need the contentShape modifier:
.contentShape(Rectangle())
maybe after the .frame modifier. Clicking on the whitespace in the 200x200 area should work after that.
Post not yet marked as solved
The only way I could make this work when running the application from within Xcode was to shut down the application using its own Quit menu while the sidebar was open. Just re-starting the app by hitting the "run" button would close the sidebar again.
When you Archive the app and run outside of Xcode, it seems to open with the sidebar visible no matter what state it was in when you closed it. At that point, saving the "closed" state via NavigationSplitView's visibility property is probably how you'd want to preserve sidebar open/close across restarts. Maybe that would work when running from Xcode, too?
Also, if you notice in the message output window, there's some warning about being able to read certain kinds of preferences, which is maybe an issue ONLY when run within Xcode.
Post not yet marked as solved
At least for me, this is fixed in Xcode 13.3 beta. I can enabled the EnableSwiftBuildSystemIntegration switch and code completion works. The FB I filed had about 10 other reports, too, so I hope that between all of us, they found the issue.
Post not yet marked as solved
Ok, if any of you are still here, did you enable that "make builds faster" mode with Xcode 13.2?
defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 1
That thing?
Try:
defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 0
and see if it turns the completion and quick-help back on. Seems to work for me.
Post not yet marked as solved
New information that I'm not at all sure is helpful.
I installed (from downloads):
Xcode 13.1
Xcode 13.2
Xcode 13.2.1
If I open my project in Xcode 13.1, clean, build, then attempt to do something like let x = String( I get all the string constructors as you'd expect. AND, quick help works.
If I then close 13.1, open the project in Xcode 13.2(.1) and attempt to do let x = String( I ALSO get all the string constructor completions. However, if I then clean, the completions no longer work. If I build after cleaning, the completions no longer work.
So, Xcode 13.1 is doing something that the 13.2 series is not doing. As long as that build/Xcode cache (or whatever it is) remains from a 13.1 build, Xcode 13.2 can use it for completion.
«MacOS 12.1»
Post not yet marked as solved
Did any of you see the "Install required components" request / dialog when installing Xcode? I did not.
That modal says: "Xcode requires additional components to support running and debugging. Choose Install to add required components."
That sounds like the problem, no?
When I run:
sudo /usr/bin/xcodebuild -runFirstLaunch -verbose
objc[3862]: Class AMSupportURLConnectionDelegate is implemented in both /usr/lib/libauthinstall.dylib (0x1e79a2b90) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1040e02c8). One of the two will be used. Which one is undefined.
objc[3862]: Class AMSupportURLSession is implemented in both /usr/lib/libauthinstall.dylib (0x1e79a2be0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1040e0318). One of the two will be used. Which one is undefined.
And then nothing happens. Oy.
Fixed for me on iOS 15 Beta 5, out today.
I think this is fixed with iOS 15 Beta 5. I updated, then launched my little hours-tracker app, and all the most recent data loaded up just fine.
I have a small, private, personal app that only uses the Development DB for CloudKit-CoreData.
Using Xcode 13 beta 4:
The Mac version of the app (running in Big Sur 11.5 (Intel)) seems to work fine. I don't see the above error message in the Xcode spew-log.
When I run the iOS version of the app (shared core data context) on an iPhone 12 running iOS 15 beta 4, I get the Account temporarily unavailable error message, as have others.
When I run the app on any of the simulators, I get the same error message.
For whatever that's worth. Compiling with Xcode 13b4 doesn't wreck the app for macOS 11.x.
I'm seeing this as well, on my iPhone 12, and on the iPhone 12, 12 Pro and iPad 11inch simulators.
Post not yet marked as solved
I can confirm this is an issue on MacOS 11 Beta 8 (as well).
Bottom Line: The delegate java commands use JAVAVERSION to route to the correct JDK, not JAVAHOME. So, Set JAVA_VERSION="1.8".
Set JAVA_HOME too, but that's for other tools.
The binaries /usr/bin/java and /usr/bin/javac (etc) are all the same binary which (I'm guessing) launch the correct command based on examining its first parameter and (as of Big Sur) the JAVA_VERSION environment variable.
You can set JAVA_LAUNCHER_VERBOSE=1 to get output its assumptions about paths and versions.
Helper
For anyone reading this who is NOT a super expert on all this JDK stuff, you can add helpers to your shell init: some variation on:
switch_java() {
		export JAVA_HOME=$(/usr/libexec/java_home -v $1)
		export JAVA_VERSION="$1"
		echo "JAVA_HOME: ${JAVA_HOME}"
		echo "JAVA_VERSION: ${JAVA_VERSION}". ####	WORKAROUND 		java -version
}
java8() { switch_java 1.8 }
java11() { switch_java 11 }
NOTE: Setting JAVA_VERSION as well as JAVA_HOME.
$ java8
JAVA_HOME: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home
JAVA_VERSION: 1.8
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (Zulu 8.48.0.53-CA-macosx) (build 1.8.0_265-b11)
OpenJDK 64-Bit Server VM (Zulu 8.48.0.53-CA-macosx) (build 25.265-b11, mixed mode)
$ java11
JAVA_HOME: /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
JAVA_VERSION: 11
openjdk version "11.0.6" 2020-01-14 LTS
OpenJDK Runtime Environment Zulu11.37+17-CA (build 11.0.6+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.37+17-CA (build 11.0.6+10-LTS, mixed mode)
and so on.
