3 ms·
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 develo
by interpol_p 4y ago
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/ https://webkit.org/blog/7929/designing-websites-for-iphone-x...
- TylerE 4y agoBut 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.
- interpol_p 4y agoIt 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
- TylerE 4y agoFalse. Swiping up in the YouTube app with the bar hidden goes home just fine.
- interpol_p 4y agoYou'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