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

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


    • #42
      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; 07-08-2018, 03:27 PM.

      Comment


      • #43
        Originally posted by shmerl View Post
        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.

        Originally posted by shmerl View Post
        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.
        Last edited by Gusar; 07-08-2018, 03:44 PM.

        Comment


        • #44
          Originally posted by shmerl View Post
          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.

          Comment


          • #45
            Originally posted by randomsalad View Post
            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.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


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

              Comment


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

                Comment


                • #48
                  Originally posted by brrrrttttt View Post
                  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.

                  Comment


                  • #49
                    Originally posted by Weasel View Post
                    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...

                    Comment


                    • #50
                      Originally posted by Weasel View Post
                      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.
                      Last edited by smitty3268; 07-09-2018, 12:57 AM.

                      Comment

                      Working...
                      X