5 ms·

Why is this enforced by a policy rather than code? Why aren't "private APIs" even accessible for third party apps? (I guess what I'm asking: why hasn't a secur

Why is this enforced by a policy rather than code? Why aren't "private APIs" even accessible for third party apps? (I guess what I'm asking: why hasn't a security mechanism been built in the language/linker/OS for this purpose?)

userbinator 11y ago
Do we really need more "security mechanisms" just because people might find something they could do which you didn't expect, but is actually useful for them and allows them to do what they want? A bit of a philosophical point, but I don't think it's a good thing at all if everything anyone ever did required explicit approval from some entity. Then again, I don't get the culture of strict conformance around iOS (and Apple in general) either...
- masklinn 11y ago
  > Then again, I don't get the culture of strict conformance around iOS (and Apple in general) either… Really? You don't get why apple would want to avoid software unexpectedly breaking on every OS update (on user devices, to widespread cries of "Apple broke software X") because the dev used an undocumented and unsupported private API which was modified or removed entirely?
  - jessaustin 11y ago
    The current situation is one in which things are breaking, right? Why do they want things to break now rather than in some hypothetical future?
    - masklinn 11y ago
      > The current situation is one in which things are breaking, right? No, the situation posted about is one where developers get their application rejected, nothing is broken. > Why do they want things to break now rather than in some hypothetical future? 1. breakage in private APIs is absolutely not hypothetical 2. rejecting submission is a very different (and much milder) issue than applications breaking on end-user systems
    - rileymat2 11y ago
      It is breaking for the developers, not the end users.
    - xoa 11y ago
      No, the current situation is that developers are finding their updates are being rejected. Because they're being rejected right now while the apps are still being actively maintained, there is a vastly higher likelihood that (as you see happening right here) it'll get immediately noticed and effort expended to resolve it by switching to stable public APIs. In contrast, if they continued to use private APIs then the app's future failure point becomes entirely unpredictable. The entire point of private vs public isn't security or arbitrary conformance or whatever per se, but rather flexibility. Apple wants to be able to alter internal implementation details as their needs dictate, or feels that a given API is not yet one they're comfortable committing to maintaining intact long term. That means it may get changed not merely in a major OS update but even in a maintenance update. What if everything breaks in iOS 11.2.3 a couple of years from now? Will all of these apps actually still be maintained? Will their developers even still be in business at all? Users would have zero warning, it wouldn't even necessarily happen on a major update where incompatibilities might be more expected. ObjC (and other dynamic languages) cannot enforce "private" in code, and on OS X there is a long history of private API use, which probably is part of what drove Apple's decisions here. I've used private APIs there myself, at times in the history of its development it's been the only way to accomplish some really cool stuff. But it was absolutely fragile and also resulted in a lot of things that'd break later if not actively maintained, either when Apple removed it entirely or conversely stabilized it and baked it into public APIs/frameworks. Apple wants to be able to maintain an aggressive OS upgrade schedule and simultaneously have apps continue to work even if they're from many versions back and are no longer actively maintained (which is an important part of getting most people to upgrade). Requiring App Store software to stick to public APIs is one reasonable way to work toward those goals given their constraints.
      - masklinn 11y ago
        > it'll get immediately noticed and effort expended to resolve it by switching to stable public APIs. FWIW there may not be a public API for what they're trying to do. > ObjC (and other dynamic languages) cannot enforce "private" in code Even if they could, a root issue here is that it's a UI views tree (so it's possible to access any subview by traversing the views tree), to fix that you'd need to wrap any non-public view object in some sort of opaque view adapter/proxy to prevent anyone getting a handle on them, which would be hard to enforce and would have a runtime cost. Once you've got a handle on it, unless the language has neither reflection nor unsafe observation (e.g. digging through the vtable directly) your private API is toast.
    - fixermark 11y ago
      Pushing off the breakage to the hypothetical future is how you end up with the Win32 API---Microsoft actually had to go and reverse-engineer their own (C++-implemented) classes into C structs because apps like Photoshop were digging through private structures to squeak a bit of performance out of the system that the APIs didn't directly allow for. When changes in the C++ implicit rules changed the layout of the structures the compiler made, big-name apps would break and Microsoft got into a state where they couldn't release a new OS without "breaking Photoshop." Apple would rather not be shackled to popular developers cracking open their design to do things that are forwards-incompatible.
    - blkhp19 11y ago
      Absolutely wrong. Nothing is breaking. Apple simply rejected an app / an update to give the developer a chance to fix the issue that could break at some point in the future.
    - st3v3r 11y ago
      Because if they break now, before the app is published, then the developer can fix it. Once people have published apps with private api use, it becomes extremely difficult to change those private apis.
- realusername 11y ago
  The problem of doing this is you end-up with something like the Win32 API, with decade of undocumented methods people called that you must support 10 years after because some critical applications are crashing.
  - jowiar 11y ago
    One of the best things about the iOS ecosystem is that people actually update their OS. This allows Apple to add new features, and developers can then develop for them knowing the user base isn't hanging back due to maintaining comparability with legacy code (witness how long it took IE6 to die).
  - asveikau 11y ago
    It's amusing to me that people defending very restrictive development frameworks will often talk as if any easement of the policy is a slippery slope to Windows 98. There is no middle ground! Can't do that because PCs sucked in the 90s! (Also implicitly ignores that NT based Windows got a lot better.)
masklinn 11y ago
Because widget hierarchies are naturally traversable, and objective-c is a dynamically typed language.
LeoNatan25 11y ago
The nature of dynamic language such as Objective C.
- masklinn 11y ago
  Most static language wouldn't help any. Were it java, you could traverse the widgets tree as done here, then use reflection to call whatever method you want once you reached the widget you wanted.
  - lmm 11y ago
    Java is an exception since it was designed to run untrusted bytecode. The Security Manager controls access to reflection and could easily be configured to disallow doing that.
afoxtron 11y ago
You may be misunderstanding the usage of the word "private". It doesn't mean that these APIs are obfuscated from developers, it's just that they are only meant to be used internally by frameworks created by Apple. Using them directly can result in all kinds of unforeseen behavior because they were never meant to be instantiated or called by arbitrary objects.

userbinator 11y ago

Do we really need more "security mechanisms" just because people might find something they could do which you didn't expect, but is actually useful for them and allows them to do what they want? A bit of a philosophical point, but I don't think it's a good thing at all if everything anyone ever did required explicit approval from some entity. Then again, I don't get the culture of strict conformance around iOS (and Apple in general) either...

masklinn 11y ago
> Then again, I don't get the culture of strict conformance around iOS (and Apple in general) either… Really? You don't get why apple would want to avoid software unexpectedly breaking on every OS update (on user devices, to widespread cries of "Apple broke software X") because the dev used an undocumented and unsupported private API which was modified or removed entirely?
- jessaustin 11y ago
  The current situation is one in which things are breaking, right? Why do they want things to break now rather than in some hypothetical future?
  - masklinn 11y ago
    > The current situation is one in which things are breaking, right? No, the situation posted about is one where developers get their application rejected, nothing is broken. > Why do they want things to break now rather than in some hypothetical future? 1. breakage in private APIs is absolutely not hypothetical 2. rejecting submission is a very different (and much milder) issue than applications breaking on end-user systems
  - rileymat2 11y ago
    It is breaking for the developers, not the end users.
  - xoa 11y ago
    No, the current situation is that developers are finding their updates are being rejected. Because they're being rejected right now while the apps are still being actively maintained, there is a vastly higher likelihood that (as you see happening right here) it'll get immediately noticed and effort expended to resolve it by switching to stable public APIs. In contrast, if they continued to use private APIs then the app's future failure point becomes entirely unpredictable. The entire point of private vs public isn't security or arbitrary conformance or whatever per se, but rather flexibility. Apple wants to be able to alter internal implementation details as their needs dictate, or feels that a given API is not yet one they're comfortable committing to maintaining intact long term. That means it may get changed not merely in a major OS update but even in a maintenance update. What if everything breaks in iOS 11.2.3 a couple of years from now? Will all of these apps actually still be maintained? Will their developers even still be in business at all? Users would have zero warning, it wouldn't even necessarily happen on a major update where incompatibilities might be more expected. ObjC (and other dynamic languages) cannot enforce "private" in code, and on OS X there is a long history of private API use, which probably is part of what drove Apple's decisions here. I've used private APIs there myself, at times in the history of its development it's been the only way to accomplish some really cool stuff. But it was absolutely fragile and also resulted in a lot of things that'd break later if not actively maintained, either when Apple removed it entirely or conversely stabilized it and baked it into public APIs/frameworks. Apple wants to be able to maintain an aggressive OS upgrade schedule and simultaneously have apps continue to work even if they're from many versions back and are no longer actively maintained (which is an important part of getting most people to upgrade). Requiring App Store software to stick to public APIs is one reasonable way to work toward those goals given their constraints.
    - masklinn 11y ago
      > it'll get immediately noticed and effort expended to resolve it by switching to stable public APIs. FWIW there may not be a public API for what they're trying to do. > ObjC (and other dynamic languages) cannot enforce "private" in code Even if they could, a root issue here is that it's a UI views tree (so it's possible to access any subview by traversing the views tree), to fix that you'd need to wrap any non-public view object in some sort of opaque view adapter/proxy to prevent anyone getting a handle on them, which would be hard to enforce and would have a runtime cost. Once you've got a handle on it, unless the language has neither reflection nor unsafe observation (e.g. digging through the vtable directly) your private API is toast.
  - fixermark 11y ago
    Pushing off the breakage to the hypothetical future is how you end up with the Win32 API---Microsoft actually had to go and reverse-engineer their own (C++-implemented) classes into C structs because apps like Photoshop were digging through private structures to squeak a bit of performance out of the system that the APIs didn't directly allow for. When changes in the C++ implicit rules changed the layout of the structures the compiler made, big-name apps would break and Microsoft got into a state where they couldn't release a new OS without "breaking Photoshop." Apple would rather not be shackled to popular developers cracking open their design to do things that are forwards-incompatible.
  - blkhp19 11y ago
    Absolutely wrong. Nothing is breaking. Apple simply rejected an app / an update to give the developer a chance to fix the issue that could break at some point in the future.
  - st3v3r 11y ago
    Because if they break now, before the app is published, then the developer can fix it. Once people have published apps with private api use, it becomes extremely difficult to change those private apis.
realusername 11y ago
The problem of doing this is you end-up with something like the Win32 API, with decade of undocumented methods people called that you must support 10 years after because some critical applications are crashing.
- jowiar 11y ago
  One of the best things about the iOS ecosystem is that people actually update their OS. This allows Apple to add new features, and developers can then develop for them knowing the user base isn't hanging back due to maintaining comparability with legacy code (witness how long it took IE6 to die).
- asveikau 11y ago
  It's amusing to me that people defending very restrictive development frameworks will often talk as if any easement of the policy is a slippery slope to Windows 98. There is no middle ground! Can't do that because PCs sucked in the 90s! (Also implicitly ignores that NT based Windows got a lot better.)

masklinn 11y ago

Because widget hierarchies are naturally traversable, and objective-c is a dynamically typed language.

LeoNatan25 11y ago

The nature of dynamic language such as Objective C.

masklinn 11y ago
Most static language wouldn't help any. Were it java, you could traverse the widgets tree as done here, then use reflection to call whatever method you want once you reached the widget you wanted.
- lmm 11y ago
  Java is an exception since it was designed to run untrusted bytecode. The Security Manager controls access to reflection and could easily be configured to disallow doing that.

afoxtron 11y ago

You may be misunderstanding the usage of the word "private". It doesn't mean that these APIs are obfuscated from developers, it's just that they are only meant to be used internally by frameworks created by Apple. Using them directly can result in all kinds of unforeseen behavior because they were never meant to be instantiated or called by arbitrary objects.