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