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

[Weasel]

Re first sentence: to understand this you need to understand the difference between a public API and private method, functions and data structures. It's obvious from what you've said that you don't understand this difference.

There is actually no difference at the binary level. What is different, however, is the intent. Private methods *might* break, but that's solely up to Apple's discretion. You know, they could just as well break a public method if they wanted to...

But what really matters here is that the private methods are probably undocumented, not "private". And using undocumented stuff is kind of bad since they might break.

However it still makes no sense to ban MoltenVK, it's absurd in fact. An app could theoretically static link it and not even claim it's using MoltenVK but directly Metal, what would Apple do then? See the hypocrisy.

re first sentence: I really don't get your point. Proprietary APIs often expose features that open APIs don't. Or the proprietary API has some performance benefit. Sometimes proprietary APIs are created simply because the existing open APIs / standards are insufficient for their needs and they want to rapidly innovate unrestricted by any existing standards.

So why hasn't Microsoft open-sourced DirectX versions (maybe not 12, since it's the latest) yet? I mean they're not even working on them anymore (DX9, DX11, etc) so they don't gain any benefit of "exposing new features".

Don't be so naive.

[cybertraveler]

There is actually no difference at the binary level. What is different, however, is the intent. Private methods *might* break, but that's solely up to Apple's discretion. You know, they could just as well break a public method if they wanted to...

But what really matters here is that the private methods are probably undocumented, not "private". And using undocumented stuff is kind of bad since they might break.

However it still makes no sense to ban MoltenVK, it's absurd in fact. An app could theoretically static link it and not even claim it's using MoltenVK but directly Metal, what would Apple do then? See the hypocrisy.

You can't of read my earlier post. Either that or your trolling.

Last time:

It's plausible that MoltenVK is using private functions, methods or data structures and thus Apple are banning apps that are using MoltenVK because of that. This would be a wise thing for Apple to do in order to stop so many apps braking when iOS is updated. Obviously it's extremely bad for users if apps brake during updates. Considering how many novice users use apple stuff, many of them may even stop updating which will expose them to security issues.

Apple will like change many of these private functions, methods and data structures during an update in a non-backwards compatible way: why wouldn't they... it's private.

I'm unsubbing from this thread. There's way too many people talking about about stuff they don't understand and just using this thread as an opportunity to bash and even call for state violence against a company. It's horrible.

[R41N3R]

One more reason to never ever buy any Apple product again, if there haven't been enough already

[Ronshere]

How is it "not public" if it's open source?

Maybe Khronos used it in a non-public way. There is no mention of the specifics of the application or its use.

[mike44]

I'm unsubbing from this thread. There's way too many people talking about about stuff they don't understand and just using this thread as an opportunity to bash and even call for state violence against a company. It's horrible.

As hobby c++ programmer I don't understand the difference. Could someone explain it easily. Thanks.

[Tomin]

Maybe Khronos used it in a non-public way. There is no mention of the specifics of the application or its use.

MoltenVK is open source. Metal API implementations are not and MoltenVK seems to use some non-public Metal API parts that Apple doesn't want developers to use.

Khronos has nothing to do with this.

[Xaero_Vincent]

Fuck Apple. This is one reason why I never, ever buy anything Apple. The only Apple things I own is an early 90's Mac SE/30 and an 80's Apple IIe. There is actually a class action lawsuit happening over Apple's App Store walled garden approach. API usage restrictions for app development could add fuel to the fire.

https://www.theverge.com/2018/6/20/1...ding-explainer

[Gusar]

How is it "not public" if it's open source?

Private APIs are functions that exist to be used by the operating system itself, but are not to be used by third parties. Because they're for internal use only, these APIs are often not documented and, most importantly, can change without notice - the person changing the API will be changing the rest of the system to go along with the change, but said person obviously can't change third party software.

Public APIs are meant for third party software. They're well documented and have a stability guarantee. If something does change, there is a deprecation period, where the developer will get the message that what they're doing is outdated, but the old functionality will be preserved until the deprecation period is over.


All of you people blasting Apple here - you're doing it because it's fashionable to blast Apple without understanding what's actually going on here. Public vs. private APIs exist everywhere - in the Linux kernel, in Firefox, in ffmpeg, in lots of software that you all are using daily on your systems, regardless of OS. That's how software development works. So please, drop the pitchforks and knee-jerk reactions.

[Weasel]

You can't of read my earlier post. Either that or your trolling.

Last time:

It's plausible that MoltenVK is using private functions, methods or data structures and thus Apple are banning apps that are using MoltenVK because of that. This would be a wise thing for Apple to do in order to stop so many apps braking when iOS is updated. Obviously it's extremely bad for users if apps brake during updates. Considering how many novice users use apple stuff, many of them may even stop updating which will expose them to security issues.

Apple will like change many of these private functions, methods and data structures during an update in a non-backwards compatible way: why wouldn't they... it's private.

I'm unsubbing from this thread. There's way too many people talking about about stuff they don't understand and just using this thread as an opportunity to bash and even call for state violence against a company. It's horrible.

Undocumented is not the same thing as private. You described undocumented APIs. A private method in C++ is a completely different thing.

You're using weird words and then wonder why nobody understands you.

[natbro]

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.