Apple Doubling Down on Blocking Private API Use
Rumor has it, that Apple is recently pushing to double down on eliminating any and every use of private API.
I’m convinced that this is ill-fated and hurts the platform as a whole. Users get worse experiences, developers worse products, Apple a worse platform.
Disclaimer: Of course, the use of private API is something to avoid at all costs. And it’s good that Apple is pushing for the discontinuation of its use.
But occasionally, it’s the last resort to solve certain problems. Problems that affect UX and totally should be addressed.
[…]
But as developer of apps, we need to ship things. Even if the issue was fixed now, apps should be as bug-free as possible on all the OS’es. iOS 11 is still the public release.
So… we need a solution. Let’s look at our options here.
[…]
1) Leave as-is, file radar, hope for eventual fix.
Results in bad experience for some users. They are not able to use the app because of a certain title. That’s a bug. Bad idea.
(There even is an app review guideline against bugs. More in a moment.)
2) Do not set a custom back title.
This leads to worse user experience – because we are no longer able to provide better context than what’s the default.
While this is a small example, take a dozen of them and you have a worse app. You get a worse experience for users.
[…]
5) Switch to non-native cross-platform toolkit.
I know this is radical. But you’re free to do whatever you want there. Style the UI with some CSS or something and no need for private API.
But IMO nobody will want to use your app. Bad idea. Native wins. UIKit is the one to use.
[…]
Know what? In my one and a half decades as professional app developer, all my apps broke in some way on every single new OS that came out.
Staring with Mac OS X 10.2, continuing to iOS 12 today.
But absolutely zero of these breaks were caused by the use of private API.
Pretty much the same in the last ~25 years or so. Incidentally, NeXTStep releases tended to not break things. System updates were downright boring.
I guess the issue for Apple is that not all developers are appropriately cautious about using private API responsibly. I would lean toward a policy of allowing private API use but not worrying about breaking the (non-existent) contract between releases. That provides an incentive to only use it as a last resort. As to the argument that private API lets apps do things and access data that they shouldn’t be able to do, those cases should be treated as OS bugs because App Review can’t guarantee that they will not be used, anyway.
Long-term, I expect that Swift will make it harder for developers to access private API, which will lead to more problems like Seelemann describes. Banning a workaround doesn’t make the original problem go away.
Along similar lines, Ash Furrow:
Apple’s stubborn refusal to provide a simple API to determine if you’re on an iPhone X causes developers to check for hardcoded screen dimensions, which is worse than developers making device-specific layouts.
Update (2018-07-27): See also: Open Radar.
1 Comment RSS · Twitter
• not worrying about breaking the (non-existent) contract between releases
Unfortunately they can't actually do that. If a sufficiently important third-party app is broken, Apple has to code around it, even if it isn't Apple's fault. That's true for other kinds of issues too, not just private API, of course.
