Post not yet marked as solved
I've just run into the same problem. On stable Xcode and iOS 15.3.1.
Any luck?
Post not yet marked as solved
FWIW I'm experiencing this just using the offset() in SwiftUI, no scroll views or gestures involved. On the iPhone 13 pro the updates run horribly (fps seems to degrade over time?), yet iPhone X and other non 120hz phones are updating at rock solid 60fps.
Post not yet marked as solved
Found a workaround that works for me on both OSX and iOS. I suspected the bug was happening from scrollTo() incorrectly calculating the offset of the particular view in the reference frame of the scrollview, as I was getting different scroll positions depending on how far down the list the scrollTo view was.
Previously the scrollview content was composed of different container views, with subviews inside those. The workaround was to flatten those container views so the requested view IDs to scrollTo are all flat at the top level of the scroll view content.
ScrollView setup:
ScrollViewReader { proxy in
GeometryReader { geometry in
ScrollView(showsIndicators: false) {
VStack(alignment: .leading, spacing: 17) {
ForEach(levelSelect.worlds) { world in
flatRowItems(world: world)
}
}
}
.onAppear {
if let id = levelSelect.selectedLevelID {
proxy.scrollTo(id, anchor: .center)
}
}
.onChange(of: levelSelect.selectedLevelID) { selectedLevelID in
guard let selectedLevelID = selectedLevelID else { return }
if !levelSelect.isInitialSelection {
withAnimation {
proxy.scrollTo(selectedLevelID, anchor: nil)
}
} else {
levelSelect.isInitialSelection = false
proxy.scrollTo(selectedLevelID, anchor: .center)
}
}
}
}
Flattened scrollview content using @ViewBuilder:
@ViewBuilder func flatRowItems(world: World) -> some View {
Group { // previously had a WorldRow which contained the following content as child views
if world.locked {
LockedWorldRow(world: world)
} else {
UnlockedWorldRow(world: world) // previously UnlockedWorldRow contained LevelRows inside
ForEach(world.levels) { level in
LevelRow(levelItem: level)
.id(level.id)
}
}
}
}
Post not yet marked as solved
Adding that I'm also experiencing this problem on MacOS Monterey 12.0.1 as well as iOS 15
Post not yet marked as solved
Did you manage to get this to work? The entity immediatly jumps to the final transform for me, no matter how long the duration.
Post not yet marked as solved
For me turning off SWIFT_DISABLE_SAFETY_CHECKS for release builds allowed release builds to complete. (Kind of annoying because I got 100x speedup over some long heavy data processing 😀 )I'm guessing these are all from the same family of bug?Filed radar: 50286478
TIL that these forums don't email you if someone replies to your message (probably explains why no-one came back for the "me toos")! I only happened to look so I could send a link to App Store Connect Tech Support 🙂So here's the update:After getting the IAP rejected for not submitting with the binary, I immediately resubmitted with no changes (had to re-edit the IAP descriptions to allow resubmission), and put the explanation of what was going on in the review notes. On Saturday the IAP entered "In Review". 4.5 days later it was still "In Review".Luckily I had sent a message to the Review Appeal Board almost a week ago as it really screwed up this version's launch, and this morning they picked it up, tried the IAP and saw that it worked, then put the IAP in to Approved status.I've also started talking with App Store Connect tech support, so hopefully we can end up with either a) app store connect allowing you to submit IAPs with binaries b) IAP review workflow change to take into account this scenario or c) developer documentation update to say "please get your IAPs through review *before* submitting a binary that supports the new IAPs, because they seem to take so much longer.
I'm in the same boat this week - no way to attach the IAP to a binary as the app previously had an IAP, and the IAP getting rejected:> we have returned your in-app purchase products to you as the required binary was not submitted. When you are ready to submit the binary, please resubmit the in-app purchase products with the binary.So, I just click save on the IAP again and it went into "waiting for review" status again - no idea if it will ever come out.I then tried submitting a new binary with explanantion of how there is no way to attach the IAP to the binary, and screenshot of the form with no "attach IAP" section where taht scection normally is, and the review notes were ignored (from experience I don't know if anyone ever reads them), and the new binary approved for sale. So sadly I'm stuck with the app in the wild with broken IAP.Trying to contact the app review team and app review appeal board has led to nothing so far.Did the other folk in here just... wait it out?