Metal, Vulkan, OpenGL & Godot

Never used Vulkan so I can't comment on it.

But with respect to OpenGL and Metal, you seem to have them swapped. It's OpenGL that requires an initial compilation phase. One of the key features of Metal is that it doesn't need that. I'm unaware of any performance problems with Metal, although some higher-level APIs like SpriteKit have had performance problems recently.

Perhaps your 5 second startup time and performance problems are related to whatever Godot happens to be. Try Xcode and Swift instead.

Thanks for prompt reply!!

Well I guess the behaviour could differ on each type of app..

-To clarify:

The 5-second freeze is specific to Godot's Metal backend, not Metal itself.

Godot uses a cross-platform shader system (GLSL/SPIR-V) that gets compiled to Metal Shader Language at runtime on first launch.

On first launch with Godot's Metal backend (Metal 4.0, Forward Mobile) on an iPhone 12 (Apple A14 GPU), shader compilation occurs at runtime as Godot translates its cross-platform GLSL/SPIR-V shaders to Metal Shader Language.

In my case, this causes +5 second blocking freeze on first launch.

Subsequent launches are very fast (~1.5 seconds) as the compiled shaders are cached.

This is a known and actively discussed topic in Godot.. not a Metal limitation per se, but a consequence of Godot's runtime shader compilation pipeline.

-Native Swift/Metal apps don't have this problem because their shaders are pre-compiled at build time.

-The Vulkan path in Godot (via MoltenVK) also compiles shaders at runtime, but it seems like the the compilation is done lazy/delayed and spread across the startup sequence; not causing a blocking freeze.

-But well, beyond all technicalities..

The underliying question remains!

Is OpenGL ES3 viable for App Store submission in 2026, or is there a reason to avoid it beyond the scary Deprecation label?

Will apps built for OpenGL be Rejected right away on the Store Review process?

@cosmic-28 Welcome to the iOS development ecosystem. However, "deprecated" does not mean "banned."

The dilemma you are facing is very common among game developers, especially those using 3rd party engines that are actively transitioning their rendering backends.

Transitioning to native development using Xcode and Metal is the best long-term strategy for maximizing performance, minimizing battery drain, and fully utilizing Apple Silicon. While third party game engines are fantastic for cross-platform development, writing directly for Metal allows you to bypass the translation layers and engine-level bottlenecks like the 5-second shader compilation freeze you experienced.

Resources for metal:

• Metal Landing Page: developer.apple.com/metal
• Metal Programming Guide / Documentation: developer.apple.com/documentation/metal
• Sample Code: Using a Render Pipeline to Render Primitives - A great "Hello World" for drawing your first 2D shapes in Metal.

Migrating from OpenGL to Metal Since your app currently relies on OpenGL, Apple provides specific documentation on how to map OpenGL concepts (like state machines and draw calls) to Metal's command buffers and pipeline state objects. developer.apple.com/documentation/metal/migrating_opengl_code_to_metal

The 5-second freeze you experienced in Godot is due to runtime shader compilation. In a native Xcode/Metal workflow, you can compile your shaders offline completely eliminating this freeze.

Building a Library with Metal's Command-Line Tools:developer.apple.com/documentation/metal/libraries/building_a_library_with_metal_s_command-line_tools

Hope all this will help you get started. Can't wait to see the results.

Albert
  Worldwide Developer Relations.

Thanks!

In a native Metal workflow you're absolutely right, offline shader compilation could eliminate the freeze entirely.

However in Godot, shaders are written in GLSL and compiled to SPIR-V as a cross-platform intermediate format,

and then at runtime MoltenVK or Godot's Metal backend translates that SPIR-V to MSL, and compiles the Metal PSOs at runtime on the device.

This needs to happen at runtime cause the translated output can vary per device/driver, and Godot also generates shader variants based on scene content, so the full set of required shaders may not be known at build time.

The compiled PSOs are cached after first launch, which is why subsequent launches are fast;

but that first-launch freeze is currently a known limitation of Godot's Metal backend specifically.

-My Audio App works Perfectly as good with all three APIs on my iPhone 12, iOS 26.

So it's not a matter of porting it but,

making the best decision that will comply with Apple policy, and will give the Best experience to iOS users!

If it wasn't for the Compilation Freeze, there will be no question: Metal!

Even tho it may have a bigger CPU hit, it's the official API and makes all the sense.

But yeah, alas fact of the matter is, right now OpenGL or Vulkan/MoltenVK are giving a better experience. - No Freeze!

And that's the situation!

-If OpenGL is not Forbidden, and the app won't be flagged in the Review process..

Then it's a pretty considerable solution, as it gives the best performance and user experience atm.. right?

So maybe I could use OpenGL until the Compilation Freeze aspect is improved in Godot?

-Being a Pro Audio app, the 5 seconds freeze on first launch can make new users think it's Broken or smth.. right?

And I dont think there's a way to show a specific "Compiling Shaders" message on init;

But I will investigate that, and see if multiple bootsplash images can be used in Godot..

-As a side note..

I've already made some improvements to Godot's Metal implementation with Claude+Grok;

Just modernizing the CADisplayLink frame rate API from the deprecated preferredFramesPerSecond to the modern preferredFrameRateRange, which reduced CPU overhead a bit..

But the shader Compilation Freeze is a deeper issue that would require changes to Godot's Metal PSO pipeline itself.. which I know nothing about!

I just bought a macbook m3 two months ago, and here we are..! :)

@cosmic-28

Thank you for your response. I can't comment about the 3rd party you are using.

Metal engineers are likely to engage in this intriguing discussion and provide further insights into the process, as I lack the necessary expertise in this area.

All I know is that to eliminate this freeze in Metal, you need to shift the compilation cost away from the active render loop. If you must compile shaders at runtime, never do it synchronously on your main thread or render thread.

Instead of using the synchronous makeRenderPipelineState(descriptor:), use the asynchronous version device.makeRenderPipelineState(descriptor: pipelineDescriptor). You will need a fallback shader or skip drawing that object until the completion handler returns the compiled pipeline state. Is that possible on your workflow?

When Metal sees the archive, pipeline creation becomes nearly instantaneous because it bypasses the compiler entirely.

There are strategies to make sure to avoid that freeze.

https://developer.apple.com/documentation/metal/mtlbinaryarchivedescriptor

https://developer.apple.com/documentation/metal/creating-binary-archives-from-device-built-pipeline-state-objects

You are in the right path! Congratulations on your new MacBook M3. Looks like you are having fun with it!

Albert
  Worldwide Developer Relations.