When my Share Extension receives an image from the macOS Photos app on Tahoe, the NSItemProvider passes a URL to an image file in a temporary location. All attempts to read that file fail silently, such as with NSImage(contentsOfFile) I can see that the file does exist in Finder. This code did work in previous macOS versions. It seems like a permissions issue, but startAccessingSecurityScopedResource had no effect. Other platforms work, other apps work, such as shares from Finder, which shares via data instead of a url. I'm really stuck. Has anyone else run into this? // make sure provider has a conforming item if itemProvider.hasItemConformingToTypeIdentifier(imageType) { do { let data = try await itemProvider.loadItem(forTypeIdentifier: imageType, options: nil) // data may be image NativeImage, Data, or a URL to an image file. // figure out which by casting, then attempt to load uiImage if let image = data as? NativeImage { print("found NativeImage") self.images.append(image) } else if let data = data as? Data { print("found Data") if let image = NativeImage(data: data) { self.images.append(image) } } else if let url = data as? URL{ print("found URL") if let image = NativeImage(contentsOfFile: url.path) { print("loaded from URL") self.images.append(image) } } }catch{ print("⛔️ Share Extension Error: \(error.localizedDescription)") } }

Does the CloudKit participant limit of 100 include the owner?

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

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)

When exporting an archive.... NSLocalizedDescription=Communication with Apple failed, NSLocalizedRecoverySuggestion=A non-HTTP 200 response was received (504) for URL https://developerservices2.apple.com/services/QH65B2/listTeams.action?clientId=[redacted]

I enabled Advanced Data Protection for my developer account, and this (understandably) broke access to my private records in CloudKit Console. I disabled Advanced Data Protection but CloudKit Console still cannot connect. In the database popup the "Click here to retry..." option always fails silently. Does anyone know a workaround?

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.