I intended not to make it work somehow, but the way Apple demonstrated in all the marketing material of Siri AI. The interaction should feel natural to the user. And having to take a screenshot is definitely not something the user would expect to do.

Not really... I doubt that may users will say "edit this in ". "Open this in " would be much better, but I found no way to support that so far. I'm currently also implementing .setFilter, which is kinda neat. It triggers on something like "apply the x effect to this in ".

Correction correction: PHAsset is not a supported parameter type for editAsset—I was wrong. Full library access is still required... 😮‍💨

Correction: It seems PHAsset is now a supported parameter type for editAsset. So no full library access is needed anymore! 🥳

No. It seems Siri doesn't support anything that requires an IntentFile parameter. We are working around this by supporting the photos.editAsset schema. This at least allows Siri to open an image from Photos in our app. But it feels hacky and our app needs full photo library access for it to work. So it's more of a workaround right now.

Also seeing this issue in our apps. Thanks for the swift response and the workaround. Hopefully, this will be fixed in beta 5. 🤞

Thanks for the response, J0hn! Btw, did you find a solution for the import use case (as we discussed in this thead)?

Good to hear that I'm not alone. I also tried the generic .system.open, but no external data is passed to my app. 🤷‍♂️

Thanks! I reached out twice (102888358215 & 102895781178). App Review is supposed to call me in the next few days. But I'm honestly not sure how much they can do. It seems to be a technical issue with the review environment. I'm glad you are looking into this!

Thanks for looking into this, Quinn! Feedback is filed under FB22188848.

How did you write your kernels before? In CI Kernel Language? If so, I would highly recommend to not mix Metal and CIKL kernels in one rendering. It's best if you can translate all your kernels to Metal.

Good question. I would recommend to use the startTask(...) APIs of CIContext to render to a CIRenderDestionation. You get a CIRenderTask object back, on which you can call waitUntilCompleted() to get a CIRenderInfo object. When you Quick Look that in Xcode (mark the variable and press space), you get a very detailed render graph that, among many other useful info, shows how much memory the render pass required.

Hmm, this looks to me like a problem with profiling itself. If you run the experiment just in Xcode and watch the memory graph, you'll see that memory will return to normal a little while after rendering. Even if spamming the button, memory stays well within the resource limits. I don't know why, when profiling with instruments, those small 4 MiB surfaces don't get released. 🤷‍♂️

I can confirm what @ihomway says: it works after a reboot. 👍

It's still not working. Do we need to remove the previous toolchain download somehow?