Thank you @DTS Engineer. These are great details! I've follow-up questions to be sure using Xcode Cloud doesn't turn out in being a mistake. If I archive only using Xcode Cloud (with the option to include symbol enabled), can the Xcode Organizer show symbolicated crash logs for app builds that are more than 30 days old (the archive availability window)? For example, a crash for an app version released 6 months ago. Can you elaborate on the "significant debugging capabilities using LLDB that aren't possible without them". What does that mean? Basically, what I want is to be able to see the crash logs in Xcode Organizer, and open them in Xcode Project at the commit I used to archive the app to see what caused the crash and to fix it. I hope it's clear. Thank you, Axel

I just realised it's now working as expected. I noticed my subscription was "In Review" and is now in "Developer Action Needed". Maybe the price cannot be updated while the subscription is "In Review".

Thanks @Engineer for sharing that. My first post was maybe not clear because I‘m looking for errors that can be thrown when we use the AsyncSequence, not the properties of a CLLocationUpdate. do { for try await update in CLLocationUpdate.liveUpdates() { } } catch { // what are possible errors here? }

I don't understand why the NavigationStack is still in the view lifecycle when I tap on the "End" button in the last step and toggle the isFinished state. Here, the NavigationStack should not exist anymore because it's in another branch conditioned by the isFinished flag. And I don't understand why you say the NavigationStack has nothing to display at the end of the onboarding. The path still contains the steps (now that i don't remove them from the path when tapping on "End").

Thanks @darkpaw. I moved the .onAppear { print("onAppear: start") } to the Text("Start"). The result is the same. I also removed the line that removes the steps in the "End" button action, and moved it to the "Restart" button. The result is the same. In this case, the NavigationStack should not pop back to its initial view (the VStack), so I still don't get why this NavigationStack root view appears again.

@DTS Engineer this issue is still in Xcode 16.2 iOS 18.2 beta 1. I don't understand how this major bug is still not fixed by now... Can someone at Apple seriously look into this bug? Also, instead of observing the NSManagedObjectContextDidSave notification (which is part of Core Data + NSManagedObjectContext), we can observe the ModelContext didSave notification. The userInfo dictionary contains the PersistentIdentifiers of inserted/updated/deleted models, so we can only update views using changed models. extension NotificationCenter { var modelContextDidSavePublisher: Publishers.ReceiveOn<NotificationCenter.Publisher, DispatchQueue> { return publisher(for: ModelContext.didSave, object: nil).receive(on: DispatchQueue.main) } } Documentation: https://developer.apple.com/documentation/swiftdata/modelcontext/didsave

Thanks. I did signed out and signed in but tbe issue remained. Here is the feedback #FB15161967. I hope this helps!

I realised I can use Morphology to specify the GrammaticalNumber based on the count value like this private var formattedAttributedString: AttributedString { let formattedCount: String = numberFormatter.string(from: count as NSNumber)! var string: AttributedString = AttributedString(localized: "key_with_string_\(formattedCount)") var morphology = Morphology() let number: Morphology.GrammaticalNumber switch count { case 0: number = .zero case 1: number = .singular case 2: number = .pluralTwo default: number = .plural } morphology.number = number string.inflect = InflectionRule(morphology: morphology) let formattedResult: AttributedString = string.inflected() return formattedResult } This provides the correct string. But I'm not sure this is the correct way to do it because I have to manually specify the morphology.number (I guess .pluralFew and .pluralMany depends on the language). Is there a better solution?

Thanks @App Store Connect Engineer for answering. So it means that if someone downloads an app from a Product Page, leaves the store, then opens the app from the device (home screen for example), the deep link does not work? If this is the case, this is really sad because it makes this feature weak. The OS should keep in cache the original product page used to download the app. I filed a feedback for that: FB13991558

Thanks @DTS Engineer for exploring with me! Before posting my first question, I initially thought I found the value that was used between sections. It seems that spacingBeforeN = min(spacing[n] / 2 + spacing[n-1]/2, 35.33) So this would mean the spacing is capped to a maximum value (the default spacing?). And the documentation is wrong (it's not the minimum spacing that is used). But it does not explain how it works with header and/or footer. As previously shared, when I enable a header and/or footer, the spacing doesn't seem to be used.

I just tested with .listSectionSpacing(.custom(100.0)) but I obtain the same result. Also, the document I shared before is displayed from the other constructor. So it seems there are two ways to specify the listSectionSpacing. Let's see if my feedback is updated soon.

Thanks @DTS Engineer Sydney for answering. The documentation in Xcode 16 clearly states that it's possible to apply different spacing. It's probably new to iOS 18 (and other OSes), but it seems buggy unfortunately. Can you make sure the feedback I mentioned in my previous post (https://feedbackassistant.apple.com/feedback/13699952) will be taken into consideration?

Thanks. Can you share what happens if the products are different? Does it follow the subscription group ranking logic (upgrade starts immediately with a refund, downgrade starts when the active subscription ends, cross grade behaves like a downgrade if duration are different)?

Thanks for your answer. Unfortunately, I'm not sure how to interpret it. Maybe my question was not clear enough and I badly explained what I want. I don't want to only detect the top of the red Text("0") view (i.e. the top of the scrollView), I want to detect the top/bottom of every red Text("...") view, without the spacing being taken into account. So when scrolling down, I want the binding to be updated only when a red background is at the top of the visible scroll view. In the example I provide, the binding is updated to 5 soon after I scroll 4, where 5 is at the middle of the screen. And when scrolling down, I want the binding to be updated only when a red background appears at the top. In my example, the binding is updated to 8 when 9 is still almost at the top of the screen. The thing I find strange is that setting the binding to 7 scroll at the position I want: just over the red Text("7") view. As if this was considered the top of a target View. Why scrolling provides a different result? Why would the spacing or margin be taken into account when scrolling but not when specifying manually a position?

Have you found a solution to this problem? My schema has 2 versions, and I want to migrate with a custom stage migration. My app crashes at launch with the following error: Thread 1: "Duplicate version checksums across stages detected.". I filed feedback #FB13647876 and request a technical support.