Nat Brown from Valve posted a comment on the article:
>I know app rejections and the Apple ecosystem rules can be frustrating and cause a lot of consternation, but in this case I think this is likely a legitimate rejection for using the kIOSurfaceIsGlobal=true flag when creating an IOSurface - Apple documents this as private and not allowed by sandboxed apps on iOS, and there are legitimate security & sandbox reasons to not support IOSurfaces that can be guessed and mapped to a foreign process using IOSurfaceLookup(). It's likely Apple's static analyzer found this during submission. We (Valve) worked to add this type of IOSurface-backed MTLTexture for Vulkan VR support for macOS and I suspect it slipped into the iOS build inadvertently - we don't need that support on iOS (yet? If somebody knows the developer and can point them my way (natb@valvesoftware.com) I'd be happy to figure out if this was the only issue, and I'll create a PR for MoltenVK to drop the global flag out of the iOS build.
>Apple graphics folks I work with are fine with MoltenVK, and many Apple and AMD folks have provided concrete technical feedback to improve the performance of MoltenVK, and we have uncovered bugs in HLSL->GLSL->SPIR-V->MSL together which should help make the entire graphics ecosystem stronger.
That’s a deceptive title. It wasn’t the use of MoltenVK, it was that MoltenVK used non public APIs. It even says in the article:
> We were alerted today by an indie game studio that one of their iOS games is now rejected by Apple over its MoltenVK usage. Specifically, the game was rejected for "non-public API" usage. Apple's rejection letter cites the use of non-public interfaces around IOSurface, which is used directly by MoltenVK.
Yes, this isn’t news at all. Apple has always had a hardline policy when it comes to private API usage. Private APIs are private for a reason — they’re undocumented and often not finished or drastically different from their intended final public form and thus likely to change without notice. If developers were allowed to use them, it’d make major iOS updates much more painful for users than they currently are as the APIs apps rely on would get broken with much greater regularity. That, or Apple faces nightmarish levels of compatibility maintenance, slowing development to a crawl.
If this game used Metal directly with no involvement of MoltenVK at all, it’d still get rejected if it as long as that IOSurface private API is in use. The title is borderline clickbait.
Apples private API scanner also leaves a lot to be desired - I've worked on projects where our clients had their apps rejected due to use of names like "index" (not quite those, but similary generic) for use of "private API". Of course Apple rejected this and refused to communicate.
Yea, I clicked the link, preparing to equip my Leather Armor of Technical Outrage, and after reading the details, this is about as mundane as it gets. Apple doesn't let you release apps that call private APIs. It's been this way since the App Store existed. MoltenVK allegedly calls one of these. The rational next step would be that the game studio or Apple would identify the API in question to the MoltenVK team so they could fix it.
Seems to me you are into promoting conspiracy theories if they confirm your own world view, instead of withholding judgement until more information is available.
The article omitted the critical detail about which private API was used. I have received one of those letters before and they should contain those details. The fact that the article omitted that information makes it sound like they want to start a controversy instead of admitting a library developer probably made an easily remedied mistake. They were hoping for low-information-high-opinion internet audience to drive traffic.
The only level of private API use that Apple will accept is 'none', so this question is at best immaterial. All of the private API use needs to be removed.
Right—they (Molten) might not know which of their API calls is to a private API. Although that’s doubtful—you have to deliberately go out of your way to use a private iOS API, using performSelector: or similar.
The confusing thing about this situation is that the game apparently was developed in Unity 3D, which has a Metal backend for iOS, with a fallback to OpenGL ES for older devices. Unity doesn't have a Vulkan backend for iOS.
2. Developers of MoltenVK found "public" Metal API to be inadequate, and used something that Apple considers not public to implement Vulkan translation.
3. Apple found an excuse to ban usage of MoltenVK under pretense that their non public APIs shouldn't be used.
Surely, Apple could:
1. Provide Vulkan to begin with.
2. Provide public APIs in Metal that are adequate to implement Vulkan.
But doing that would reduce Apple's lock-in, so they are resorting to jerk moves. Apple being Apple.
Apple's opposition to Vulkan is purely political to begin with. Their usual anti-competitive lock-in garbage. So no one will buy their "like all other applications" excuse.
To play the devils advocate, Why should Vulcan propagate their own APIs instead of picking one and porting others to work on top of it? All they are doing is this: https://xkcd.com/927/
Considering they don’t control any platform, they are misguided.
Vulkan was called Mantle before AMD gave it to the open standards group. Mantle existed before Metal and Apple knew it was being made into an open standard before they released Metal.
AMD and Khronos were open about their plans and Apple was/is part of the group.
To answer your question, Khronos are trying to promote an open free API to help developers save time and effort, picking Metal as a closed source and late arrival would be unworkable.
> Why should Vulcan propagate their own APIs instead of picking one and porting others to work on top of it?
I suppose you are asking, why should developers strive to use cross platform API, instead of using Apple's lock-in. The answer is simple - reducing work duplication. It's same reason you'd avoid using ActiveX, Silverlight and Flash and would use standard HTML/JavaScript.
Apple obviously are irritated that someone found a way to break their lock-in, so they are looking for ways to mess things up under some side pretenses.
>I know app rejections and the Apple ecosystem rules can be frustrating and cause a lot of consternation, but in this case I think this is likely a legitimate rejection for using the kIOSurfaceIsGlobal=true flag when creating an IOSurface - Apple documents this as private and not allowed by sandboxed apps on iOS, and there are legitimate security & sandbox reasons to not support IOSurfaces that can be guessed and mapped to a foreign process using IOSurfaceLookup(). It's likely Apple's static analyzer found this during submission. We (Valve) worked to add this type of IOSurface-backed MTLTexture for Vulkan VR support for macOS and I suspect it slipped into the iOS build inadvertently - we don't need that support on iOS (yet? If somebody knows the developer and can point them my way (natb@valvesoftware.com) I'd be happy to figure out if this was the only issue, and I'll create a PR for MoltenVK to drop the global flag out of the iOS build.
>Apple graphics folks I work with are fine with MoltenVK, and many Apple and AMD folks have provided concrete technical feedback to improve the performance of MoltenVK, and we have uncovered bugs in HLSL->GLSL->SPIR-V->MSL together which should help make the entire graphics ecosystem stronger.
https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
So, no. Apple isn't out to get MoltenVK. On the contrary, they have been helping improve it's performance.