Is it possible to compile and run iOS Metal apps in simulator?

No, Metal is not supported in the iOS Simulator.

The last day I tried creating a new dummy project that uses Metal. Surprisingly I was able to compile and run the project in simulator without any compilation error. I ran it in iPad Air 2 simulator. But when I started debugging I found that the Metal APIs (for ex: MTLDevice ) was returning null values.

Then I started compiling my project in the simulator (iPad Air 2). I was able to compile and run it, but in the same way the Metal APIs are returing null values. I am using XCode 7.1 and OS X version is 10.10.5 (Yosemite) as I mentioned in my previous post.

I am not sure how this is happening. Does it mean that from XCode 7 and above it is possible to compile the iOS Metal projects in simulator ? Regarding the null values I am getting this thought in mind that it may happening because Yosemite doesn't have the Metal APIs. If I upgrade to EI Captain this might get resolved.

Is my understanding correct?

Whether or not you are able to use Metal APIs in a given target is dependent on the selected platform and SDK. As there is no Metal.framework (or MetalKit.framework, etc) for the iOS Simulator SDK, what you are describing should be impossible. Regardless of whether you're running OS X Yosemite or El Capitan, Metal is not supported in the Simulator.

wcm - thanks for being so clear. Are there any plans to support it? And if not, why not? Seems like a bit of an omission...

Remember, the simulator is not an emulator and runs a stack built for i386...your computer.

See Testing and Debugging in Simulator for the differences when using it vs. a device

Even though Metal is not supported in simulator, headers files should be present. Otherwise, the project doesn't compile, and frameworks that depend on Metal have to workaround the lack of Metal Performance Shaders headers, such as CVMetalTexture from CoreVideo, CAMetalDrawable from QuartzCore and MTKView from MetalKit do. They could provide the headers with a stub implementation.

We created a framework (https://github.com/xmartlabs/MetalPerformanceShadersProxy) for frameworks and apps that depend on Metal to be able to (among other things):

• Upload a pod to CocoaPods.
• Make a framework to work with Carthage.
• Run an app on a simulator to use features that don't depend on Metal shaders.
• Compile unit tests.
• Test automatically (maybe with a CI server) with simulators the parts of an app that don't depend on Metal shaders.

With iOS 13 it seems like it's changing, but i do have an issue : https://forums.developer.apple.com/message/363736#363736

Would you have an answer for me @wcm ?

With Xcode 11 on macOS 10.15, the iOS 13 / tvOS 13 simulators support Metal. (The watchOS simulator uses Metal under the hood but Metal is not a public framework there).

You can check out the new docs here: https://developer.apple.com/documentation/metal/developing_metal_apps_that_run_in_simulator

This includes the ability to build projects for simulators that include metal files. When back-deploying to older simulators MTLCreateSystemDefaultDevice() will return nil.

The Xcode 11 simulator on Catalina does support Metal, and I am able to display my CIImage in an MTKView, but everything is coming out upside down on the simulator. On the device things still work normally. So this feature isn't as usable as it might be.

Any idea why compiling a Metal shader at runtime from source on the iOS 13 Simulator fails with the following error:

Error: PCH file built from a different branch ((metalfe-902.9.49)) than the compiler ((metalfe-902.9.52))

But works fine for an iOS 13 device?

Did you ever figure out how to fix this issue in the simulator? I'm running into the same problem.

Update: just discovered something interesting! If I use

CIRenderDestination(mtlTexture:commandBuffer:)

to create a render destination, my CIImage is rendered upside-down in the simulator. However, if I use

CIRenderDestination(width:height:pixelFormat:commandBuffer:mtlTextureProvider:)

the image is rendered correctly. Seems like a bug...I'll file one.