Post

Replies

Boosts

Views

Activity

scrollTargetLayout + @FetchRequest causes items to constantly re-initialize
On a ScrollView+LazyVStack, the addition of .scrollTargetLayout causes many list items to be initialized, instead of the ordinary economical behavior of LazyVStack, where only the necessary items and views are initialized. Even worse, as the stack is scrolled down, all list items are reinitialized for every small scroll. Without, .scrollTargetLayout, everything works fine. I've tried every variation of locating modifiers, and different ways of identifying the list items, with no success. Any ideas? Thanks. @FetchRequest( sortDescriptors: [NSSortDescriptor(keyPath: \Post.created, ascending: true)], animation: .default) private var posts: FetchedResults<Post> var body: some View { ZStack{ ScrollView{ LazyVStack(spacing:0) { ForEach(posts, id: \.self) { post in PostView(post: post) } .onDelete(perform: deletePosts) }.scrollTargetLayout() // <---- causes multiple Posts re-instantiations for any small scroll, very slow } .scrollPosition(id: $scrolledID) .scrollTargetBehavior(.paging)
1
0
73
3d
SwiftData on iOS 18 extreme memory use
Hi, I've run into two problems using SwiftData in iOS 18 that are total show-stoppers for my app, causing it to run out of memory and be killed by the system. The same app runs fine on iOS 17. The two problems are inter-related in a way I can't exactly diagnose, but are easy to reproduce. Problem #1: Calling .count on the array that represents a relationship or Query causes the whole array of objects to be loaded into memory. Problem #2: When a @Model object is loaded, properties that are declared with .externalStorage are loaded unnecessarily, and use tons of memory. It's possible that #1 is normal behavior, exacerbated by #2. I've written a test app that demonstrates the extreme difference in memory usage between the OS Versions. It uses a typical navigation pattern, with content counts on the left-side view. Each item has one thumbnail and one large image in .externalStorge. GitHub Source When populated with 80 items, each containing one thumbnail and one large image in .externalStorge, the app launches in 17.5 using 29mb of memory. On iOS 18, in the same conditions, 592 mb. When the first folder is selected, causing a list of thumbnails to load, iOS 17 uses just 86mb. iOS 18 uses 599mb, implying that all image data has already been loaded. So I'm asking for help from Apple or the Community in finding a workaround. I've been advised that finding a workaround may be necessary, as this may not be addressed in 18.0. Thanks in advance for any insight. Radars: FB14323833, FB14323934 (See attached images, or try it yourself) (You may notice in the 18.0 screenshots that the item counts don't add up right. That's yet another 18.0-SwiftData anomaly regarding relationships that I haven't tackled yet, but is also demonstrated by the sample app.)
12
5
2.2k
Aug ’24
Xcode Cloud builds failing randomly citing internal Apple network failure
Since April 30 (yesterday as of this writing) Xcode Cloud builds are failing randomly, usually citing an internal Apple network failure. NSLocalizedDescription=Communication with Apple failed, NSLocalizedRecoverySuggestion=A non-HTTP 200 response was received (502) for URL https://developerservices2.apple.com/services/QH65B2/listTeams.action?clientId=XABBG36SBA Because of this network failure, the build cannot fetch my app ID NSLocalizedDescription=Capabilities for bundle ID "Twine" could not be fetched. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator., IDEDistributionIssueSeverity=3 This is a multi platform app, iOS, macOS, and visionOS. Usually one or two platforms will succeed, with one or two failing. From build to build, with no source changes, the successful platform randomly changes. But I never get a complete build.
2
0
784
May ’24