There is an API for developers to use to signal that a view should hide the home indicator [1]. It doesn't guarantee that it will be hidden (the user may have accessibility or other options enabled which take precedence and prefer to display it)

When playing fullscreen video on my phone, I do not see the home indicator, as it hides after a short delay due to most developers adopting this API. Just tested in VLC and the home indicator is hidden after about 3 seconds of fullscreen video playback

[1] https://developer.apple.com/documentation/uikit/uiviewcontro...

It’s much more problematic on iPad Pro, since lots of devs don’t have one. It’s also geometrically larger, especially in landscape.

Getting app developers to fix it is a very mixed bag. One app I use a lot (F1 TV) had had this issue forever, and many many many people have complained to F1 Media about it. They don’t care, apparently, and that’s a high end app that costs upwards of $80/yr

Also, erm, Safari. I was actually complaining about this (with a screenshot) just yesterday: https://news.ycombinator.com/context?id=33770571

As stated in my sibling[0] to your comment, the developer may have limited ability to fix it, since its a preference the system will often override. That said, its literally a one line change to implement it (for each view controller class), so there is little reason for them not to put it in, even with its limited effectiveness.

[0] https://news.ycombinator.com/item?id=33781895

This is not the behaviour I am seeing as I compile to my iOS devices right now. The home indicator is consistently hidden on view controllers which adopt this preference, but will reappear whenever a user interacts with the application, only to hide again after a few seconds.

I agree that it can be annoying if the developer of an app does not adopt the correct behaviours. But in the case of Safari we should not be allowing web developers to hide persistent OS UI elements. The better solution to your screenshot, I think, is to design with safe areas[1] in mind so that the overlap does not occur and persistent OS UI remains accessible.

[1] https://webkit.org/blog/7929/designing-websites-for-iphone-x...

But why on earth does it NEED to be persistent?

It’s instinctual behavior.

Like imagine if a desktop pc had 3 dime sized dots on the bottom of the screen to remind you a mouse has 3 buttons.

It’s noise, not signal.

It wasn't instinctual when iOS introduced the swipe up to close apps in 2018?

It's also a clear indication that you can swipe up to go home. If the indicator is invisible, you cannot swipe up. You need to interact with the app to make the indicator appear (eg. tap the screen). I appreciate the visual indicator and that it can be disabled when there is full screen content

False. Swiping up in the YouTube app with the bar hidden goes home just fine.

You're right. I confused two APIs, there is also `defersSystemGestures(on: edges)` which allows an app to prevent a swipe to go home initially. A lot of fullscreen apps do this so I thought it was the same API

> It doesn't guarantee that it will be hidden (the user may have accessibility or other options enabled which take precedence and prefer to display it)

In my experience as an iOS developer using this API, the only time the preference to hide the home indicator is respected is in the case you mentioned, when a full screen video is playing. Otherwise the home indicator always appears whenever the user stops interacting with the screen. So the GP is correct that there is no user control to make it hidden, and not really any developer control either.

It consistently hides the home indicator in my experience.

I just compiled two of my apps with `prefersHomeIndicatorAutoHidden` set to true. This resulted in the home indicator disappearing after a second or two on the view controllers where it was configured. Neither of the apps were video apps.

The home indicator does come back if you interact with the screen. Tap the screen and it will appear briefly, before disappearing again.