In their sample project Sharing Core Data objects between iCloud users, Apple now covers this situation. They added some code to handle the soft deletion of objects that are duplicates. To do so, they added a deduplicatedDate property on the Tag entity, then only remove the objects after some time. See the file PersistenceController+Deduplicate.swift. They also have to filter these objects marked as deduplicated from the UI (like in the TaggingView.swift).

I tried it on Xcode Version 15.0 beta 8 (15A5229m) but it does not seem to be working. My text is not animated in the app (not a widget). Do you have any idea why?

Here is a solution that works in iOS 17: import SwiftUI struct TimerTransitionView: View { var body: some View { Text(Date(timeIntervalSince1970: 1696563619), style: .timer) .contentTransition(.numericText()) .transaction { t in t.animation = .default } } } #Preview { TimerTransitionView() } Thanks LiYanan04818 for the suggestion!

I'm also really interested in this. In my app, I want to make sure locations I receive are coming from a GPS and not from Wi-Fi/Cell towers. I used to specify a desiredAccuracy to kCLLocationAccuracyBest or kCLLocationAccuracyNearestTenMeters. How can I do that again with this new API? Is that even possible? Thanks!

I just tested with other time zones and the results are different... For some time zones, the result is correct, for others, not. I used the following code to print the result for all time zones. Optional(1970-08-31 23:00:00 +0000) for Europe/London Optional(1995-08-31 23:00:00 +0000) for Europe/Paris Optional(2002-08-31 22:00:00 +0000) for Europe/Vilnius Optional(2023-09-01 07:00:00 +0000) for America/Los_Angeles for zone in TimeZone.knownTimeZoneIdentifiers { var calendar: Calendar = Calendar(identifier: .gregorian) calendar.timeZone = TimeZone(identifier: zone) ?? .autoupdatingCurrent let matchingDateComponents: DateComponents = DateComponents(month: 9) let date: Date? = calendar.nextDate( after: Date.now, matching: matchingDateComponents, matchingPolicy: .nextTime, direction: .backward ) print(zone, date) }

I tested with other date components to see if the dates provided by these methods are correct when searching backward. I tested using a .nextTime and .strict matchingPolicy. DateComponents(month: 1) Correct years, wrong days. I mainly get dates around January the 5th. But the years seem to be correct. In this case, only the America/Los_Angeles date seems to be correct. Even GMT is wrong. 2023-01-05 00:00:00 +0000 for Europe/London 2023-01-04 23:00:00 +0000 for Europe/Paris 2023-01-04 22:00:00 +0000 for Europe/Vilnius 2023-01-01 08:00:00 +0000 for America/Los_Angeles 2023-01-05 00:00:00 +0000 for GMT DateComponents(month: 2) Correct years, correct days DateComponents(month: 3) Correct years, wrong days DateComponents(month: 4) Correct years, correct days DateComponents(month: 5) Correct years, wrong days. I mainly get dates around May the 3rd. 2023-05-02 23:00:00 +0000 for Europe/London 2023-05-02 22:00:00 +0000 for Europe/Paris 2023-05-02 21:00:00 +0000 for Europe/Vilnius 2023-05-03 07:00:00 +0000 for America/Los_Angeles 2023-05-03 00:00:00 +0000 for GMT DateComponents(month: 6) Correct years, correct days DateComponents(month: 7) Correct years, wrong days DateComponents(month: 8) Correct years, wrong days DateComponents(month: 9) Wrong years, correct days DateComponents(month: 10) Correct years, wrong days DateComponents(month: 11) Correct years, correct days DateComponents(month: 12) Wrong years, wrong days Expected Result: first day of December of this year (when after is December the 5th for example). Actual Result: It provides the last day of December for the previous year. If I additionally specify a day in the date components like DateComponents(month: 1, day: 1), I get the correct results for all time zones, except for September (still wrong years). So two issues: If only a month is specified, the backward results are often wrong: either the year (like in September or December), or the days (if I only provide the month, I expect the function to give me the start of the month that matches this month date component). If the specified month is September, the year and day in provided date are wrong for a lot of time zones.

Here is the code to reproduce the issue: import SwiftUI @main struct FB_SwiftUI_NavigationSplitView_Delete_SelectApp: App { var body: some Scene { WindowGroup { ContentView() } } } enum SelectionString: Hashable { case all case item(String) } struct ContentView: View { @State private var selectionString: SelectionString? @State private var strings: [String] = [] var body: some View { NavigationSplitView { List(selection: $selectionString) { Section { NavigationLink(value: SelectionString.all) { Text("All") } } Section { ForEach(strings.sorted(), id: \.self) { string in NavigationLink(value: SelectionString.item(string)) { Text(string) } } } } .toolbar { ToolbarItem { Button("Add") { strings.append(UUID().uuidString) } } } } detail: { if let selectionString { switch selectionString { case .all: Text("All") case .item(let string): Button(role: .destructive) { if let index = strings.firstIndex(of: string) { strings.remove(at: index) self.selectionString = nil } } label: { Text("Delete") } } } else { Text("Select an item") } } } }

I realized the issue is actually caused by the use of Section. If I keep my same code I shared but remove the sections in the sidebar List, I don’t have the issue anymore. If I keep at least one section, it crashes. List(selection: $selectionString) { NavigationLink(value: SelectionString.all) { Text("All") } ForEach(strings.sorted(), id: \.self) { string in NavigationLink(value: SelectionString.item(string)) { Text(string) } } }

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.

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?

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 @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?

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 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.

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