Post

Replies

Boosts

Views

Activity

Large memory consumption when running Core ML model on A13 GPU
We recently had to change our MLModel's architecture to include custom layers, which means the model can't run on the Neural Engine anymore. After the change, we observed a lot of crashes being reported on A13 devices. It turns out that the memory consumption when running the prediction with the new model on the GPU is much higher than before, when it was running on the Neural Engine. Before, the peak memory load was ~350 MB, now it spikes over 2 GB, leading to a crash most of the time. This only seems to happen on the A13. When forcing the model to only run on the CPU, the memory consumption is still high, but the same as running the old model on the CPU (~750 MB peak). All tested on iOS 16.1.2. We profiled the process in Instruments and found that there are a lot of memory buffers allocated by Core ML that are not freed after the prediction. The allocation stack trace for those buffers is the following: We ran the same model on a different device and found the same buffers in Instruments, but there they are only 4 KB in size. It seems, Core ML is somehow massively over-allocating memory when run on the A13 GPU. So far we limit the model to only run on CPU for those devices, but this is far from ideal. Is there any other model setting or workaround that we can use to avoid this issue?
3
2
2.2k
3d
Core ML memory usage is dramatically higher with an Xcode 27 build on iOS 27
I’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27. The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs. On the same iPad running iPadOS 27: Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint. Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used. I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime. The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak. I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change. If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit. A few additional observations: The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly. The first uncached run can survive model preparation because specialization spaces the loads farther apart. Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak. os_proc_available_memory() decreases in line with the newly reported footprint. With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes. Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27? In particular, I’m trying to understand: Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory? Is the new accounting used for the application’s jetsam/per-process memory limit? Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device. Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly? Are there recommended APIs or Core ML loading strategies for controlling this residency? Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.
0
0
165
1w
Is `.appEntityIdentifier` + `Transferable` the intended way to let Siri send an on-screen image to another app? (iOS 27)
I'm trying to make a third-party app's on-screen image available to Siri / Apple Intelligence so the user can say something like "send this to " and have the image handed off. And I'd like to confirm whether I'm using the intended mechanism or whether this particular case just isn't supported yet. What I'm trying to do My app shows a single image (it owns no photo library, the image is an in-app render). I want the user to be able to reference it as "this" and have Siri move it to another app. What I implemented (following Making onscreen content available to Siri and Apple Intelligence and WWDC26 240/343) A plain AppEntity with a stable id, conforming to Transferable, annotated on the image view with the iOS 27 .appEntityIdentifier(_:) modifier: struct OnScreenImageEntity: AppEntity, Transferable { static let typeDisplayRepresentation = TypeDisplayRepresentation(name: "On-Screen Image") static let defaultQuery = Query() let id: String static var transferRepresentation: some TransferRepresentation { DataRepresentation(exportedContentType: .plainText) { … } // distinctive text DataRepresentation(exportedContentType: .png) { … } // the image } struct Query: EntityQuery { func entities(for ids: [String]) async throws -> [OnScreenImageEntity] { logger.notice("entities(for:) CALLED \(ids)") // <- never fires return ids.filter { store.isCurrent($0) }.map(OnScreenImageEntity.init) } } } // on the view: Image(uiImage: image) .appEntityIdentifier(EntityIdentifier(for: OnScreenImageEntity.self, identifier: id)) What I observe (iOS 27 Beta 3, device) "Describe this image" / "Create a note for this" appear to use an automatic screenshot — the responses reference my app's UI chrome, and EntityQuery.entities(for:) is never called, so my entity's Transferable is not involved at all. "Send this to " doesn't attach the image; Siri says something like "I can't attach the image directly from your screen," which again sounds like a screen grab. entities(for:) is not called. The only flow that resolves my entity is the ChatGPT hand-off: asking Siri about the on-screen content calls entities(for:) (several times). But even there it stalls — Siri responds "could not clarify what you mean by 'about this'… document, image, or topic?", and no Transferable representation is ever read (my export closures never run). So the entity resolves, yet the content is never actually transferred. The older NSUserActivity.appEntityIdentifier route was never consumed at all; only the iOS 27 .appEntityIdentifier(_:) view modifier produced any resolution, and only in the ChatGPT flow above. I also understand from WWDC26 240/343 that the cross-app content move is built on IntentValueRepresentation (entity ↔ a system value type like IntentPerson), which the recipient imports via IntentValueQuery / IntentValueRepresentation(importing:). Since there doesn't seem to be a system value type for an arbitrary image (and IntentFile isn't one), I'm not sure an image entity can participate in that transfer at all. My questions Is .appEntityIdentifier(_:) the intended way to expose a single on-screen item in iOS 27? It only resolves my entity in the ChatGPT hand-off, and even then the Transferable is never read — under what conditions is the resolved entity's Transferable actually consumed? Are on-screen content requests ("describe this", "create a note for this") ever meant to use an app-provided AppEntity + Transferable, or are they always served by screen capture? (For me they never call entities(for:).) Is there a supported path for Siri to send an image from a third-party app's on-screen content to another app? If the transfer requires IntentValueRepresentation and there's no image system value, is a Transferable image representation ever consumed for this — and if so, how is it triggered? If this is simply not supported for image content yet, that's useful to know too, I just want to make sure I'm not missing a required piece (a schema conformance, an eligibility flag, a different annotation API, etc.). I have a minimal sample project that reproduces this (single annotated image, no photo library, logs to a subsystem so you can see entities(for:) never being called) and filed it as Feedback FB23813341 — happy to share details. Thanks!
4
3
306
1w
Receiving an on‑screen image from another app via App Intents / Siri (app has no photo library)
I have a photo editing app that owns no photo library. I want a user viewing an image in another app (e.g. Photos) to say "filter this image in MyApp" and have Siri hand that on‑screen image to my intent. Targeting iOS 27. What I've tried, and the result in each case: • App Shortcut + @Parameter var image: IntentFile — Siri resolves my other parameters (a filter AppEnum) by voice, but never binds the image; the run fails. • @AppIntent(schema: .photos.setFilter) with a .photos.asset entity — never routes from Photos. • @AppIntent(schema: .system.open): OpenIntent with a custom AppEntity target — "Open this image in MyApp" just launches the app by name; perform() is never called, and the entity query never runs. My understanding from WWDC26 "Build intelligent Siri experiences with App Schemas" (session 240) and "Discover new capabilities in the App Intents framework" (session 345): • Cross‑app content transfer (Transferable + IntentValueRepresentation) seems limited to system value types (IntentPerson, PlaceDescriptor); IntentFile is not a _SystemIntentValue, so an image can't ride that rail. • Onscreen awareness (NSUserActivity.appEntityIdentifier, View Annotations) appears to expose only the foreground app's own content — which here is Photos, not me. Question: Is there a supported way for a third‑party app to receive another app's on‑screen image (vs. a contact/place) through Siri/App Intents today? If so, which API carries the pixels — an IntentFile parameter, @UnionValue, IntentValueQuery, something else — and what must the source app do to make it available? Or is asking "do X to this image in <third‑party app>" simply not supported yet outside Shortcuts?
2
1
489
4w
Linker trying to link Metal toolchain for every object file on Catalyst
When building our project for Mac Catalyst with Xcode 26.2, we get this warning almost a hundred times, once for every object file: directory not found for option '-L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' Somehow, every Link <FileName>.o build step got the following parameter, regardless if the target contained Metal files or not: -L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst The toolchain is mounted at this point, but the directory usr/lib/swift/maccatalyst doesn't exist. When building the project for iOS, the option doesn't exist and the warning is not shown. We already check the build settings, but we couldn't find a reason why the linker is trying to link against the toolchain here. Even for targets that do contain Metal files, we get the following linker warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Is this a known issue? Is there a way to get rid of these warnings?
2
3
1.3k
Jun ’26
Managed Asset Pack not found by TestFlight reviewer
We have an on-demand asset pack that we download at the start of the app. We first present the user with the download size and the option to download the asset. The iOS version of our app went through review just fine, but the macOS version (Catalyst) is stuck. The reviewer reports an error that indicates that even the lookup of the asset pack (assetPack(withID:)) doesn't work. On all our test devices we don't have that issue. It seems the reviewer is running the app in an environment that is unable to load the asset pack information from TestFlight. We don't know what to do here. Any help would be appreciated!
4
5
348
Jun ’26
Managed Background Assets on iPadOS 26.3: metadata resolves, download never starts
Has anyone seen Managed Background Assets get stuck before any download progress is reported on iPadOS 26.3 / TestFlight? We are using Apple-hosted managed asset packs for a large on-demand model download. The app can resolve the asset pack metadata: we can show the asset pack’s download size in the UI, so AssetPackManager.assetPack(withID:) appears to work. But when we call ensureLocalAvailability(of:), the UI stays at 0% indefinitely. We also do not receive any useful terminal state from statusUpdates(forAssetPackWithID:): no .began, .downloading, .failed, or .finished. The app remains responsive. The issue also appears persistent on the affected device/account. Reinstalling the app does not help, reinstalling TestFlight does not help, logging out and back in does not help, and restarting the device does not help. After each attempt, the app can still resolve the asset pack metadata/download size, but the actual download remains stuck before any progress or failure status is delivered. The suspicious part of the device log is that the managed helper starts normally, fetches/installs the manifest from TestFlight, but repeatedly fails to create its helper directory inside the app container: OurApp Initializing the asset-pack manager… OurApp Creating a proxy object for the helper service… OurApp activating connection ... name=com.apple.backgroundassets.managed.helper.service kernel Sandbox: no system container path found for ID "com.apple.backgroundassets.managed.helper.service" Managed Background Assets Helper Service Starting the Managed Background Assets Helper Service… Managed Background Assets Helper Service Configuring the directory suffix… Managed Background Assets Helper Service The directory suffix was successfully configured. Managed Background Assets Helper Service The extension token "<...>" was consumed. kernel Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] After that, manifest fetching still seems to work: OurApp The asset-pack manager has been initialized. OurApp The system download-manager delegate has been assigned to the download manager. OurApp The app was installed for internal beta testing; checking for updates automatically… OurApp Refreshing the manifest… Managed Background Assets Helper Service The app with the bundle ID "..." is configured to use Apple hosting. Managed Background Assets Helper Service Asking the TestFlight extension via the App Store Daemon for the URL request... Managed Background Assets Helper Service Fetching the download manifest ... from TestFlight… Managed Background Assets Helper Service Installing a manifest at ".../Library/Application Support/.../Manifest.json"... But during/after manifest install, the same mkdir failure appears again: Managed Background Assets Helper Service Installing a manifest at ".../Manifest.json"... Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] kernel duplicate reports for Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service So the behavior seems to be: TestFlight/internal beta install Apple-hosted managed asset pack Manifest fetch succeeds Asset pack metadata resolves, including download size Actual local availability request never starts reporting progress No visible Background Assets failure reaches the app Logs show repeated sandbox file-write-create denial for the Managed Background Assets Helper trying to create /tmp/com.apple.backgroundassets.managed.helper.service inside the app container Reinstalling the app/TestFlight, logging out and back in, and restarting the device do not clear the stuck state On devices with 26.4, the issue doesn’t seem to exist Has anyone else seen this on iOS/iPadOS/macOS versions before 26.4? Is this a known issue in the Managed Background Assets helper/runtime? I noticed 26.4 added more local status APIs for asset packs, so I’m wondering whether this area changed in 26.4. Any hints on whether the sandbox denial is expected/noisy, or whether it could explain ensureLocalAvailability(of:) never progressing, would be appreciated.
1
3
326
Apr ’26
Sharing a JPEG via Action or Share Extension fails in Photos on macOS
We have a Share Extension that fails in Photos on macOS when trying to share a JPEG image for the following reason: From the NSItemProvider we get from the NSExtensionItem.attachments, we try to load the image using loadFileRepresentation(forTypeIdentifier: “public.image”, completionHandler: …). This fails for .jpeg images in the library. There seems to be a mismatch in expected and actual file extension internally. Here is the log: Error copying file type public.image. Error: Error Domain=NSItemProviderErrorDomain Code=-1000 "Cannot load representation of type public.jpeg" UserInfo={NSLocalizedDescription=Cannot load representation of type public.jpeg, NSUnderlyingError=0x1527c1a80 {Error Domain=NSItemProviderErrorDomain Code=-1 "Cannot copy file at URL file:///Users/frank/Library/Containers/com.apple.Photos/Data/tmp/TemporaryItems/ShareKit-Exports/7CCFA760-AAC9-42B0-812D-68F051ED1543/F912E593-2BE5-4E70-86AB-7657A40657E5/IMG_3517.jpg." UserInfo={NSLocalizedDescription=Cannot copy file at URL file:///Users/frank/Library/Containers/com.apple.Photos/Data/tmp/TemporaryItems/ShareKit-Exports/7CCFA760-AAC9-42B0-812D-68F051ED1543/F912E593-2BE5-4E70-86AB-7657A40657E5/IMG_3517.jpg., NSUnderlyingError=0x152789670 {Error Domain=NSItemProviderErrorDomain Code=-1 "Cannot create a temporary file. Error: Undefined error: 0" UserInfo={NSLocalizedDescription=Cannot create a temporary file. Error: Undefined error: 0}}}}}``` In the specified folder, there is an image, however, it’s named IMG_3517.jpeg, not IMG_3517.jpg. This seems to be a bug in Photo’s item provider implementation. If we use loadObject(ofClass: URL.self, completionHandler: …) instead, we get the correct .jpeg URL in the completion handler.
3
1
1.8k
Nov ’25
PHPicker fails to load RAW images
We observed that the PHPicker is unable to load RAW images captured on an iPhone in some scenarios. And it is also somehow related to iCloud. Here is the setup: The PHPickerViewController is configured with preferredAssetRepresentationMode = .current to avoid transcoding. The image is loaded from the item provider like this: if itemProvider.hasItemConformingToTypeIdentifier(kUTTypeImage) { itemProvider.loadFileRepresentation(forTypeIdentifier: kUTTypeImage) { url, error in // work } } This usually works, also for RAW images. However, when trying to load a RAW image that has just been captured with the iPhone, the loading fails with the following errors on the console: [claims] 43A5D3B2-84CD-488D-B9E4-19F9ED5F39EB grantAccessClaim reply is an error: Error Domain=NSCocoaErrorDomain Code=4097 "Couldn’t communicate with a helper application." UserInfo={NSUnderlyingError=0x2804a8e70 {Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 19420 on anonymousListener or serviceListener" UserInfo={NSDebugDescription=connection from pid 19420 on anonymousListener or serviceListener}}} Error copying file type public.image. Error: Error Domain=NSItemProviderErrorDomain Code=-1000 "Cannot load representation of type public.image" UserInfo={NSLocalizedDescription=Cannot load representation of type public.image, NSUnderlyingError=0x280480540 {Error Domain=NSCocoaErrorDomain Code=4097 "Couldn’t communicate with a helper application." UserInfo={NSUnderlyingError=0x2804a8e70 {Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 19420 on anonymousListener or serviceListener" UserInfo={NSDebugDescription=connection from pid 19420 on anonymousListener or serviceListener}}}}} We observed that on some devices, loading the image will actually work after a short time (~30 sec), but on others it will always fail. We think it is related to iCloud Photos: On the device that has iCloud Photos sync enabled, the picker is able to load the image right after it was synced to the cloud. On devices that don't sync the image, loading always fails. It seems that the sync process is doing some processing (?) of the image that will later enable the picker to load it successfully, but that's just guessing. Additional observations: This seems to only occur for images that were taken with the stock Camera app. When using Halide to capture RAW (either ProRAW or RAW), the Picker is able to load the image. When trying to load the image as kUTTypeRawImage instead of kUTTypeImage, it also fails. The picker also can't load RAW images that were AirDroped from another device, unless it synced to iCloud first. This is reproducable using the Selecting Photos and Videos in iOS sample code project. We observed this happening in other apps that use the PHPicker, not just ours. Is this a bug, or is there something that we are missing?
7
1
3.2k
Sep ’25
Images with unusual color spaces not correctly loaded by Core Image
Some users reported that their images are not loading correctly in our app. After a lot of debugging we identified the following: This only happens when the app is build for Mac Catalyst. Not on iOS, iPadOS, or “real” macOS (AppKit). The images in question have unusual color spaces. We observed the issue for uRGB and eciRGB v2. Those images are rendered correctly in Photos and Preview on all platforms. When displaying the image inside of a UIImageView or in a SwiftUI Image, they render correctly. The issue only occurs when loading the image via Core Image. When comparing the different Core Image render graphs between AppKit (working) and Catalyst (faulty) builds, they look identical—except for the result. Mac (AppKit): Catalyst: Something seems to be off when Core Image tries to load an image with foreign color space in Catalyst. We identified a workaround: By using a CGImageDestination to transcode the image using the kCGImageDestinationOptimizeColorForSharing option, Image I/O will convert the image to sRGB (or similar) and Core Image is able to load the image correctly. However, one potentially loses fidelity this way. Or might there be a better workaround?
2
3
421
Aug ’25
UI freeze during layouting
One of our users reported a very strange bug where our app freezes and eventually crashes on some screen transitions. From different crash logs we could determine that the app freezes up when we call view.layoutIfNeeded() for animating constraint changes. It then gets killed by the watchdog 10 seconds later: Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<bundleID(2A01F261-3554-44C0-B5A9-EBEB446484AD)>:6921 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 24.320 (user 18.860, system 5.460), 29% CPU", "Elapsed application CPU time (seconds): 10.630, 12% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> The crash stack trace looks slightly different, depending on the UI transition that is happening. Here are the two we observed so far. Both are triggered by the layoutIfNeeded() call. Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 CoreAutoLayout 0x1b09f90e4 -[NSISEngine valueForEngineVar:] + 8 1 UIKitCore 0x18f919478 -[_UIViewLayoutEngineRelativeAlignmentRectOriginCache origin] + 372 2 UIKitCore 0x18f918f18 -[UIView _nsis_center:bounds:inEngine:forLayoutGuide:] + 1372 3 UIKitCore 0x18f908e9c -[UIView(Geometry) _applyISEngineLayoutValuesToBoundsOnly:] + 248 4 UIKitCore 0x18f9089e0 -[UIView(Geometry) _resizeWithOldSuperviewSize:] + 148 5 CoreFoundation 0x18d0cd6a4 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 6 CoreFoundation 0x18d0cd584 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 432 7 UIKitCore 0x18f8e62b0 -[UIView(Geometry) resizeSubviewsWithOldSize:] + 128 8 UIKitCore 0x18f977194 -[UIView(AdditionalLayoutSupport) _is_layout] + 124 9 UIKitCore 0x18f976c2c -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 800 10 UIKitCore 0x18f903944 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2728 11 QuartzCore 0x18ec15498 CA::Layer::layout_if_needed(CA::Transaction*) + 496 12 UIKitCore 0x18f940c10 -[UIView(Hierarchy) layoutBelowIfNeeded] + 312 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 QuartzCore 0x18ec2cfe0 -[CALayer animationForKey:] + 176 1 UIKitCore 0x18fa5b258 UniqueAnimationKeyForLayer + 192 2 UIKitCore 0x18fa5ab7c __67-[_UIViewAdditiveAnimationAction runActionForKey:object:arguments:]_block_invoke_2 + 468 3 UIKitCore 0x18fa5ba5c -[_UIViewAdditiveAnimationAction runActionForKey:object:arguments:] + 1968 4 QuartzCore 0x18eb9e938 CA::Layer::set_bounds(CA::Rect const&, bool) + 428 5 QuartzCore 0x18eb9e760 -[CALayer setBounds:] + 132 6 UIKitCore 0x18f941770 -[UIView _backing_setBounds:] + 64 7 UIKitCore 0x18f940404 -[UIView(Geometry) setBounds:] + 340 8 UIKitCore 0x18f908f84 -[UIView(Geometry) _applyISEngineLayoutValuesToBoundsOnly:] + 480 9 UIKitCore 0x18f9089e0 -[UIView(Geometry) _resizeWithOldSuperviewSize:] + 148 10 CoreFoundation 0x18d0cd6a4 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 11 CoreFoundation 0x18d132488 -[__NSSingleObjectArrayI enumerateObjectsWithOptions:usingBlock:] + 92 12 UIKitCore 0x18f8e62b0 -[UIView(Geometry) resizeSubviewsWithOldSize:] + 128 13 UIKitCore 0x18f977194 -[UIView(AdditionalLayoutSupport) _is_layout] + 124 14 UIKitCore 0x18f976c2c -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 800 15 UIKitCore 0x18f916258 -[UIView(Hierarchy) layoutSubviews] + 204 16 UIKitCore 0x18f903814 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2424 17 QuartzCore 0x18ec15498 CA::Layer::layout_if_needed(CA::Transaction*) + 496 18 UIKitCore 0x18f940c10 -[UIView(Hierarchy) layoutBelowIfNeeded] + 312 So far, we only know of one iPad Air M1 where this is happening. But we don't know how many users experience this issue without reporting it. Does anyone know what could cause Auto Layout or Core Animation to block in those calls? We have no clue so far...
1
0
291
Apr ’25
Observe currentEDRHeadroom for changes
Is there a way to observe the currentEDRHeadroom property of UIScreen for changes? KVO is not working for this property... I understand that I can query the current headroom in the draw(...) method to adapt the rendering. However, our apps only render on-demand when the user changes parameters. But we would also like to re-render when the current EDR headroom changes to adapt the tone mapping to the new environment. The only solution we've found so far is to continuously query the screen for changes, which doesn't seem ideal. It would be better if the property would be observable via KVO or if there would be a system notification to listen for. Thanks!
2
0
1.4k
Feb ’25
Image Playground not available for "Designed for iPad" apps?
I'm currently trying to add support for Image Playground to our apps. It seems that it's not working in an app that is "Designed for iPad" and runs on a Mac. The modal just shows a spinner and the following is logged to console: Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> GP extension could not be loaded: Extension (platform: 2) could not be found (in update) dealloc Query controller [C32BA176-6A3E-465D-B3C5-0F8D91068B89] ImagePlaygroundViewController.isAvailable returns true, however. In a "real" Mac Catalyst app, it's working. Just not when the app is actually an iPad app. Is this a bug?
4
2
1.6k
Jan ’25
Resize Image Playground sheet
When using the imagePlaygroundSheet modifier in SwiftUI, the system presets an image playground in a fixed size. Especially on macOS, this modal is rather small and doesn't utilize the available space efficiently. Is there a way to make the modal bigger, or allow the user to resize the dialog? I tried presentationDetents, but this would need to be applied to the content of the sheet, which is provided by the system... I guess this question applies to other system-provided sheets like the photo picker as well.
2
0
825
Jan ’25
CGImageDestinationAddImageFromSource causes issues in iOS 18 / macOS 15
There seems to be an issue in iOS 18 / macOS 15 related to image thumbnail generation and/or HEIC. We are transcoding JPEG images to HEIC when they are loaded into our app (HEIC has a much lower memory footprint when loaded by Core Image, for some reason). We use Image I/O for that: guard let source = CGImageSourceCreateWithURL(inputURL, nil), let destination = CGImageDestinationCreateWithURL(outputURL, UTType.heic.identifier as CFString, 1, nil) else { throw <error> } let primaryImageIndex = CGImageSourceGetPrimaryImageIndex(source) CGImageDestinationAddImageFromSource(destination, source, primaryImageIndex, nil) When we use CGImageDestinationAddImageFromSource, we get the following warnings on the console: createImage:1445: *** ERROR: bad image size (0 x 0) rb: 0 CGImageSourceCreateThumbnailAtIndex:5195: *** ERROR: CGImageSourceCreateThumbnailAtIndex[0] - 'HJPG' - failed to create thumbnail [-67] {alw:-1, abs: 1 tra:-1 max:4620} writeImageAtIndex:1025: ⭕️ ERROR: '<app>' is trying to save an opaque image (4620x3466) with 'AlphaPremulLast'. This would unnecessarily increase the file size and will double (!!!) the required memory when decoding the image --> ignoring alpha. It seems that CGImageDestinationAddImageFromSource is trying to extract/create a thumbnail, which fails somehow. I re-wrote the last part like this: guard let primaryImage = CGImageSourceCreateImageAtIndex(source, primaryImageIndex, nil), let properties = CGImageSourceCopyPropertiesAtIndex(source, primaryImageIndex, nil) else { throw <error> } CGImageDestinationAddImage(destination, primaryImage, properties) This doesn't cause any warnings. An issue that might be related has been reported here. I've also heard from others having issues with CGImageSourceCreateThumbnailAtIndex.
0
0
1k
Nov ’24
Large memory consumption when running Core ML model on A13 GPU
We recently had to change our MLModel's architecture to include custom layers, which means the model can't run on the Neural Engine anymore. After the change, we observed a lot of crashes being reported on A13 devices. It turns out that the memory consumption when running the prediction with the new model on the GPU is much higher than before, when it was running on the Neural Engine. Before, the peak memory load was ~350 MB, now it spikes over 2 GB, leading to a crash most of the time. This only seems to happen on the A13. When forcing the model to only run on the CPU, the memory consumption is still high, but the same as running the old model on the CPU (~750 MB peak). All tested on iOS 16.1.2. We profiled the process in Instruments and found that there are a lot of memory buffers allocated by Core ML that are not freed after the prediction. The allocation stack trace for those buffers is the following: We ran the same model on a different device and found the same buffers in Instruments, but there they are only 4 KB in size. It seems, Core ML is somehow massively over-allocating memory when run on the A13 GPU. So far we limit the model to only run on CPU for those devices, but this is far from ideal. Is there any other model setting or workaround that we can use to avoid this issue?
Replies
3
Boosts
2
Views
2.2k
Activity
3d
Core ML memory usage is dramatically higher with an Xcode 27 build on iOS 27
I’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27. The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs. On the same iPad running iPadOS 27: Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint. Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used. I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime. The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak. I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change. If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit. A few additional observations: The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly. The first uncached run can survive model preparation because specialization spaces the loads farther apart. Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak. os_proc_available_memory() decreases in line with the newly reported footprint. With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes. Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27? In particular, I’m trying to understand: Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory? Is the new accounting used for the application’s jetsam/per-process memory limit? Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device. Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly? Are there recommended APIs or Core ML loading strategies for controlling this residency? Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.
Replies
0
Boosts
0
Views
165
Activity
1w
Is `.appEntityIdentifier` + `Transferable` the intended way to let Siri send an on-screen image to another app? (iOS 27)
I'm trying to make a third-party app's on-screen image available to Siri / Apple Intelligence so the user can say something like "send this to " and have the image handed off. And I'd like to confirm whether I'm using the intended mechanism or whether this particular case just isn't supported yet. What I'm trying to do My app shows a single image (it owns no photo library, the image is an in-app render). I want the user to be able to reference it as "this" and have Siri move it to another app. What I implemented (following Making onscreen content available to Siri and Apple Intelligence and WWDC26 240/343) A plain AppEntity with a stable id, conforming to Transferable, annotated on the image view with the iOS 27 .appEntityIdentifier(_:) modifier: struct OnScreenImageEntity: AppEntity, Transferable { static let typeDisplayRepresentation = TypeDisplayRepresentation(name: "On-Screen Image") static let defaultQuery = Query() let id: String static var transferRepresentation: some TransferRepresentation { DataRepresentation(exportedContentType: .plainText) { … } // distinctive text DataRepresentation(exportedContentType: .png) { … } // the image } struct Query: EntityQuery { func entities(for ids: [String]) async throws -> [OnScreenImageEntity] { logger.notice("entities(for:) CALLED \(ids)") // <- never fires return ids.filter { store.isCurrent($0) }.map(OnScreenImageEntity.init) } } } // on the view: Image(uiImage: image) .appEntityIdentifier(EntityIdentifier(for: OnScreenImageEntity.self, identifier: id)) What I observe (iOS 27 Beta 3, device) "Describe this image" / "Create a note for this" appear to use an automatic screenshot — the responses reference my app's UI chrome, and EntityQuery.entities(for:) is never called, so my entity's Transferable is not involved at all. "Send this to " doesn't attach the image; Siri says something like "I can't attach the image directly from your screen," which again sounds like a screen grab. entities(for:) is not called. The only flow that resolves my entity is the ChatGPT hand-off: asking Siri about the on-screen content calls entities(for:) (several times). But even there it stalls — Siri responds "could not clarify what you mean by 'about this'… document, image, or topic?", and no Transferable representation is ever read (my export closures never run). So the entity resolves, yet the content is never actually transferred. The older NSUserActivity.appEntityIdentifier route was never consumed at all; only the iOS 27 .appEntityIdentifier(_:) view modifier produced any resolution, and only in the ChatGPT flow above. I also understand from WWDC26 240/343 that the cross-app content move is built on IntentValueRepresentation (entity ↔ a system value type like IntentPerson), which the recipient imports via IntentValueQuery / IntentValueRepresentation(importing:). Since there doesn't seem to be a system value type for an arbitrary image (and IntentFile isn't one), I'm not sure an image entity can participate in that transfer at all. My questions Is .appEntityIdentifier(_:) the intended way to expose a single on-screen item in iOS 27? It only resolves my entity in the ChatGPT hand-off, and even then the Transferable is never read — under what conditions is the resolved entity's Transferable actually consumed? Are on-screen content requests ("describe this", "create a note for this") ever meant to use an app-provided AppEntity + Transferable, or are they always served by screen capture? (For me they never call entities(for:).) Is there a supported path for Siri to send an image from a third-party app's on-screen content to another app? If the transfer requires IntentValueRepresentation and there's no image system value, is a Transferable image representation ever consumed for this — and if so, how is it triggered? If this is simply not supported for image content yet, that's useful to know too, I just want to make sure I'm not missing a required piece (a schema conformance, an eligibility flag, a different annotation API, etc.). I have a minimal sample project that reproduces this (single annotated image, no photo library, logs to a subsystem so you can see entities(for:) never being called) and filed it as Feedback FB23813341 — happy to share details. Thanks!
Replies
4
Boosts
3
Views
306
Activity
1w
Receiving an on‑screen image from another app via App Intents / Siri (app has no photo library)
I have a photo editing app that owns no photo library. I want a user viewing an image in another app (e.g. Photos) to say "filter this image in MyApp" and have Siri hand that on‑screen image to my intent. Targeting iOS 27. What I've tried, and the result in each case: • App Shortcut + @Parameter var image: IntentFile — Siri resolves my other parameters (a filter AppEnum) by voice, but never binds the image; the run fails. • @AppIntent(schema: .photos.setFilter) with a .photos.asset entity — never routes from Photos. • @AppIntent(schema: .system.open): OpenIntent with a custom AppEntity target — "Open this image in MyApp" just launches the app by name; perform() is never called, and the entity query never runs. My understanding from WWDC26 "Build intelligent Siri experiences with App Schemas" (session 240) and "Discover new capabilities in the App Intents framework" (session 345): • Cross‑app content transfer (Transferable + IntentValueRepresentation) seems limited to system value types (IntentPerson, PlaceDescriptor); IntentFile is not a _SystemIntentValue, so an image can't ride that rail. • Onscreen awareness (NSUserActivity.appEntityIdentifier, View Annotations) appears to expose only the foreground app's own content — which here is Photos, not me. Question: Is there a supported way for a third‑party app to receive another app's on‑screen image (vs. a contact/place) through Siri/App Intents today? If so, which API carries the pixels — an IntentFile parameter, @UnionValue, IntentValueQuery, something else — and what must the source app do to make it available? Or is asking "do X to this image in <third‑party app>" simply not supported yet outside Shortcuts?
Replies
2
Boosts
1
Views
489
Activity
4w
Linker trying to link Metal toolchain for every object file on Catalyst
When building our project for Mac Catalyst with Xcode 26.2, we get this warning almost a hundred times, once for every object file: directory not found for option '-L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' Somehow, every Link <FileName>.o build step got the following parameter, regardless if the target contained Metal files or not: -L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst The toolchain is mounted at this point, but the directory usr/lib/swift/maccatalyst doesn't exist. When building the project for iOS, the option doesn't exist and the warning is not shown. We already check the build settings, but we couldn't find a reason why the linker is trying to link against the toolchain here. Even for targets that do contain Metal files, we get the following linker warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Is this a known issue? Is there a way to get rid of these warnings?
Replies
2
Boosts
3
Views
1.3k
Activity
Jun ’26
Managed Asset Pack not found by TestFlight reviewer
We have an on-demand asset pack that we download at the start of the app. We first present the user with the download size and the option to download the asset. The iOS version of our app went through review just fine, but the macOS version (Catalyst) is stuck. The reviewer reports an error that indicates that even the lookup of the asset pack (assetPack(withID:)) doesn't work. On all our test devices we don't have that issue. It seems the reviewer is running the app in an environment that is unable to load the asset pack information from TestFlight. We don't know what to do here. Any help would be appreciated!
Replies
4
Boosts
5
Views
348
Activity
Jun ’26
Managed Background Assets on iPadOS 26.3: metadata resolves, download never starts
Has anyone seen Managed Background Assets get stuck before any download progress is reported on iPadOS 26.3 / TestFlight? We are using Apple-hosted managed asset packs for a large on-demand model download. The app can resolve the asset pack metadata: we can show the asset pack’s download size in the UI, so AssetPackManager.assetPack(withID:) appears to work. But when we call ensureLocalAvailability(of:), the UI stays at 0% indefinitely. We also do not receive any useful terminal state from statusUpdates(forAssetPackWithID:): no .began, .downloading, .failed, or .finished. The app remains responsive. The issue also appears persistent on the affected device/account. Reinstalling the app does not help, reinstalling TestFlight does not help, logging out and back in does not help, and restarting the device does not help. After each attempt, the app can still resolve the asset pack metadata/download size, but the actual download remains stuck before any progress or failure status is delivered. The suspicious part of the device log is that the managed helper starts normally, fetches/installs the manifest from TestFlight, but repeatedly fails to create its helper directory inside the app container: OurApp Initializing the asset-pack manager… OurApp Creating a proxy object for the helper service… OurApp activating connection ... name=com.apple.backgroundassets.managed.helper.service kernel Sandbox: no system container path found for ID "com.apple.backgroundassets.managed.helper.service" Managed Background Assets Helper Service Starting the Managed Background Assets Helper Service… Managed Background Assets Helper Service Configuring the directory suffix… Managed Background Assets Helper Service The directory suffix was successfully configured. Managed Background Assets Helper Service The extension token "<...>" was consumed. kernel Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] After that, manifest fetching still seems to work: OurApp The asset-pack manager has been initialized. OurApp The system download-manager delegate has been assigned to the download manager. OurApp The app was installed for internal beta testing; checking for updates automatically… OurApp Refreshing the manifest… Managed Background Assets Helper Service The app with the bundle ID "..." is configured to use Apple hosting. Managed Background Assets Helper Service Asking the TestFlight extension via the App Store Daemon for the URL request... Managed Background Assets Helper Service Fetching the download manifest ... from TestFlight… Managed Background Assets Helper Service Installing a manifest at ".../Library/Application Support/.../Manifest.json"... But during/after manifest install, the same mkdir failure appears again: Managed Background Assets Helper Service Installing a manifest at ".../Manifest.json"... Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] kernel duplicate reports for Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service So the behavior seems to be: TestFlight/internal beta install Apple-hosted managed asset pack Manifest fetch succeeds Asset pack metadata resolves, including download size Actual local availability request never starts reporting progress No visible Background Assets failure reaches the app Logs show repeated sandbox file-write-create denial for the Managed Background Assets Helper trying to create /tmp/com.apple.backgroundassets.managed.helper.service inside the app container Reinstalling the app/TestFlight, logging out and back in, and restarting the device do not clear the stuck state On devices with 26.4, the issue doesn’t seem to exist Has anyone else seen this on iOS/iPadOS/macOS versions before 26.4? Is this a known issue in the Managed Background Assets helper/runtime? I noticed 26.4 added more local status APIs for asset packs, so I’m wondering whether this area changed in 26.4. Any hints on whether the sandbox denial is expected/noisy, or whether it could explain ensureLocalAvailability(of:) never progressing, would be appreciated.
Replies
1
Boosts
3
Views
326
Activity
Apr ’26
Sharing a JPEG via Action or Share Extension fails in Photos on macOS
We have a Share Extension that fails in Photos on macOS when trying to share a JPEG image for the following reason: From the NSItemProvider we get from the NSExtensionItem.attachments, we try to load the image using loadFileRepresentation(forTypeIdentifier: “public.image”, completionHandler: …). This fails for .jpeg images in the library. There seems to be a mismatch in expected and actual file extension internally. Here is the log: Error copying file type public.image. Error: Error Domain=NSItemProviderErrorDomain Code=-1000 "Cannot load representation of type public.jpeg" UserInfo={NSLocalizedDescription=Cannot load representation of type public.jpeg, NSUnderlyingError=0x1527c1a80 {Error Domain=NSItemProviderErrorDomain Code=-1 "Cannot copy file at URL file:///Users/frank/Library/Containers/com.apple.Photos/Data/tmp/TemporaryItems/ShareKit-Exports/7CCFA760-AAC9-42B0-812D-68F051ED1543/F912E593-2BE5-4E70-86AB-7657A40657E5/IMG_3517.jpg." UserInfo={NSLocalizedDescription=Cannot copy file at URL file:///Users/frank/Library/Containers/com.apple.Photos/Data/tmp/TemporaryItems/ShareKit-Exports/7CCFA760-AAC9-42B0-812D-68F051ED1543/F912E593-2BE5-4E70-86AB-7657A40657E5/IMG_3517.jpg., NSUnderlyingError=0x152789670 {Error Domain=NSItemProviderErrorDomain Code=-1 "Cannot create a temporary file. Error: Undefined error: 0" UserInfo={NSLocalizedDescription=Cannot create a temporary file. Error: Undefined error: 0}}}}}``` In the specified folder, there is an image, however, it’s named IMG_3517.jpeg, not IMG_3517.jpg. This seems to be a bug in Photo’s item provider implementation. If we use loadObject(ofClass: URL.self, completionHandler: …) instead, we get the correct .jpeg URL in the completion handler.
Replies
3
Boosts
1
Views
1.8k
Activity
Nov ’25
PHPicker fails to load RAW images
We observed that the PHPicker is unable to load RAW images captured on an iPhone in some scenarios. And it is also somehow related to iCloud. Here is the setup: The PHPickerViewController is configured with preferredAssetRepresentationMode = .current to avoid transcoding. The image is loaded from the item provider like this: if itemProvider.hasItemConformingToTypeIdentifier(kUTTypeImage) { itemProvider.loadFileRepresentation(forTypeIdentifier: kUTTypeImage) { url, error in // work } } This usually works, also for RAW images. However, when trying to load a RAW image that has just been captured with the iPhone, the loading fails with the following errors on the console: [claims] 43A5D3B2-84CD-488D-B9E4-19F9ED5F39EB grantAccessClaim reply is an error: Error Domain=NSCocoaErrorDomain Code=4097 "Couldn’t communicate with a helper application." UserInfo={NSUnderlyingError=0x2804a8e70 {Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 19420 on anonymousListener or serviceListener" UserInfo={NSDebugDescription=connection from pid 19420 on anonymousListener or serviceListener}}} Error copying file type public.image. Error: Error Domain=NSItemProviderErrorDomain Code=-1000 "Cannot load representation of type public.image" UserInfo={NSLocalizedDescription=Cannot load representation of type public.image, NSUnderlyingError=0x280480540 {Error Domain=NSCocoaErrorDomain Code=4097 "Couldn’t communicate with a helper application." UserInfo={NSUnderlyingError=0x2804a8e70 {Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 19420 on anonymousListener or serviceListener" UserInfo={NSDebugDescription=connection from pid 19420 on anonymousListener or serviceListener}}}}} We observed that on some devices, loading the image will actually work after a short time (~30 sec), but on others it will always fail. We think it is related to iCloud Photos: On the device that has iCloud Photos sync enabled, the picker is able to load the image right after it was synced to the cloud. On devices that don't sync the image, loading always fails. It seems that the sync process is doing some processing (?) of the image that will later enable the picker to load it successfully, but that's just guessing. Additional observations: This seems to only occur for images that were taken with the stock Camera app. When using Halide to capture RAW (either ProRAW or RAW), the Picker is able to load the image. When trying to load the image as kUTTypeRawImage instead of kUTTypeImage, it also fails. The picker also can't load RAW images that were AirDroped from another device, unless it synced to iCloud first. This is reproducable using the Selecting Photos and Videos in iOS sample code project. We observed this happening in other apps that use the PHPicker, not just ours. Is this a bug, or is there something that we are missing?
Replies
7
Boosts
1
Views
3.2k
Activity
Sep ’25
Images with unusual color spaces not correctly loaded by Core Image
Some users reported that their images are not loading correctly in our app. After a lot of debugging we identified the following: This only happens when the app is build for Mac Catalyst. Not on iOS, iPadOS, or “real” macOS (AppKit). The images in question have unusual color spaces. We observed the issue for uRGB and eciRGB v2. Those images are rendered correctly in Photos and Preview on all platforms. When displaying the image inside of a UIImageView or in a SwiftUI Image, they render correctly. The issue only occurs when loading the image via Core Image. When comparing the different Core Image render graphs between AppKit (working) and Catalyst (faulty) builds, they look identical—except for the result. Mac (AppKit): Catalyst: Something seems to be off when Core Image tries to load an image with foreign color space in Catalyst. We identified a workaround: By using a CGImageDestination to transcode the image using the kCGImageDestinationOptimizeColorForSharing option, Image I/O will convert the image to sRGB (or similar) and Core Image is able to load the image correctly. However, one potentially loses fidelity this way. Or might there be a better workaround?
Replies
2
Boosts
3
Views
421
Activity
Aug ’25
UI freeze during layouting
One of our users reported a very strange bug where our app freezes and eventually crashes on some screen transitions. From different crash logs we could determine that the app freezes up when we call view.layoutIfNeeded() for animating constraint changes. It then gets killed by the watchdog 10 seconds later: Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<bundleID(2A01F261-3554-44C0-B5A9-EBEB446484AD)>:6921 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 24.320 (user 18.860, system 5.460), 29% CPU", "Elapsed application CPU time (seconds): 10.630, 12% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> The crash stack trace looks slightly different, depending on the UI transition that is happening. Here are the two we observed so far. Both are triggered by the layoutIfNeeded() call. Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 CoreAutoLayout 0x1b09f90e4 -[NSISEngine valueForEngineVar:] + 8 1 UIKitCore 0x18f919478 -[_UIViewLayoutEngineRelativeAlignmentRectOriginCache origin] + 372 2 UIKitCore 0x18f918f18 -[UIView _nsis_center:bounds:inEngine:forLayoutGuide:] + 1372 3 UIKitCore 0x18f908e9c -[UIView(Geometry) _applyISEngineLayoutValuesToBoundsOnly:] + 248 4 UIKitCore 0x18f9089e0 -[UIView(Geometry) _resizeWithOldSuperviewSize:] + 148 5 CoreFoundation 0x18d0cd6a4 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 6 CoreFoundation 0x18d0cd584 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 432 7 UIKitCore 0x18f8e62b0 -[UIView(Geometry) resizeSubviewsWithOldSize:] + 128 8 UIKitCore 0x18f977194 -[UIView(AdditionalLayoutSupport) _is_layout] + 124 9 UIKitCore 0x18f976c2c -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 800 10 UIKitCore 0x18f903944 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2728 11 QuartzCore 0x18ec15498 CA::Layer::layout_if_needed(CA::Transaction*) + 496 12 UIKitCore 0x18f940c10 -[UIView(Hierarchy) layoutBelowIfNeeded] + 312 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 QuartzCore 0x18ec2cfe0 -[CALayer animationForKey:] + 176 1 UIKitCore 0x18fa5b258 UniqueAnimationKeyForLayer + 192 2 UIKitCore 0x18fa5ab7c __67-[_UIViewAdditiveAnimationAction runActionForKey:object:arguments:]_block_invoke_2 + 468 3 UIKitCore 0x18fa5ba5c -[_UIViewAdditiveAnimationAction runActionForKey:object:arguments:] + 1968 4 QuartzCore 0x18eb9e938 CA::Layer::set_bounds(CA::Rect const&, bool) + 428 5 QuartzCore 0x18eb9e760 -[CALayer setBounds:] + 132 6 UIKitCore 0x18f941770 -[UIView _backing_setBounds:] + 64 7 UIKitCore 0x18f940404 -[UIView(Geometry) setBounds:] + 340 8 UIKitCore 0x18f908f84 -[UIView(Geometry) _applyISEngineLayoutValuesToBoundsOnly:] + 480 9 UIKitCore 0x18f9089e0 -[UIView(Geometry) _resizeWithOldSuperviewSize:] + 148 10 CoreFoundation 0x18d0cd6a4 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 11 CoreFoundation 0x18d132488 -[__NSSingleObjectArrayI enumerateObjectsWithOptions:usingBlock:] + 92 12 UIKitCore 0x18f8e62b0 -[UIView(Geometry) resizeSubviewsWithOldSize:] + 128 13 UIKitCore 0x18f977194 -[UIView(AdditionalLayoutSupport) _is_layout] + 124 14 UIKitCore 0x18f976c2c -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 800 15 UIKitCore 0x18f916258 -[UIView(Hierarchy) layoutSubviews] + 204 16 UIKitCore 0x18f903814 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2424 17 QuartzCore 0x18ec15498 CA::Layer::layout_if_needed(CA::Transaction*) + 496 18 UIKitCore 0x18f940c10 -[UIView(Hierarchy) layoutBelowIfNeeded] + 312 So far, we only know of one iPad Air M1 where this is happening. But we don't know how many users experience this issue without reporting it. Does anyone know what could cause Auto Layout or Core Animation to block in those calls? We have no clue so far...
Replies
1
Boosts
0
Views
291
Activity
Apr ’25
Observe currentEDRHeadroom for changes
Is there a way to observe the currentEDRHeadroom property of UIScreen for changes? KVO is not working for this property... I understand that I can query the current headroom in the draw(...) method to adapt the rendering. However, our apps only render on-demand when the user changes parameters. But we would also like to re-render when the current EDR headroom changes to adapt the tone mapping to the new environment. The only solution we've found so far is to continuously query the screen for changes, which doesn't seem ideal. It would be better if the property would be observable via KVO or if there would be a system notification to listen for. Thanks!
Replies
2
Boosts
0
Views
1.4k
Activity
Feb ’25
Image Playground not available for "Designed for iPad" apps?
I'm currently trying to add support for Image Playground to our apps. It seems that it's not working in an app that is "Designed for iPad" and runs on a Mac. The modal just shows a spinner and the following is logged to console: Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> Private sandbox for com.apple.GenerativePlaygroundApp.remoteUIExtension : <none> GP extension could not be loaded: Extension (platform: 2) could not be found (in update) dealloc Query controller [C32BA176-6A3E-465D-B3C5-0F8D91068B89] ImagePlaygroundViewController.isAvailable returns true, however. In a "real" Mac Catalyst app, it's working. Just not when the app is actually an iPad app. Is this a bug?
Replies
4
Boosts
2
Views
1.6k
Activity
Jan ’25
Resize Image Playground sheet
When using the imagePlaygroundSheet modifier in SwiftUI, the system presets an image playground in a fixed size. Especially on macOS, this modal is rather small and doesn't utilize the available space efficiently. Is there a way to make the modal bigger, or allow the user to resize the dialog? I tried presentationDetents, but this would need to be applied to the content of the sheet, which is provided by the system... I guess this question applies to other system-provided sheets like the photo picker as well.
Replies
2
Boosts
0
Views
825
Activity
Jan ’25
CGImageDestinationAddImageFromSource causes issues in iOS 18 / macOS 15
There seems to be an issue in iOS 18 / macOS 15 related to image thumbnail generation and/or HEIC. We are transcoding JPEG images to HEIC when they are loaded into our app (HEIC has a much lower memory footprint when loaded by Core Image, for some reason). We use Image I/O for that: guard let source = CGImageSourceCreateWithURL(inputURL, nil), let destination = CGImageDestinationCreateWithURL(outputURL, UTType.heic.identifier as CFString, 1, nil) else { throw <error> } let primaryImageIndex = CGImageSourceGetPrimaryImageIndex(source) CGImageDestinationAddImageFromSource(destination, source, primaryImageIndex, nil) When we use CGImageDestinationAddImageFromSource, we get the following warnings on the console: createImage:1445: *** ERROR: bad image size (0 x 0) rb: 0 CGImageSourceCreateThumbnailAtIndex:5195: *** ERROR: CGImageSourceCreateThumbnailAtIndex[0] - 'HJPG' - failed to create thumbnail [-67] {alw:-1, abs: 1 tra:-1 max:4620} writeImageAtIndex:1025: ⭕️ ERROR: '<app>' is trying to save an opaque image (4620x3466) with 'AlphaPremulLast'. This would unnecessarily increase the file size and will double (!!!) the required memory when decoding the image --> ignoring alpha. It seems that CGImageDestinationAddImageFromSource is trying to extract/create a thumbnail, which fails somehow. I re-wrote the last part like this: guard let primaryImage = CGImageSourceCreateImageAtIndex(source, primaryImageIndex, nil), let properties = CGImageSourceCopyPropertiesAtIndex(source, primaryImageIndex, nil) else { throw <error> } CGImageDestinationAddImage(destination, primaryImage, properties) This doesn't cause any warnings. An issue that might be related has been reported here. I've also heard from others having issues with CGImageSourceCreateThumbnailAtIndex.
Replies
0
Boosts
0
Views
1k
Activity
Nov ’24