9 Things UI Designers Should Keep in Mind for iPhone Design

Apple shipped its biggest visual redesign since iOS 7 launched in 2013, and if your mental model of iPhone design still centers on the notch, you're designing for a device that hasn't shipped since 2018. iOS 26, released in 2025, introduced Liquid Glass, a translucent, light-refracting material system that changed how nearly every control, navigation bar, and floating element looks and behaves across the entire Apple ecosystem simultaneously, iOS, iPadOS, macOS, watchOS, and tvOS. That's the actual design conversation happening right now, and it's worth understanding properly rather than working from what was current a decade ago.

Here's what genuinely matters for anyone designing for iPhone in 2026, grounded in Apple's current Human Interface Guidelines rather than the design language of a discontinued phone.

1. Design with Liquid Glass, not against it

Liquid Glass is Apple's biggest visual overhaul in over a decade, and it's not a coat of paint, it's a fundamentally different material logic underlying the whole interface. Controls now behave as a distinct, translucent functional layer that floats above your content, reflecting and refracting whatever's beneath it, rather than sitting as opaque, fixed bars. This is Apple's long-standing principle of Deference, the interface should serve the content and never compete with it, taken to its logical conclusion: the UI chrome itself becomes semi-transparent, letting the actual content show through even while remaining fully readable and usable.

Practically, this changes concrete decisions you'll make constantly. Tab bars are now inset from the screen edges rather than running flush, typically 21 points from the left, right, and bottom, presented in a horizontal Liquid Glass capsule rather than a solid bar. Search, when present, often appears as its own separate circular "island" of Liquid Glass off to the side, positioned for easier one-handed reach rather than buried inside a larger bar. Content scrolling beneath a tab bar fades out progressively as it approaches the edge, reinforcing the sense of depth and layering rather than an abrupt cutoff.

If you're building custom app icons, Apple now recommends using Icon Composer, a dedicated tool that lets your icon pick up system-level lighting effects, light mode and dark mode variants, lit edges, and even subtle parallax as the device tilts, consistent with how Liquid Glass behaves system-wide. An icon built as a flat, static image will look visibly out of step with the rest of the operating system now, in a way that wasn't true even two years ago.

2. The Dynamic Island is infrastructure now, not a novelty

The physical notch the original iPhone X shipped with is long gone from Apple's current design language, replaced by the Dynamic Island starting with the iPhone 14 Pro in 2022 and standard across the current lineup. It's worth understanding as a genuinely different kind of interface element, not just a reshaped cutout: it expands and contracts to show live, contextual information, and it's meant to be actively designed for, not merely tolerated as a hardware obstruction.

The primary use case worth building for deliberately is Live Activities, real-time, glanceable updates for genuinely time-bound events: delivery tracking, sports scores in progress, an active workout, a timer counting down. These display directly in the Dynamic Island and on the Lock Screen without requiring the user to open your app, and they need to handle interruption gracefully, saving state and pausing cleanly when the app moves to the background rather than losing the user's place. If your app has any feature with a genuine real-time or countdown component, this is worth building for specifically rather than defaulting to a plain push notification, since it's a meaningfully more native, more polished way to keep a user informed.

Apple is explicit that the Dynamic Island, like the home indicator before it, should never be hidden or covered by app content. Treat it as a permanent, protected zone in every layout, not an occasional obstacle to design around.

3. Safe areas: what actually needs protecting now

Safe area guidance has moved well past "avoid the notch." The current safe area needs to account for the status bar, the Dynamic Island, the home indicator at the bottom of the screen, and, with Liquid Glass's floating, inset navigation elements, a somewhat more complex set of protected zones than a single rectangular cutout at the top of the screen.

The practical rule is simple to state and easy to violate carelessly: never place interactive or essential content under the status bar, Dynamic Island, or home indicator. In SwiftUI, this means relying on automatic safe area handling by default rather than reaching for .ignoresSafeArea() on anything containing text or interactive controls, that modifier is appropriate only for background fills, decorative images, or full-bleed visual elements, never for content a user actually needs to read or tap. A surprising number of otherwise polished apps still ship with a button or a label quietly clipped behind the home indicator because a developer applied that modifier too broadly, and it's one of the fastest ways to make an app feel unpolished even when everything else about it is well built.

Standard content margins now run 16 to 20 points from the screen edges, with spacing generally built in increments of 8, 16, and 24 points, worth knowing as a baseline rather than guessing at arbitrary padding values on every screen.

4. Touch targets, and the real cost of getting them wrong

This isn't a matter of taste, it's backed by real, specific research: touch targets smaller than Apple's 44x44 point minimum produce tap error rates of 25 percent or higher, and that error rate disproportionately affects users with motor impairments, who are exactly the population accessibility guidelines exist to protect. A button, icon, or link below this size isn't a minor aesthetic compromise, it's a measurable, quantified source of user frustration and mis-taps that shows up directly in your own analytics as rage-taps and abandoned flows, even if nobody on your team can immediately articulate why.

Design primary actions, the ones a user needs most often, toward the bottom of the screen, where a thumb naturally rests during one-handed use, and reserve the top of the screen for secondary actions and navigation a user reaches less frequently or reaches with their other hand. This single placement decision has an outsized effect on how an app actually feels to hold and use, far more than most visual polish does.

5. Typography and Dynamic Type aren't optional extras

Apple's interface typography runs on the San Francisco font family, specifically engineered for legibility across every one of Apple's screen types and pixel densities, and it's paired with Dynamic Type, the system that lets a user scale text size according to their own preference or accessibility need, up to genuinely large accessibility sizes far beyond a "large" setting in most other software.

The mistake worth avoiding explicitly: hardcoding font sizes instead of using Dynamic Type's built-in text styles. Body text defaults to 17 points and Large Title to 34 points at standard settings, but the actual point is that these values need to scale correctly when a user increases their text size, and every layout needs to reflow gracefully at those larger sizes rather than truncating essential content. Test your actual layouts at the largest accessibility text size available, not just the default, since that's where most real typography bugs in production apps actually surface, cramped layouts, truncated labels, buttons that overflow their containers.

6. Accessibility is a mandatory design input, not a QA checklist

This deserves to be stated plainly: accessibility isn't an ethical nice-to-have layered on at the end of a project, it's a first-class design requirement Apple treats as central to app review, and over a billion people worldwide live with some form of disability that these features directly serve. Beyond that population specifically, accessible design measurably benefits everyone, larger text helps anyone reading in bright sunlight, and well-structured VoiceOver support helps a sighted user driving or otherwise unable to look at their screen.

The concrete requirements worth building in from the start rather than retrofitting: full VoiceOver support, with every interactive element carrying a real, descriptive accessibility label ("Add to cart, large blue sneaker" rather than the unhelpful default of "Button"). A minimum color contrast ratio of 4.5:1 for body text against its background, dropping to 3:1 for large text, checked in both light and dark mode, not just whichever one your design team happened to be looking at. Full Dynamic Type support at every accessibility size, covered above. And respecting the system's Reduced Motion setting for any app that uses meaningful animation or transitions, since motion that feels like a nice flourish to one user can cause genuine discomfort for another.

Retrofitting accessibility after a product is largely built is dramatically more expensive and less thorough than designing it in from the first wireframe, and it's exactly the kind of foundational work best planned alongside a genuine UI design partner from day one rather than treated as a post-launch compliance pass.

7. Follow Apple's actual navigation conventions, or pay for it in App Store review

Apple's Human Interface Guidelines aren't abstract suggestions open to loose interpretation, they translate into specific, observable choices that both App Store reviewers and real users notice within seconds of opening an app. A few conventions worth following deliberately rather than reinventing:

Use tab bars for top-level navigation, not hamburger menus. Hamburger menus hide navigation behind an extra tap and measurably reduce feature discoverability, by as much as 50 percent in some analysis, compared to a visible tab bar. If your app has five or fewer top-level destinations, and most apps genuinely do, a tab bar showing them directly is both more discoverable and more consistent with what iPhone users already expect from every other app they use.

Don't break standard gestures. If a user can swipe from the left edge to go back on one screen, that same gesture needs to work consistently across every applicable screen in your app. This is a specific, well-documented reviewer flag, replacing the standard back button with a custom one that breaks swipe-back navigation, and it's an unforced, easily avoidable error.

Use SF Symbols with actual semantic accuracy, Apple's library of thousands of icons that align optically with the system typeface across every weight and size. Using the standard trash icon for delete, rather than a custom icon that looks similar but isn't quite the system convention, isn't pedantry, it's what lets users recognize a function instantly based on years of consistent exposure across every other app on their phone.

Give every modal a genuine, obvious dismiss path. A sheet or modal with no visible close button, cancel option, or swipe-down gesture traps a user, and stacking multiple modals on top of each other compounds that confusion badly. If a flow needs several steps, keep them within a single modal's navigation stack rather than presenting sheet on top of sheet.

8. Dark mode is a first-class mode, not an inverted afterthought

Treating dark mode as a simple color inversion applied after the fact is one of the more common, more visible mistakes still shipping in production apps. Apple's semantic color system, systemBlue, systemRed, systemGreen, and the rest, exists specifically so colors adapt automatically and correctly between light and dark appearances while preserving the visual hierarchy your design actually depends on. Using hardcoded hex values instead of these semantic colors is how an app ends up genuinely broken in one mode or the other, illegible text, invisible buttons, a hierarchy that simply stops making sense.

Dark mode also isn't purely a straight inversion of your light palette. Accent colors generally need slightly lower brightness and higher saturation in dark mode to read correctly and stay visually prominent against a dark background, and it's worth genuinely previewing both modes throughout development rather than designing exclusively in light mode and hoping the automatic inversion holds up.

9. Design for the whole device family, not just the phone in your hand

Apple's adaptivity guidelines exist specifically so a well-built layout adjusts automatically to new screen sizes, a new iPhone, an iPad Pro, and to newer interface features like interactive widgets or the Dynamic Island, without requiring a redesign every time Apple ships new hardware. Relying on Apple's standard system components, rather than heavily custom-built ones, is what actually delivers this adaptivity for free: system components handle Dynamic Type scaling, appearance switching, and future platform changes automatically, while custom components require ongoing, manual work to keep pace with every new OS release indefinitely.

It's also worth having at least a working awareness of visionOS and spatial computing design guidance, now a genuine part of Apple's current HIG alongside iOS, iPadOS, and macOS. Even for teams with no immediate plans to build for Vision Pro specifically, understanding how Apple is extending concepts like depth and Liquid Glass into a spatial context helps clarify why those same principles show up the way they do in the current iPhone interface, since Apple is visibly designing these platforms as one coherent, connected system rather than isolated products.

A practical note on navigating the HIG itself

Apple's own documentation is genuinely large and, by most designers' own account, not the easiest reference to browse casually. It's organized into four layers worth knowing about explicitly: Foundations (the broad philosophy, Clarity, Deference, and Depth), Patterns (how those principles apply to common interaction types), Components (specifications for individual UI elements like buttons, tab bars, and sheets), and Technologies (platform-specific capabilities like Live Activities or widgets). Missing the Technologies section specifically is a common, avoidable mistake, it's entirely possible to build a Live Activity that looks and functions correctly in isolation but displays incorrectly once it actually reaches the Dynamic Island, because the platform-specific presentation rules live in a section separate from the general component guidance.

Working from Apple's own Figma library for iOS, which ships official, current system components rather than approximations, considerably reduces the risk of small inconsistencies compounding across a real project, and it's worth treating as a starting point rather than something to reference only when a question comes up.

The bottom line

The specific details will keep changing, Apple has shown a clear pattern of significant periodic redesigns, from iOS 7's flat design shift in 2013 to Liquid Glass in 2025, and whatever ships next will supersede some of what's covered here in turn. But the underlying principles worth internalizing are durable: Clarity, Deference, and Depth aren't slogans, they're the actual logic behind why Apple's current interface looks and behaves the way it does, and understanding that logic, rather than just copying the current visual surface, is what lets a design team adapt smoothly to whatever Apple ships next instead of scrambling to catch up each time.

Building genuinely native-feeling iPhone experiences, whether that's a from-scratch app or bringing an existing product current with Liquid Glass and the modern Dynamic Island, takes real, current platform expertise, exactly the kind of specialized knowledge worth expecting from an iOS development partner rather than a general mobile team working from years-old assumptions. And since a growing number of these same adaptive layout, accessibility, and typography principles now extend directly into how Apple expects responsive web experiences to behave on iPhone's Safari browser as well, it's worth treating platform currency as a single, connected discipline rather than something siloed by app versus web.

Frequently Asked Questions

What is Liquid Glass in iOS design? Liquid Glass is Apple's translucent, light-refracting material system introduced with iOS 26 in 2025, described by Apple as its biggest visual redesign since iOS 7 in 2013. It changes how navigation bars, tab bars, and floating controls look and behave across iOS, iPadOS, macOS, watchOS, and tvOS, with UI elements now behaving as a distinct, semi-transparent layer floating above app content rather than solid, opaque bars.

Is the iPhone notch still relevant to UI design in 2026? No. The physical notch was replaced by the Dynamic Island starting with the iPhone 14 Pro in 2022, and it's now standard across Apple's current lineup. The Dynamic Island is a fundamentally different, more capable interactive element that expands to show live content like Live Activities, rather than a static cutout designers simply had to design around.

What are the minimum touch target and contrast requirements for iOS apps? Touch targets must be at least 44x44 points, since smaller targets produce tap error rates of 25 percent or higher, particularly affecting users with motor impairments. Text contrast must meet a minimum ratio of 4.5:1 for body text and 3:1 for large text against its background, checked in both light and dark mode.

Do iOS apps really need full accessibility support, or is it optional? It's effectively mandatory, both because Apple's App Store review process weighs it heavily and because it directly affects a very large population, over a billion people worldwide live with some form of disability. Core requirements include full VoiceOver support with descriptive labels on every interactive element, Dynamic Type support at all accessibility sizes, adequate color contrast, and respecting the system's Reduced Motion setting.

Should I use hamburger menus in an iPhone app? Generally no. Apple's convention is a visible tab bar for top-level navigation, and hamburger menus, which hide navigation behind an extra tap, measurably reduce feature discoverability by as much as 50 percent compared to a visible tab bar. If your app has five or fewer top-level sections, a standard tab bar is both more discoverable and more consistent with what iPhone users expect from other apps.

How is dark mode supposed to work in a well-built iOS app? Through Apple's semantic color system, colors like systemBlue and systemRed that automatically adapt between light and dark appearances while preserving visual hierarchy, rather than hardcoded hex values that often break or become illegible in one mode. Accent colors typically need slightly lower brightness and higher saturation in dark mode to remain visually prominent, and both modes should be genuinely previewed throughout development rather than designed for light mode alone.