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 cybertraveler View Post
    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.

    Comment


    • #32
      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.

      Comment


      • #33
        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


        • #34
          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; 07-08-2018, 02:41 PM.

          Comment


          • #35
            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


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

              Comment


              • #37
                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; 07-08-2018, 02:49 PM.

                Comment


                • #38
                  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; 07-08-2018, 02:51 PM.

                  Comment


                  • #39
                    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


                    • #40
                      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

                      Working...
                      X