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

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?

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

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!

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?

I am trying to compress a CIImage below a certain file size threshold when creating a JPEG. Currently, I am handling this in, potentially, multiple passes. In the first pass, I am essentially calling:
encodeJPEG(CIImage, quality: 0.85, colorSpace: CIImage.colorSpace ?? CGColorSpace(name: CGColorSpace.sRGB)!)
I am then checking the image size. If the image is still too big, I try to estimate how much I need to reduce it and try again until the image size is small enough. My question: Is there a more efficient way of doing this?

The iPhone Lock Screen lets you display a small time and date at the top of the display that has a neat image processing effect where the text takes on the underlying colors with a blurred gradient while still maintaining legibility appearing largely white. In this screenshot you can see the white text features blue colors at the top left and transitions to a purple color on the right due to the underlying vibrant blue and purple blocks. Can you share how this text effect is achieved using Core Image?

I’m really excited about RAW 9, great work! Since RAW 9 is not enabled by default, are there any recommended use cases where it makes sense to select it by default, if supported? For compatibility handling, should I treat decoderVersion as covering all processing and adjustments performed by CIRAWFilter, or does it mostly affect the RAW decoding stage? When switching decoder versions, should I re-evaluate which CIRAWFilter adjustments are supported? Also, the macOS 26 headers appear to expose version9 and version9DNG. Is RAW 9 actually supported on macOS 26 runtimes? Thanks!

CIRAWFilter documentation lists despeckleAmount as available on macOS 12.0+, but I cannot find this property in the macOS 26 headers. Could you provide a detailed description of how despeckleAmount affects the image so I can explain this adjustment accurately to my users? Does it run before or after linearSpaceFilter, and what should it be set to when generating scene-referred linear output? Thanks!

What is the high water mark for rendering an image in RAW 9 vs. RAW 8? I realize it depends on the megapixels of the render, but what can you share memory wise, especially compared to RAW 8, perhaps as a multiple? I'm mostly concerned about iOS in case that's relevant.

What is the minimum iPhone system requirement for RAW 9? Anything that can run iOS 27 / iPadOS 27 / macOS 27? I was getting some ANE errors on an M1 MacBook Air this morning (FB23103074)

In our PhotoKit backup/export code, we need to read PHAssetResource.originalFilename for each resource. The Swift API imports this property as non-optional: var originalFilename: String { get } However, we have customer reports from real Photos libraries where reading this property appears to crash because the underlying Objective-C value is nil at runtime. This affects actual users of our shipping app, not just a synthetic test case. The relevant code path is essentially this: import Photos func inspectAsset(_ asset: PHAsset) { let resources = PHAssetResource.assetResources(for: asset) for resource in resources { // This property is imported as non-optional String. // For some affected customer assets, reading it appears to trap/crash // because the underlying value is nil. let filename: String = resource.originalFilename print(filename) } } This makes the API difficult to use safely from Swift: because the property is non-optional, there is no normal Swift optional-handling path before the crash. We filed this as FB22589474. We also filed a related Feedback, FB22519412, for empty-string / otherwise unusable filename values. That is a separate issue, but it points in the same direction: apps that export, back up, or sync Photos resources cannot treat PHAssetResource.originalFilename as a guaranteed usable filename. For PHAssetResource.originalFilename, what is the intended contract?