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.
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.
The back button has a title, because it gives users context. “Where am I?”
And it can be changed to allow providing *better* context. E.g. in cases where the default title is imprecise or misleading.
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.)
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.
I guess you could manually figure when which case would be triggered. But this is bound to break with the next best OS update. Spacing and layout change. Fonts change. Hacks break.
Take a dozen of these cases and you have a fragile, hacky app.
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.
1) Buggy UI
2) Inferior UX
3) Hacky Code
4) Private API
5) Horrible UI
If you were *free* to choose – what would you do?
I know *my* option. The mindset behind it got us an Apple Design Award. Make your guess.
- users get worse experiences,
- developers get worse products,
- Apple gets lower quality apps on its platforms.
Everybody looses. Nobody wins.
(Thanks for reading until here, I’m almost done. Just one more thing…)
I believe they hope for a more stable platform. Internal APIs can change any time, and their use might break apps. If a change broke a lot of apps, it would turn into *Apple’s* problem.
Of course Apple will want to kill this off. I’m all for it. Kill it.
But there must be room for exceptions.
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.
- Use it only as a LAST resort
- Use it only for cases of bad UX
- Always protect against change
We usually have lower standards when “bending” public API. (That’s actually why apps break.)
I’d like Apple to reconsider this direction. Bugs are a *reality* in software development. We must all live and deal with them.