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?

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..! :)