I'm implementing PHBackgroundResourceUploadExtension to back up photos and videos to our cloud storage service. During testing, I observed that iCloud-optimized photos (where the full-resolution original is stored in iCloud, not on device) do not upload. The upload job appears to silently skip these assets. Questions: Is this behavior intentional/documented? I couldn't find explicit mention of this limitation. If the device only has the optimized/thumbnail version locally, does the system: - Automatically download the full-resolution asset from iCloud before uploading? - Skip the asset entirely? - Return an error via PHAssetResourceUploadJobChangeRequest? For a complete backup solution, should we: - Pre-fetch full-resolution assets using PHAssetResourceManager.requestData(for:options:) before creating upload jobs? - Use a hybrid approach (this extension for local assets + separate logic for iCloud-only assets)? Environment: iOS 26, Xcode 18

Through the Photos framework, we can access (and thus backup) resources the user created in Photos, such as Adjustments.plist, AdjustmentsSecondary.data, .aae files and more. Is there any way to restore those resources back into the Photos library? (e.g., similar to dropping a combination of .heic and .mov file to restore a Live Photo)

Thanks for adding CoreML into the Apple RAW decoder. I'm excited with what it can bring. But I'm having a number of issues with it. My code base is written in Objective-C, and I'm using my custom MTKView. Now when I enabled RAW 9 support, the render is extremely slow (instant vs seconds). The UI would appear to hang with a spinning color wheel. It feels like CoreML processing is being delegated in the rendering thread, which runs on the main queue. How can I improve performance? As someone has reported, there is a black horizontal line in the middle of the image. The image that I was testing came from Fuji X-T5. If I enable EDR (Extended Dynamic Range), RAW 9 stops rendering, and will return ANE error. My app does HDR rendering of RAW files. I cannot get something like Sony A7R IV ARW image to load. Same ANE error. Is there a memory setting I need to tweak? When I render the X-T5 image, the colors appear to be overly saturated, which is different from the result of RAW 8. I cannot speak for the color rendering of other types of RAW files. I was told code base with Catalyst (and perhaps Swift) works without issue, other than being slow (except for large RAW files), but there seems to be an issue with Objective-C?

I'm implementing a PHBackgroundResourceUploadExtension to back up photos and videos from the user's library to our cloud storage service. Our existing upload infrastructure uses chunked uploads for large files (splitting videos into smaller byte ranges and uploading each chunk separately). This approach: Allows resumable uploads if interrupted Stays within server-side request size limits Provides granular progress tracking Looking at the PHAssetResourceUploadJobChangeRequest.createJob(destination:resource:) API, I don't see a way to specify byte ranges or create multiple jobs for chunks of the same resource. Questions: Does the system handle large files (1GB+) automatically under the hood, or is there a recommended maximum file size for a single upload job? Is there a supported pattern for chunked/resumable uploads, or should the destination URL endpoint handle the entire file in one request? If our server requires chunked uploads (e.g., BITS protocol with CreateSession → Fragment → CloseSession), is this extension the right mechanism, or should we use a different approach for large videos? Any guidance on best practices for large asset uploads would be greatly appreciated. Environment: iOS 26, Xcode 18

We are building a musician practice application that uses MusicKit.js inside a WKWebView on iOS and macOS. One of our core use cases is musical looping, where playback repeatedly seeks back to a loop start position while a song is playing. A typical loop length is 1-4 seconds, making interruptions that might be acceptable for general media playback very noticeable in our use case. For looping we currently use MusicKit’s seekToTime() API. We have also experimented with audioElement.fastSeek() and directly setting audioElement.currentTime. In all cases, seeking to a nearby position during playback produces an audible hitch or pause, even when the destination appears to already be buffered. We have observed similar interruptions when changing the playback rate during playback. For comparison, the same JavaScript bridge architecture running in a Chromium-based WebView on Android exhibits significantly smoother seek behavior and supports near-seamless looping. At this point, the WebView media stack appears to be the primary platform difference we have identified. We are currently using MusicKit.js v2. We are aware that v3 is available, but have not found anything suggesting this behavior has changed. As part of our investigation, we also experimented with Apple’s native MusicKit APIs. We observed that seeking and playback-rate changes can still produce audible interruptions, although playback-rate changes behave noticeably better than our MusicKit.js / HTML audio implementation. This led us to wonder whether the behavior originates from the underlying Apple media pipeline rather than MusicKit.js itself. Our questions are: Is it expected that seeking during playback, whether through seekToTime(), fastSeek(), or currentTime, causes the playback pipeline to be interrupted or rebuilt on Apple platforms? Are there known differences in WebKit’s media pipeline, buffering, or seek handling that would explain why the same implementation exhibits smoother seek behavior in a Chromium-based WebView? If so, are there recommended WebKit, WKWebView, or MusicKit.js techniques to achieve smoother, near-seamless looping? Given that we observe similar, though less pronounced, behavior when using native MusicKit APIs, is this a known characteristic or limitation of the underlying Apple media stack? If so, are there any APIs or implementation patterns recommended for applications that require tight musical looping and low-latency seeks? Any guidance would be greatly appreciated. Our goal is to provide musicians with seamless looping for practice and transcription, where even very small interruptions are noticeable.

I would like to use the memory limit during interactive editing on iOS to decrease jetsam risk. However, I'm unsure of what to set it to. Do you have a recommendation as a fraction of physical memory? I have set the extended virtual memory entitlement, but I don't know what fraction of physical memory (or more) that entitlement enables - perhaps I should use a larger memory limit for M1-based iPads?

Thanks for adding CoreML into the Apple RAW decoder. I'm excited with what it can bring. But I'm having a number of issues with it. My code base is written in Objective-C, and I'm using my custom MTKView. Now when I enabled RAW 9 support, the render is extremely slow (instant vs seconds). The UI would appear to hang with a spinning color wheel. It feels like CoreML processing is being delegated in the rendering thread, which runs on the main queue. How can I improve performance? As someone has reported, there is a black horizontal line in the middle of the image. The image that I was testing came from Fuji X-T5. If I enable EDR (Extended Dynamic Range), RAW 9 stops rendering, and will return ANE error. My app does HDR rendering of RAW files. I cannot get something like Sony A7R IV ARW image to load. Same ANE error. Is there a memory setting I need to tweak? When I render the X-T5 image, the colors appear to be overly saturated, which is different from the result of RAW 8. I cannot speak for the color rendering of other types of RAW files. I was told code base with Catalyst (and perhaps Swift) works without issue, other than being slow (except for large RAW files), but there seems to be an issue with Objective-C?

My app currently supports display and editing of RAW files in HDR mode (Extended Dynamic Range). I came across 2 issues: In HDR mode, if I am using the default boostAmount = 1.0, then some of the highlight colors will shift. Like a clear blue sky becomes a light gray / light purple sky. I've to set boostAmount = 0.0 to avoid this problem. Is this a bug or is there a way to keep the Apple colors and not having this issue? The Shadow and highlight filter does not appear to work correctly in HDR mode, I've it hooked up in the linearSpaceFilter. Would be nice if you guys can introduce a spatial aware shadow & highlight filter.

What is the difference (if any) between RAW 9 and RAW 9.DNG in terms of quality, noise reduction, and color?

Are color differences expected for any cameras? I have heard some reports, but have not seen it myself. If it's not expected, then I can get those people to file bugs.

Is the memoryLimit option mentioned in WWDC26 session 305 the same option as CIContextOption.memoryTarget? The session says the default memory target on iOS is 256 MB. What is the default memoryTarget on macOS? Also, the session recommends the Extended Virtual Addressing entitlement for interactive RAW editing. That entitlement does not appear to be available for macOS, so does Core Image automatically use a larger intermediate cache budget on macOS? Should memoryTarget be used only for export contexts, or can/should it also be tuned for interactive editing contexts with cacheIntermediates enabled? Thanks!

Thanks for adding CoreML into the Apple RAW decoder. I'm excited with what it can bring. But I'm having a number of issues with it. My code base is written in Objective-C, and I'm using my custom MTKView. Now when I enabled RAW 9 support, the render is extremely slow (instant vs seconds). The UI would appear to hang with a spinning color wheel. It feels like CoreML processing is being delegated in the rendering thread, which runs on the main queue. How can I improve performance? As someone has reported, there is a black horizontal line in the middle of the image. The image that I was testing came from Fuji X-T5. If I enable EDR (Extended Dynamic Range), RAW 9 stops rendering, and will return ANE error. My app does HDR rendering of RAW files. I cannot get something like Sony A7R IV ARW image to load. Same ANE error. Is there a memory setting I need to tweak? When I render the X-T5 image, the colors appear to be overly saturated, which is different from the result of RAW 8. I cannot speak for the color rendering of other types of RAW files. I was told code base with Catalyst (and perhaps Swift) works without issue, other than being slow (except for large RAW files), but there seems to be an issue with Objective-C?

Aside from setting inputScaleFactor and using cacheIntermediates, what are the most important things to do to get great interactive performance with Core Image (both when constructing a CIImage from URL and using CIRAWFilter). Perhaps CIImage lifetimes or how they are mutated? Alternatively, what patterns (again other than inputScaleFactor / cacheIntermediates) most hurt performance?

I render images using a tiled/LOD pipeline. The final render usually requests only the visible ROI at the current display scale, which works well for local filters. The difficult case is filters that need a lower-resolution full-extent or larger-extent input, such as guided filters, blurs, histograms/statistics, and reduce passes. If that dependency remains inside the same CI graph, ROI propagation can force larger-extent evaluation of the upstream image, defeating small-ROI rendering. My current approach is to render those intermediates in a separate lower-resolution CI render pass, cache the result, and feed the rendered intermediate back into the final graph. Is this the recommended architecture, or is there a better Core Image structure for expressing this kind of intermediate render/cache barrier without manually creating and rendering a separate intermediate graph? Thanks!

Could you provide a more detailed description of how isHighlightRecoveryEnabled affects the image, and how it differs from isGamutMappingEnabled? I’d like to explain these controls accurately to my users. Does highlight recovery run before or after linearSpaceFilter, and should it be disabled when generating scene-referred linear output? Thanks!

In WWDC20 it was mentioned that missing compileTime/renderTime (or no intermediate image with the dump-intermediates option) can indicate a cached intermediate. I have also seen renderTime=cacheHit on passes that are clearly rendering intermediates, and an actual renderTime is only properly shown on the final pass which always seems to equal the final time render time. In compileTime it says cacheMiss. Which fields should be considered authoritative for tracking intermediate cache hits versus actual rendering? Thanks!

Here are two additional RAW 9 bugs: Horizontal Line in RAW 9 decode: FB23076983 CIRAWFilter.scaleFactor not respected in RAW 9 for some RAW formats: FB23076984

In my testing, enabling isDraftModeEnabled improves decode performance for very large non-RAW images. Does it also affect decoding performance or quality for RAW images? Are there non-RAW formats that benefit more than others, or not at all, with draft mode? For non-RAW images, is it generally recommended to load them through CIRAWFilter or CIImage? If CIImage is preferred, is there an equivalent to isDraftModeEnabled for CIImage initialization? Conversely, if CIRAWFilter is acceptable for non-RAW images, how can I get the expandToHDR behavior that is available through CIImage options? Thanks!

When processing RAW images with CIRAWFilter's extendedDynamicRange, does the boost filter’s behavior change? How does boost handle extended range values and does boost have a limit before clamping? Also, in the RAW EDR case, should we still use the linearSpace filter or is it now fine to run filters post-boost (assuming the filters are linear-dependent and can run post-boost)

Which of the Vision framework‘s support for grounding/bounding boxes/segmentation carry over to the iOS 27 on-device Foundation Model image support?