Bottom Tab Bar Under the iPhone Home Indicator
A field-service company built a Mobile App (MABS) in OutSystems 11. The app has a bottom tab bar with four tabs on phones and a left side menu on tablets. The developer used the LayoutSideMenu block, set it to show a hamburger, and added a Container with Style Classes bottom-bar fixed at the bottom. The bar is 56 px tall and has z-index: 100. The main list has padding-bottom: 0. On an iPhone 14 Pro, the tab bar sits under the home indicator, and the last list row cannot be tapped. On a Pixel 6 the same build is fine. A floating action button (FAB) is 56x56 px, positioned bottom: 16px; right: 16px, and it covers the third tab. On iPad, the design requires the left menu, but the bottom bar still appears because the CSS only uses max-width: 600px.
1. Explain the iPhone-only overlap and the CSS/layout changes needed to make the bottom bar and scroll content respect the safe area.
Read the worked answer
The iPhone has a home-indicator safe area at the bottom that is roughly 34 px in portrait. A fixed bar at bottom: 0 is laid out against the visual viewport edge and sits in that area. The Pixel has no equivalent inset, which is why the bug is device-specific rather than a general layout bug.
The fix has two parts. First, the web view must be allowed to extend into the safe area; in a custom layout this means the viewport meta must include viewport-fit=cover. Second, the bar must absorb the inset: padding-bottom: env(safe-area-inset-bottom); and its height must become calc(56px + env(safe-area-inset-bottom)), or the bar keeps 56 px of visible content plus the inset. The scroll container needs matching bottom padding, for example padding-bottom: calc(56px + env(safe-area-inset-bottom));, otherwise the final row still sits behind the bar even after the bar itself is raised. Do not hardcode 34 px, because the inset changes with orientation and device.
2. How would you show bottom tabs on phones and a side menu on tablets without duplicating the screen or its logic?
Read the worked answer
Keep one screen and one set of logic. Put the bottom tab bar and the side menu in the same LayoutBlank-based layout, each wrapped in a Container with a visibility class. Use CSS media queries to switch them: the bottom bar is hidden at min-width: 768px, and the side menu is hidden below that width. This keeps the screen's aggregates, client variables and actions in one place. Avoid branching on JavaScript device detection at OnReady, because the first paint then shows the wrong navigation and then swaps it, which is a visible flash and can break deep links.
If the side menu must be a real LayoutSideMenu block on tablet, wrap that block in a Container that is hidden on phone, and put the custom bottom bar in a separate Container hidden on tablet and up. Both can coexist in the same layout without rendering two screens. Test at the exact breakpoint and in landscape, because tablet landscape widths can cross the breakpoint.
3. What is wrong with the FAB positioning, and what touch-target and stacking checks would you apply?
Read the worked answer
The FAB is positioned relative to the viewport bottom, not relative to the tab bar. At bottom: 16px it occupies the same vertical band as the 56 px bar and covers the third tab. Move it above the bar: bottom: calc(56px + env(safe-area-inset-bottom) + 16px); and keep right: 16px. Check z-index separately: the FAB must be above page content but must not sit above modal overlays or the tab bar's active state. Give the bar and the FAB explicit stacking contexts rather than relying on source order.
For touch targets, 56x56 px is acceptable, but verify the tappable element is the button itself and not a small icon inside it. Ensure at least 44x44 px of actual hit area and at least 8 px of separation from the tab bar so a thumb does not hit both. Test with the iPhone inset and with Android gesture navigation, where the system inset may be smaller but still present.