Post not yet marked as solved
I don’t need NavigationStack as my detail. What I meant is that NavigationSplitView behaves as stack on iPhone, yet it doesn’t seem to have the kind of programmatic control for navigation that NavigationStack has. If I had NavigationStack as my content/detail view, it wouldn’t help with controlling navigation on the first level (sidebar).
I have seen the video. Everything about NavigationStack there looks great, but it doesn’t help me. All NavigationSplitView examples there are with a simple list in sidebar. It appears there is some magic going on with binding the List selection to NavigationSplitView state. I can’t figure out how it should behave with non-List or if it’s even possible.
Thank you! I got exactly the same. I was building a simple list-detail interface with NavigationSplitView and wondering why it was not updating the detail contents. Wrapping the column content in ZStack helped.
Just in case others hit it, here’s my code.
struct Thing: Identifiable, Hashable {
let id: UUID
let name: String
}
struct ContentView: View {
let things: [Thing]
@State private var selectedThing: Thing?
var body: some View {
NavigationSplitView {
List(things, selection: $selectedThing) { thing in
NavigationLink(value: thing) {
Text("navlink: \(thing.name)")
}
}
} detail: {
// This is the ZStack wrapper, hopefully won’t be needed when 91311311 is fixed.
ZStack {
if let selectedThing {
Text("There is a thing: \(selectedThing.name)")
} else {
Text("There is no thing.")
}
}
}
}
}
See a related thread. Apparently this is caused by Xcode versions. Apple did something which causes TestFlight builds to crash when built with older Xcodes, but it works when using 13.2 RC. https://developer.apple.com/forums/thread/696197
Check out this other thread which describes the root cause, which is Xcode versions. https://developer.apple.com/forums/thread/696197
I am one of the people affected. When I built an app for Testflight with Xcode 13.1 (App Store version), it crashes on launch when installed from TestFlight, as everyone describes.
The same app built and uploaded with Xcode 13.2 RC (no code changes on my side, only build number bump) installs from Testflight and runs fine on both iOS 14 and 15.
Everything appears fixed for me in Beta 5. I don’t use NSPersistentCloudkitContainer, just staight CloudKit calls. I wish Apple was more diligent in documenting this in release notes though. There’s nothing about this in Xcode or iOS beta release notes.
Seeing the same error on both macOS 12 beta 4 and iOS 15 beta 4 simulator.
<CKError 0x600001a2dbc0: "Account Temporarily Unavailable" (1028/2011); "Account temporarily unavailable due to bad or missing auth token">
Filed FB9435854.
Post not yet marked as solved
Same here. Works on iOS, but not macOS. On iOS simulator, opening a CloudKit Share URL works fine. On macOS, I get the same kind of error. Filed FB9326669.
The behavior of this has improved in recent versions. Now everything works as expected.
Same here as recent posters. Finally fixed in Big Sur 11.4, works again in both production and developer environments.
@Gualtier Malde - thank you for the tips. I am still having trouble registering for notifications in both developer and production environments, and am not receiving the callbacks. My network setup is unrestricted and has all the needed permissions. I have filed FB8731513 to that effect.
It appears that this was fixed in one of the recent Big Sur betas. My sheets now resize to their content correctly.
I should also say that it works as expected and resizes the sheet on Catalina. It does not work as expected and has this error on Big Sur.
Same here on macOS Big Sur beta 4 with Xcode 12 beta 4.
Post not yet marked as solved
I am working on a cross platform app and using the app lifecycle across all platforms would be great. Since I can’t do that, my current plan is to keep using the new lifecycle on macOS, but fall back to iOS 13 way on iOS until there is a way to accept CloudKit shares in the new lifecycle.
Post not yet marked as solved
There is only one CloudKit container per app. (Well, I guess there can be several, but mostly you work with one.) That container, though, contains both private, public, and shared databases. It is possible to mix and match the different database types. I am currently working on an app that uses all three database types. So yes, it’s definitely possible.
