Modern iOS Navigation Patterns

Not to beat a dead horse, but the use of these patterns is one of the many reasons Apollo was so much better than Reddit&#x27;s official app. Consistent navigation, consistent gestures, consistent behaviors.<p>And it&#x27;s not like these concepts are hard, you just have to care enough to follow them. It&#x27;s really disheartening to see how many apps don&#x27;t.

When I see &quot;iOS Navigation Patterns&quot; I cringe. There are no patterns and it&#x27;s one of the worst things (there are many) when comparing to Android. Going back on Android is easy, and back can mean multiple things. On iOS that I&#x27;ve been using over a year I just blindly try one of the two back &quot;patterns&quot;, then look for buttons in an unreachable places. And even that sometimes doesn&#x27;t work.<p>Don&#x27;t let developers use patterns, fix it on OS level. Developers don&#x27;t want you to leave parts of their app - try doing back action on Instagram reels for example.

I’m not sure if this is related enough or not, but here goes:<p>On Mac and now iPadOS (<a href="https:&#x2F;&#x2F;useyourloaf.com&#x2F;blog&#x2F;ipad-customizable-toolbars&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;useyourloaf.com&#x2F;blog&#x2F;ipad-customizable-toolbars&#x2F;</a>), the built-in toolbar control supports a high degree of customization. You can try this in Finder, among many other native apps.<p>Powerful built-in widgets are an underappreciated aspect of the Mac desktop, and something I worry about with SwiftUI taking over. They’re also a huge win for iOS, but less so because it is so common for apps to want to put their own spin on the design.<p>Anyway, am I crazy, or did iOS apps used to support customizing tab bars out of the box? While clearly different from toolbars, supporting editing the order (and which are actually displayed) of tabs felt like the spiritual equivalent of built-in toolbar customization. And I haven’t seen it in years.<p>According to doc it is still there, but does anyone know of apps still using this pattern? <a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;uikit&#x2F;uitabbarcontroller#1653016" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;uikit&#x2F;uitabbarcont...</a><p>Anyway, tab bars are cool also because that is what is used by Apple TV in most apps I’ve used, and the consistent experience is wonderful.

On the first entry:<p>&gt;<i>Drill-down navigation is stateless</i><p>I&#x27;ve been encountering this a lot lately, but: this seems the opposite to me, it&#x27;s <i>deeply</i> stateful as screen N depends on what you did before, and you can go back to it. It literally keeps track of some internal state in order to be useful at all, i.e. the list contents depend on state N-1, because if it didn&#x27;t it would be awful.<p>A stateless UI would be, like, a one-step modal. It exists or it doesn&#x27;t. Particularly strongly &quot;stateless&quot; if it&#x27;s transient and you have no way to &quot;resume&quot; it.<p>I&#x27;ve been in and around quite a few discussions using the term &quot;stateful&quot; to mean WILDLY different things through the years, and in a giant burst lately, and it has largely led me to conclude that almost nobody agrees with anyone else what it means and few are aware of this.<p>What does &quot;stateful UI&quot; mean to you all? I find the variation <i>fascinating</i>.

One inexact wording here I noticed: &quot;Swiping right from the left edge of the screen does the same as pressing the Back button.&quot; If you&#x27;re implementing that yourself, it&#x27;s important it&#x27;s not a swipe gesture, it&#x27;s an edge pan gesture. It has to be an interactive, cancellable pan that follows your finger, or it just feels wrong.

This is such a good resource for folks like me who struggle with the visual aspect of software. The diagrams and clear explanations are just excellent.

Frank Rausch created the best Wikipedia app ever, &quot;V for Wiki&quot;*<p>So when he speaks about iOS design and UX, I&#x27;m inclined to listen.<p>-----<p>* <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20211223231349&#x2F;https:&#x2F;&#x2F;v-for-wiki.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20211223231349&#x2F;https:&#x2F;&#x2F;v-for-wik...</a>

&gt; Swiping right from the left edge of the screen does the same as pressing the Back button.<p>Wish you could disable that, so common horizontal scrolling in web pages that don&#x27;t fit activates the Back function

iOS does this reasonably well<p>&gt; A typical iOS application has a fixed architecture-often a hierarchical tree with multiple levels. This rigid struc- ture makes navigation options pre- dictable. Structural navigation pat- terns give users confidence about where they came from, where they are in the hierarchy, and how to navi- gate back to where they came from.<p>whereas on Android, sometimes the &#x27;Back&#x27; gesture lands you on the previous page and sometimes it completely closes the app. it&#x27;s so inconsistent that I dropped 12 years of using Android and switched to iOS.

When I first started developing for the iPhone (back when they first released the official SDKs) Apple were really hot on their Human Interface Guidelines and had really good documentation on what made a good UI along with standard patterns to follow.<p>That seemed to completely vanish when they went with the &quot;flat&quot; design - mainly I think because none of it made sense anymore. They went from very clear:<p>- make sure the user interaction is obvious<p>to<p>- this might be clickable, or it might be some text or maybe it&#x27;s a long press...

This site itself is really nice to read and easy to understand. I wish Apple&#x27;s docs looked as nice and were as easy to read as this.

I recently moved from iphone se to a later iphone without a home button, the user experience is so much worse. I accidentally take screenshots all the time and find it slower to navigate back to the home screen.

Are there any good app examples of what Frank says here?<p>&quot;A step-by-step sequence should be contained in a modal overlay for presentation to emphasize that the Back button in this context serves a different purpose than in a hierarchical drill-down.<p>The step-by-step process is usually completed with a Done or Close button, which also closes the containing modal.<p>The sequence can have a variable number of steps and different paths depending on the options selected.&quot;

I&#x27;m dead excited for 2040 when SwiftUI can handle all of these patterns natively.<p>And, maybe for 2043 when our n-3 OS target will let us support them in our app.

I always turn the button navigation on for Android phones on setup. Only gestures are terrible navigation.

Btw, does anybody know the proper way to quit home screen “Search” in iOS? Currently I swipe up to close the keyboard and then tap the empty space at the bottom of the search screen. Seemed like a bug the first time.

I like the presentation, it&#x27;s understandable and well-structured.<p>From what I can see, Apple&#x27;s guidelines look really similar to what Google suggests for Android apps - the only really big difference is visual presentation.

The Home Screen actually uses the pyramid pattern and not the hub and spoke.<p>You can swipe between apps using the black bar at the bottom.

I love the design of that page. Very clean and informative. Very visual. Well done!

This sets off my alarm bells big time:<p>&gt;High-Friction Modal<p>&gt;A decision is required to dismiss them: A decision whether to save state, whether to confirm (by tapping Done) or to destroy (by tapping Cancel) the data you’ve entered on a form.<p>&gt;Low-Friction Modal<p>&gt;They are easy to dismiss: “Low friction” means not having to think about how to get back.<p>&#x27;CANCEL&#x27; ON A PROMPT IS NEVER, EVER DESTRUCTIVE. This is a huge red flag for the author&#x27;s understanding of UI conventions. &quot;Cancel&quot; must always be safe. &quot;Cancel&quot; is the low-friction no-thinking way to dismiss a prompt. It should dismiss the prompt, and <i>do nothing else</i>.<p>Corollary to this is that you should avoid putting a &quot;Cancel&quot; button on a full-blown input interface that will throw away user data if dismissed (regardless of whether you have decided to embed said interface in a modal). If you do, you at least need a &quot;are you sure&quot; prompt <i>with a cancel button</i> (hence why you avoid using the word &#x27;cancel&#x27; redundantly on the original form).

Next, try addressing why they change all the time, and seemingly for no reason. It&#x27;s infuriating.<p>The latest inexplicable, surprise change happened when my Apple Watch updated overnight, I went to open control center the next morning to locate my phone which I had misplaced, and .... it wouldn&#x27;t open. For 10 minutes I fiddled with this fucking thing, thinking I was going senile at one point, only to find out that Apple moved the control center trigger to the side (power) button, and swipe from below now does something completely different. No warning, no announcement, no nothing, and no way to revert to the old behavior which existed for years. Imagine walking into your car one morning and the operation of the pedals was suddenly reversed due to an automatic software update because some geekaroid at the car manufacturer thought it was a good idea.<p>At this point I&#x27;m convinced they are making changes as a means to justify their existence. If I ran that company the project managers responsible for these breaking changes - and yes, unannounced UI changes are breaking changes - would all be fired.

The entire article can be summarized into one word: trees.<p>Anyway, this is the sort of information that you must absolutely consume from a direct source, i.e. Apple documentation and Human Interface Guidelines, because they change a lot and secondary sources can be outdated or flat out wrong at any given point in time. Additionally, your mental model of the UI must correspond with Apple’s implementations of its UI frameworks (if this is targeted at designers, well the problem of design that is detached from engineering is a separate and long discussion, though very real and so widespread as to be the norm).