Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Gusar View Post
    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.
    Apple deserves being blasted for not supporting Vulkan to begin with. I get the point of some API not having stability guarantees, but banning applications for using such APIs is not an appropriate solution, it's Apple solution. And they deserve being criticized for doing that, instead of providing what's needed to support Vulkan better.

    Comment


    • #32
      Originally posted by shmerl View Post
      Apple deserves being blasted for not supporting Vulkan to begin with.
      Yes, but that's not what this thread is about. This isn't about Vulkan or MoltenVK. It's about use of private APIs and all applications are affected, not just those wanting to use MoltenVK.

      Originally posted by shmerl View Post
      I get the point of some API not having stability guarantees, but banning applications for using such APIs is not an appropriate solution, it's Apple solution. And they deserve being criticized for doing that, instead of providing what's needed to support Vulkan better.
      Banning such applications actually is appropriate. Private vs public APIs is not an Apple thing, like I said, it exists everywhere. Using private APIs is bad, it will lead to your application starting to crash or outright cease to work at some point. I get that sometimes you may not have a choice because the public API is lacking, or the private API is simply so much more convenient to use, but it's private for a reason and Apple clamping down on the use of private APIs is not something they deserve being blasted for.


      Originally posted by Weasel View Post
      Undocumented is not the same thing as private. You described undocumented APIs. A private method in C++ is a completely different thing.
      The meaning of "private" in C++ is specific to C++, it has no relation to the context of private vs. public API, which is a concept that isn't tied to one specific language.

      Originally posted by Weasel View Post
      You're using weird words and then wonder why nobody understands you.
      No, he's actually spot on, nothing weird about his words.
      Last edited by Gusar; 08 July 2018, 02:41 PM.

      Comment


      • #33
        Originally posted by natbro View Post
        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.
        Why's the GLSL step necessary there, btw?

        Comment


        • #34
          Why an Unity3d game needs moltenvk when Unity3d supports metal in a native way? This makes no sense at all.

          Comment


          • #35
            Originally posted by Gusar View Post
            I get that sometimes you may not have a choice because the public API is lacking, or the private API is simply so much more convenient to use, but it's private for a reason and Apple clamping down on the use of private APIs is not something they deserve being blasted for
            Since it's not a theoretical case, but quite practical case of Apple banning lock-in removal option, the regular excuse of "private APIs are bad" won't fly. Apple could easily provide Vulkan to begin with or work with MoltenVK developers to make more of their APIs which were needed for Vulkan implementation public. They did neither of that, so I see it as an anti-competitive move, simply masked under usual "private APIs are bad". When you deal with someone with as rotten reputation as Apple's, many normal excuses are pointless in the face of their control abuse. And Apple have only themselves to blame for that.
            Last edited by shmerl; 08 July 2018, 02:49 PM.

            Comment


            • #36
              Originally posted by shmerl View Post
              Since it's not a theoretical case, but quite practical case of Apple banning lock-in removal option, the regular excuse of "private APIs are bad" won't fly.
              Again, it's not MoltenVK that's being banned, it's *everything* using private APIs.

              Originally posted by shmerl View Post
              Apple could easily provide Vulkan to begin with or work with MoltenVK developers to make more of their APIs public that needed for Vulkan implementation.
              You're still seeing this as a Vulkan/MoltenVK issue. It's not. This isn't a specific attack on MoltenVK by Apple.

              Originally posted by shmerl View Post
              They did neither of that, so I see it as an anti-competitive move, simply masked under usual "private APIs are bad".
              If they targeted specifically MoltenVK, you'd have a point. But they're not. The MoltenVK devs need to figure out how to make it work without the use of private APIs and it'll be allowed again.
              Last edited by Gusar; 08 July 2018, 02:51 PM.

              Comment


              • #37
                Originally posted by Gusar View Post
                You're still seeing this as a Vulkan/MoltenVK issue. It's not. This isn't a specific attack on MoltenVK by Apple.
                It de-facto is, since it's MoltenVK that's using those APIs, and application is just using MoltenVK. It is a direct attack on MoltenVK in practice, no matter what their real intent is. If Apple will fix this situation - I'll agree with you that it wasn't deliberate. If Apple will say - MoltenVK developers should figure it out using current crippled public API - I'd stay with my opinion that it's a deliberate attack.

                Comment


                • #38
                  Originally posted by Weasel View Post
                  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.
                  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!). It's really bad form to use private APIs in a 3rd party library, whether it's an open source library or not. Doing so either causes your garbage to break at a later date, or hamstrings the library developer if they attempt to maintain compatibility.

                  Comment


                  • #39
                    Originally posted by shmerl View Post
                    It de-facto is, since it's MoltenVK that's using those APIs, and application is just using MoltenVK.
                    Again, other applications is being hit as well, not specifically those that use MoltenVK.

                    Originally posted by shmerl View Post
                    It is a direct attack on MoltenVK in practice, no matter what their real intent is.
                    Yeah, no. That's your anti-Apple bias showing. You want to think they have something against MoltenVK. But that's not the case, there is no indication anywhere that MoltenVK is on their radar.

                    Originally posted by shmerl View Post
                    If Apple will fix this situation - I'll agree with you that it wasn't deliberate. If Apple will say - MoltenVK developers should figure it out using current crippled public API - I'd stay with my opinion that it's a deliberate attack.
                    There is nothing for Apple to fix, private APIs are private for a reason. And you don't know if the public API is crippled, that's again your anti-Apple bias showing. Could be it'll be a simple adjustment on the MoltenVK side.

                    Comment


                    • #40
                      Originally posted by Gusar View Post
                      And you don't know if the public API is crippled
                      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.
                      Last edited by shmerl; 08 July 2018, 03:27 PM.

                      Comment

                      Working...
                      X