We recommend you move away from the Appearance APIs Isn't that a weird suggestion for something that's not marked as deprecated in the API and thus is supposed to work? We're having exactly the same issue in our app, and it is a major showstopper since we can't release updates because of this. The design of the app requires a navigationbar with a custom background, which now is broken. The weird thing is that as long as you don't scroll, the large title sometimes is shown, but it disappears to never be shown again once you start scrolling the view.

Found the issue. The alert JSON format is not accepted: alert: { "loc-key": "recording_started_message", "title-loc-key": "recording_started_title" }; When I put this: "alert": { "title": { "loc-key": "message_title" }, "body": { "loc-key": "message_body" } } it works

Is it normal for log messages to get duplicated? and in the console app: Each log message has a unique number, so I'm pretty sure my app is not logging this 4 times (and it only shows up once in Xcode)

never mind ....

I have exactly the same issue. Logs disappear after a few seconds and I can't scroll back to them.

Same here: The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { DVTErrorCreationDateKey = "2024-04-14 18:03:46 +0000"; NSURL = "file:///Users/jorismans/Downloads/com.sweel.sweel%202024-04-14%2020:03.39.386.xcappdata/AppData/Library/WebKit/WebsiteData/IndexedDB/v0"; } Performing a file system operation failed: Failed to open Library/WebKit/WebsiteData/IndexedDB/v0 for reading, openat(2) returned POSIX error code 62 (parentParam = 64) Domain: com.apple.dt.remoteservices.error Code: 11001 Failed to open Library/WebKit/WebsiteData/IndexedDB/v0 for reading, openat(2) returned POSIX error code 62 (parentParam = 64) Domain: NSPOSIXErrorDomain Code: 62 Failure Reason: Too many levels of symbolic links

Can confirm this is still the case in Xcode 14.3. It's a bloody nightmare. I refuse to work fixed price on Apple Watch projects because it's impossible to guess how much time you lose with this. For a complete project it amounts to several DAYS lost in rebooting phones, watches, Xcode, computer etc. And that's without the nightmare that is your watch app connecting to your iPhone app without issues while the iPhone app in Xcode claims it can't connect to the watch app because it's not installed .... currently on day 2 of trying to get that fixed. It's INSANE.

I agree with @Appeloper. I started applying what has been said in this thread in a project I started from scratch and it makes a lot more sense. It's not perfect (but what is? Especially sometimes issues with threading and the use of @Published vars) but it makes the code a lot more compact, and I'm pretty sure that if I were to go through the code with @Appeloper there would be more gains made because I just arrived in the land of the "converts". When you talk about big projects the use of "rigid" design patterns makes things even worse. I had the "luck" of working once in a VIPER code base. OMG. The amount of files is just staggering. If I see now that a company requires knowledge of Clean architecture / VIP / VIPER to work on their stuff I steer away. What a load of bloatware, hundreds and hundreds of files that don't really serve any purpose except for "adhering to the principles". In a way it becomes so "modular" that nobody understands what's going on anymore and lots of files just serve as "data passages" not doing anything useful. And most of the advantages of using this kind of architecture isn't even exploited (e.g. testability, but the entire codebase contains no tests. Or in theory you can swap out an interface layer for another, but let's be honest, how many projects actually have to do this? Especially if you write Swift, it's not as if you are going to plug a HTML frontend on your app all of the sudden).

Is it ok to pass environmentObjects to a stateObject using .onAppear if we want that state object to help us manage the data to be read/written in the environmentObject? Just so we don't clutter the View struct with lots and lots of code? For instance when creating code to edit a user profile, where a lot of validation is needed? e.g. struct EditPersonalInfoView: View {   @StateObject var userDataValidation = UserDataValidation()      @EnvironmentObject var userInfo: UserInfo   var body: some View {     List {       .... /* a bunch of fields here, validation code inside `userDataValidation` */     }     .onAppear {       userDataValidation.initialize(userInfo: userInfo)     }   } } We can't pass the userInfo object to userDataValidation in the constructor, for obvious reasons.

Simple question: what if the data format in your model does not correspond with how you want to show it on screen? E.g. it's not simply a String in your model that you show in a TextField component, but you need to split it over 3 different TextField components and merge it when you put it back in the model? Unless I am mistaken I haven't seen one word about converting data.

But my app needs to be compatible with WatchOS 8.

I also tried deleting all simulators in ~/Library/Developer/CoreSimulator but that didn't change anything

That was it. Next time please release the build and the symbols simultaneously. Thanks ;)

That's not very convenient, is it? Maybe mention this somewhere in the documentation so people can choose up front so they don't need to do the work twice?