I am also experiencing this issue. It appears that the most likely scenario is that there is an issue preventing some, but not all users from accessing the tag. For users who can access the tag, they can see posts at https://developer.apple.com/forums/tags/universal-app-quick-start . For other users, myself included, this page says "The page you’re looking for can’t be found".
I personally contacted Apple Developer support and they have escalated the issue to another team.
Post
Replies
Boosts
Views
Activity
Update: Now I can access the tag. I think Apple may have fixed the tag access issue last night. Either that, or someone manually updated my account after I contacted support. Or maybe it just becomes visible only after you receive the DTK, which I did last night.
I'm experiencing this too. I have to explicitly call objectWillChange.send() for the change to propagate. For example:
	@AppStorage("lineHeight") var lineHeight = "1.0" {
		willSet { objectWillChange.send() }
	}
I'm not sure if this is a beta bug or the intended behavior.
Thanks @Tom1234 for the clarifications.
If Settings is only available on SwiftUI on AppKit, why does the documentation page - https://developer.apple.com/documentation/swiftui/settings say it is available on both macOS 11.0+ and Mac Catalyst 14.0+? (Genuine question, I can see it being a typo in the docs, or a bug as to why I can't get it to show up in my Catalyst app.)
When you have a UIViewRepresentable, the method func updateUIView(_ uiView: UICollectionView, context: Context) is called every single time a @State/@Binding variable is changed. Currently your logic in that method is to call uiView.reloadData() every time. You could update the logic to only reload the data once, or only load it if certain conditions are met. For example:
struct CustomCollectionView: UIViewRepresentable {
		@Binding var lastSelectedIndex : Int
		private var didLoadData = false
		// ...
		func updateUIView(_ uiView: UICollectionView, context: Context) {
				if didLoadData { return }
				uiView.reloadData()
				didLoadData = true
		}
		// ...
}
I had this problem too. I went to https://developer.apple.com/download/ to re-download and re-run the macOSDeveloperBetaAccessUtility.pkg. Not sure why this fixed it but it did.
This happens automatically when you use NSPersistentCloudKitContainer. See https://developer.apple.com/videos/play/wwdc2019/202/?time=1291 at time 21:30.
Update: It appears that the Settings documentation page - https://developer.apple.com/documentation/swiftui/settings has been updated to no longer show compatibility with Mac Catalyst 14.0+. I guess it was a typo.
Hi MDeuschl,
Logically, your program should run just fine. I suspect that you are right, that it's a bug with SwiftUI itself. I have the same Fatal error: file SwiftUI, line 0 error for my code. In my case, I conditionally render a view based on whether the variable holding the view is nil. A different situation than yours, but the same error, and for no clear reason. I wish I had more information on how to avoid it. All I know for now is that you can submit a Feedback Assistant - https://feedbackassistant.apple.com/ with a sample Xcode project that demonstrates the crash. I'll probably do this when I have more time.
Here's my code. I display my view in another view that is displayed in a modal sheet. The whole modal setup works fine in a SwiftUI Preview, but always crashes on simulator and device.
swift
import SwiftUI
/// A view with an action button that should be presented modally.
struct ActionModalView: View {
let iconImage: Image?
let title: String
let message: String
let buttonText: String
let buttonAction: () - Void
var body: some View {
VStack(spacing: Theme.Spacing.extraExtraLarge) {
Spacer(minLength: Theme.Spacing.extraExtraLarge)
// This causes a crash
if let iconImage = iconImage {
iconImage
.resizable()
.renderingMode(.template)
.foregroundColor(.primaryBase)
.aspectRatio(contentMode: .fit)
.frame(width: 80)
}
Text(title)
.font(Theme.Text.largeTitle)
FadingScrollView {
Text(message)
.font(Theme.Text.title3)
}
actionButton
}
.padding(.horizontal, Theme.Spacing.extraExtraLarge)
.background(Color.adaptiveSecondaryBackground)
}
var actionButton: some View {
Button(action: buttonAction) {
HStack {
Spacer()
Text(buttonText)
.font(Theme.Text.title3)
.foregroundColor(.textXlight)
Spacer()
}
.padding()
.background(Color.primaryBase)
.cornerRadius(10)
}
}
}
struct ActionModalView_Previews: PreviewProvider {
static var previews: some View {
LightAndDarkPreviewGroup(layoutMode: .largeAndSmallDevices) {
Group {
Text("Press the play button to view the ActionModalView with a large amount of text.")
.sheet(isPresented: .constant(true)) {
ActionModalView(
iconImage: Image(uiImage: Asset.runningshoe.image),
title: "This is the title",
message: PreviewFixtures.Text.threeParagraphs,
buttonText: "Action Button",
buttonAction: {}
)
}
Text("Press the play button to view the ActionModalView with a small amount of text.")
.sheet(isPresented: .constant(true)) {
ActionModalView(
iconImage: Image(uiImage: Asset.runningshoe.image),
title: "This is the title",
message: PreviewFixtures.Text.oneParagraph,
buttonText: "Action Button",
buttonAction: {}
)
}
}
}
}
}
Hi again MDeuschl,
I was able to fix the crash in my app. It turns out that in my code that uses my ActionModalView in my previous post, SwiftUI accesses a computed variable, which is generated using the following code:
extension String {
var htmlToString: String {
return htmlToAttributedString.string
.trimmingCharacters(in: .whitespacesAndNewlines)
}
private var htmlToAttributedString: NSAttributedString {
guard let data = data(using: .utf8) else { return NSAttributedString() }
do {
return try NSAttributedString(
data: data,
options: [
.documentType: NSAttributedString.DocumentType.html,
.characterEncoding: String.Encoding.utf8.rawValue
],
documentAttributes: nil)
} catch {
return NSAttributedString()
}
}
}
It turns out that there's some sort of bug where creating an NSAttributedString with NSAttributedString.DocumentType.html cannot be done on a SwiftUI thread. On iOS 13, it results in a crash, while on iOS 14 it results in a slowdown, and a crash in another part of SwiftUI code. Removing this fixed my issue with my usage of if let iconImage = iconImage in SwiftUI. So it turns out that my usage of if let iconImage = iconImage wasn't really a problem in the first place, and that SwiftUI was doing a really poor job of helping me pinpoint the issue with NSAttributedString. I suspect something similar might be happening in your case. Hopefully SwiftUI improves this year.