Same here. 🖐️

I'm not sure using Core Image is the best choice here. CI might impose limits on the runtime of kernels, and your regression kernel seems too expensive. It's also not intended that you pass the images and mask as CGImage via the arguments into the kernel. It would be better if you'd convert them to CIImage first and then pass them via the inputs parameter. CI would then convert them to Metal textures for you. Unfortunately, Core Image doesn't support texture arrays, so you would need to find a workaround for that. Have you tried running your kernel in a pure Metal pipeline? It might be the better choice here. Or do you need it to be part of a Core Image pipeline?

It turns out that the issue is only occurring when there is also a CIContext being initialized in the same file (it doesn’t matter where in the file). As soon as I remove the CIContext, the compiler doesn't complain anymore about the cast to IOSurfaceRef (doesn't even need to be a force-cast), and there is also no runtime error.

Any updates on this issue? I unfortunately still can't ask a question about App Intents and Apple Intelligence. 😕

It's not yet available: Apple Intelligence will be available in an upcoming beta. https://developer.apple.com/apple-intelligence/

The static properties on CIFormat are lets now in iOS 18 / macOS 15. 👍

I can confirm the issue (tested the Core Image API). Interestingly, the heif10Representation(...) API still works as expected.

Did you set wantsExtendedDynamicRangeContent on the CAMetalLayer? What happens when you set the layer's colorSpace to some HDR color space? Also, make sure that you set the CIRenderDestinations colorSpace to the same space as the layer.

So far, there is no API in visionOS that allows developers access to the live video feed. This is by design, and most likely to protect the user's privacy: While on an iPhone you explicitly consent to sharing your surroundings with an app by pointing your camera at things, you can't really avoid that on the Apple Vision Pro.

Filed as FB13531865. Thanks!

I think there is no official API to reset single tips. As a workaround, you could change the id of the tip. This will cause TipKit to handle it as a new tip and show it again.

I guess it has to do with the affine transform you apply to the image before you do the clampedToExtent(): As you can see, the output of the transform has non-integer extent. This probably creates a row of transparent pixels at the top of the image, that is then repeated when applying clampedToExtent(). To avoid this, you can calculate the scale factors for your transform separately for x and y to ensure that the resulting pixel size is integer. Alternatively, you can apply the clamping before you apply the affine transform.

Filed as FB13419598. Thanks!

I was wondering the same thing, and it seems that improvements are coming in later versions.

From the comment in the header file: A NSNumber that specifies the maximum memory footprint (in megabytes) that the CIContext allocates for render tasks. Larger values could increase memory footprint while smaller values could reduce performance. It basically sets how much memory Core Image is allowed to use (roughly) during rendering. From what I observed, the default seems to be 256 MB.