3 ms·

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 bei

by 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
  This would not be the first time I've seen a "Can't get there from here" issue in Apple's API design (once upon a time, we tried to render from one process's pixel buffer directly into another process's window prior to 10.6, only to discover that was basically not supported; we got around it by flushing the pixels to a memory-mapped file and then flushing them to the window on the receiving side). Unfortunately, that's part of the nature of working within Apple's ecosystem---you want store support, you play by their rules. Their rules don't allow your app to exist, you sit on your hands and wait 'til they do. The benefit gained is a bit of consistency of experience on the user's side.
- xoa 11y ago
  >FWIW there may not be a public API for what they're trying to do. Of course, I didn't say they'd still be able to accomplish the same thing, after all that's the most common reason one would be interested in using private APIs in the first place. On Mac OS X (as it was back then rather then "OS X") for example at one point there was no good public API for menu bar extras. Apple wanted everyone to use the NSStatusBar API but it was vastly less capable then the private version Apple used, so naturally the latter was rapidly reverse engineered and a whole ecosystem quickly developed. There was actually a bit of an arms race for a while, a preface perhaps to the current iOS situation, because with Jaguar (10.2) Apple added new code specifically to attempt to force the exclusion of all 3rd party menu extras. Apple wised up about that later and just accepted that a bleeding edge would exist, but they were pretty sensitive even very early on to worries that crashing or bugs in 3rd party software that took down soemthing major (like the entire SystemUIServer) would have a major negative effect on perception and adoption of Mac OS X on the whole. Presumably at least some that attitude in turn dates all the way back to the stability horror story that was classic Mac OS in the later years in particular. On the Mac it was futile and pissed off devs and power users, the block was broken before Jaguar was even GM'd, but it's something they've clearly never entirely forgotten and now under iOS they're using their control to enforce it. Even if functionality is only possible with a private API in the present OS release they'd rather an app be forced to use less but be more sure that it'll work at all in the long term.

by xoa 11y ago

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
This would not be the first time I've seen a "Can't get there from here" issue in Apple's API design (once upon a time, we tried to render from one process's pixel buffer directly into another process's window prior to 10.6, only to discover that was basically not supported; we got around it by flushing the pixels to a memory-mapped file and then flushing them to the window on the receiving side). Unfortunately, that's part of the nature of working within Apple's ecosystem---you want store support, you play by their rules. Their rules don't allow your app to exist, you sit on your hands and wait 'til they do. The benefit gained is a bit of consistency of experience on the user's side.
xoa 11y ago
>FWIW there may not be a public API for what they're trying to do. Of course, I didn't say they'd still be able to accomplish the same thing, after all that's the most common reason one would be interested in using private APIs in the first place. On Mac OS X (as it was back then rather then "OS X") for example at one point there was no good public API for menu bar extras. Apple wanted everyone to use the NSStatusBar API but it was vastly less capable then the private version Apple used, so naturally the latter was rapidly reverse engineered and a whole ecosystem quickly developed. There was actually a bit of an arms race for a while, a preface perhaps to the current iOS situation, because with Jaguar (10.2) Apple added new code specifically to attempt to force the exclusion of all 3rd party menu extras. Apple wised up about that later and just accepted that a bleeding edge would exist, but they were pretty sensitive even very early on to worries that crashing or bugs in 3rd party software that took down soemthing major (like the entire SystemUIServer) would have a major negative effect on perception and adoption of Mac OS X on the whole. Presumably at least some that attitude in turn dates all the way back to the stability horror story that was classic Mac OS in the later years in particular. On the Mac it was futile and pissed off devs and power users, the block was broken before Jaguar was even GM'd, but it's something they've clearly never entirely forgotten and now under iOS they're using their control to enforce it. Even if functionality is only possible with a private API in the present OS release they'd rather an app be forced to use less but be more sure that it'll work at all in the long term.