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

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

    Originally posted by cybertraveler View Post
    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.
    Last edited by Weasel; 07-08-2018, 11:42 AM.

    Comment


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

      Comment


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

        Comment


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

          Comment


          • #25
            Originally posted by cybertraveler View Post

            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.

            Comment


            • #26
              What a great deal of confusion. TMI it seems.
              Basically, stop treating this as apple v app. It's apple v moltenvk.

              https://www.theregister.co.uk/2017/0...ward_openness/

              Read this it's easier. And it all is rather confusing.
              Last edited by bofh80; 07-08-2018, 01:37 PM.

              Comment


              • #27
                Same issue for xamarin-macios ? https://github.com/xamarin/xamarin-macios/issues/4257

                Comment


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

                  Comment


                  • #29
                    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
                    Last edited by Xaero_Vincent; 07-08-2018, 01:49 PM.

                    Comment


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

                      Comment

                      Working...
                      X