Apple Rejects iOS App For Using MoltenVK Vulkan, Alleged Non-Public API

[Gusar]

There wouldn't be a reason for MoltenVK to use the private one, if public would have been sufficient.

You don't know that. Could be accidental use of the private API, could be the devs didn't know about another option that does already exist, could be adjusting MoltenVK to remove the use of the private API will not have consequences functionality and/or performance wise. You're just going for the worst case scenario because you want to, because it gives you a reason to bash Apple.

And yes, I'm OK with not giving Apple the benefit of a doubt. It's not a fair situation to begin with. MoltenVK is working around a crooked lock-in situation, so my bias is quite natural to have here.

Again, this isn't about Vulkan/MoltenVK! Yes, Apple deserves blasting for not supporting Vulkan, no one will disagree with you there. But this particular thing here isn't about that. You're basically beating a straw man.

[randomsalad]

There wouldn't be a reason for MoltenVK to use the private one, if public would have been sufficient. And yes, I'm OK with not giving Apple the benefit of a doubt. It's not a fair situation to begin with. MoltenVK is working around a crooked lock-in situation, so my bias is quite natural to have here. Apple created it.

But going by what natbro said earlier in the thread (assuming he is who he says he is) then this was supposedly a mistake on the MoltenVK devs part that isn't actually used by MoltenVK but was left in by mistake.
And if you ask me, it's unfair to expect Apple (or any other provider of a public API that happens to have hidden private API functions also) to accept and support the use of these in 3rd party apps. If MoltenVK can't do what it does without relying on private API functions, then that's a problem with the MoltenVK implementation.

[Michael]

But going by what natbro said earlier in the thread (assuming he is who he says he is)

It is Nat Brown of Valve Software I can confirm and was already forwarded the developer's information for being able to work-through/confirm the situation.

[LaeMing]

Definitely not a fan of Apple, but in this case I assume they are trying to avoid the situation MS ended up in where (allegedly) 60%+ of Win2k* convoluted core-OS code was supporting abused (and log-since obsolete) private API calls so that badly-written popular programs would keep working.

*I haven't seen a claimed statistic for any more recent version.

[STiAT]

If MoltenVK uses internal structures or APIs, for me that's a plausible reason for a ban. Internal APIs and structures can change on updates, and possibly break things. To control that from a standpoint of user experience after upgrades is understandable.

I hope that MoltenVK finds ways around that. They don't seem to have an easy go on certain functionality with MacOS. Let's hope they succeed.

[Weasel]

You are a long way out of your depth here I'm sorry to say. Private API is for internal use only, with no stability guarantees. The documentation is typically also kept private to reduce the chance of anybody external using them, but that's not in any way a requirement (if they are documented, they need to be explicitly marked private!).

APIs with public documentation are "public APIs". Private API is a poor choice of words since it conflicts with the C++ keyword (which actually makes sense in this context, you can have private methods/functions in a class) and I've never heard of it before.

Granted I come from Windows (then Linux) background where "Undocumented" or "Internal" are the only terms used, never once seen this "private API" wording used, so it's just Apple being confusing.

[brrrrttttt]

APIs with public documentation are "public APIs". Private API is a poor choice of words since it conflicts with the C++ keyword (which actually makes sense in this context, you can have private methods/functions in a class) and I've never heard of it before.

Granted I come from Windows (then Linux) background where "Undocumented" or "Internal" are the only terms used, never once seen this "private API" wording used, so it's just Apple being confusing.

It's most definitely NOT an Apple thing. The Linux kernel has a private API, Qt has a private API etc, Microsoft has private APIs...

[smitty3268]

APIs with public documentation are "public APIs". Private API is a poor choice of words since it conflicts with the C++ keyword (which actually makes sense in this context, you can have private methods/functions in a class) and I've never heard of it before.

Granted I come from Windows (then Linux) background where "Undocumented" or "Internal" are the only terms used, never once seen this "private API" wording used, so it's just Apple being confusing.

"Private API" vs public is a very generic and commonly used term in software architecture. It has nothing to do with Apple or Microsoft. Or C++ or any other language. It's pretty basic terminology used across the entire industry.

[mike44]

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 ([email protected]) 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.

Thanks for the clarification.

[V1tol]

https://github.com/KhronosGroup/Molt...KImage.mm#L328
There is the line that caused rejection. Just read the comment about. It is deprecated (even Clang warning is disabled) and states about interprocess communication which does not exist for iOS. MoltenVK developers just need to remove that flag for iOS and that's it.