Thread by @macguru17

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.

(Long thread)

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.

I just stumbled at a simple enough example that I’d like to use to illustrate this. This one is specific to UINavigationItem’s backBarButtonItem – but there are *plenty* of examples like this.

Here’s a screenshot of an app that uses a custom back button title from user content.

As things are with user-created content, you have no control over them. So users may happen to enter very long titles. Let’s look at a longer back button title…

Oops. The layout is completely broken. See that the action buttons are gone. Because of a user title? A clear bug.

Funnily enough, this has not always been the case. See this screenshot for a comparison of iOS 10, 11, and 12 (b3).

It was not a problem on iOS 10, the title would get hidden and replaced by a generic short string. That’s a very good handling of this case.

This is *not* about this bug.

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.

In fact, iOS 11/12 still has this behavior, if you’re NOT using the backBarButtonItem … but if e.g. the parent view controller happens to have a very long title.

It’s still there. It’s intended (and good!) behavior. But setting a backBarButtonItem is broken beyond usability.

Quick reminder: When looking for solutions, we always consider *motivation*.

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.

So… options.

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.

3) Hack your way around it.

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.

4) Use private API that fixes the problem.

Turns out, UINavigationItem has a private “backButtonTitle” property. Setting this instead of a button item does the job. Good on all versions! (image)

Best possible experience, but now you are using private API. Which is bad, isnt it?

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.

So what are we left with?

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.

With these options left:

- 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…)

Here is what Apple/App Review tells you at the moment:

- You must not ship bugs.
- You must not use private API.

So they leave you with shipping inferior experiences or hacky applications or even push for cross-platform SDKs. This is why I call it ill-fated.

Why is Apple pushing so hard against private API? I have no insights, I can only guess.

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.

Also, private API might provide apps illegal access to data that they must not use. E.g. circumventing sandbox restrictions, or tracking users across apps, etc.

Of course Apple will want to kill this off. I’m all for it. Kill it.

But there must be room for exceptions.

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.

So why is that? Have we ever used private API in the past, we stuck to some clear rules:

- 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.)

To sum it up: IMO, strictly and relentlessly forbidding any private API use is ill-fated. It hurts users, developers and the platform.

I’d like Apple to reconsider this direction. Bugs are a *reality* in software development. We must all live and deal with them.

(The End)

PS: The radar for this issue here is rdar://problem/42326772

Likely UINavigationController even, as you’d want all those nice push/pop interactive swipe gestures to work as well.

https://twitter.com/al45tair/status/1019557997822074880