Modern iOS Navigation Patterns

When I see "iOS Navigation Patterns" I cringe. There are no patterns and it'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've been using over a year I just blindly try one of the two back "patterns", then look for buttons in an unreachable places. And even that sometimes doesn't work.

Don't let developers use patterns, fix it on OS level. Developers don't want you to leave parts of their app - try doing back action on Instagram reels for example.

Also, why is the back button on iOS all over the place?!

Sometimes it’s on the top left, sometime bottom left, sometimes bottom right, and im sure some apps even place it somewhere else.

On Android there is a dedicated OS back button that is always in reach, when using the phone with one hand.

This is the far superior way of doing this.

The convention is that it's in the top left and that the "swipe rightward from the left edge of the screen" gesture also goes back. Most apps work like this, and it's not actually a problem in my experience. I can't actually remember seeing an app which puts the back button in the bottom right...

With apps which follow the convention, I don't miss a hardware back button (or, as is more common in Android these days, a software back button in an OS-provided bar at the bottom of the screen). Swiping from the left edge of the screen feels pretty good. But Android's approach is probably better at providing a decent UX with terrible apps.

Gesture navigation is the standard in android these days. The OS-provided bar isn't even default on budget oppo or Xiaomi devices.

It's indeed very rare to have this large navigation bar on Android nowadays, I suspect the latest Android doesn't even support it.

Android (14) still supports it, it's in Settings > System > Navigation mode (on Pixel devices, different manufacturers might put it in other menus). I still use it and will keep using it.

Interesting, I had no idea they kept it! That's going to make my life much easier when testing if my apps work with it

Same here; I found the swiping very difficult. I have also had a small number of people ask me how to switch to buttons.

In which apps is this the default? I can't think of a single one where a swipe were used to navigate "back" and "forth". Gestures are everywhere, but never in the capacity of the back button.

What do you mean? Flagship Android phones haven't shipped with a physical back button in years. Gesture navigation has been the norm for quite a while. And it works when apps use that system for its navigation patterns, which in my experience is every app on Android, including 3rd party.

If you enable gesture navigation, swiping from the side of the screen emits a virtual back button press. It's an OS level gesture (that apps can attempt to disable, but that can be overridden by the user). This doesn't require apps to implement anything it they implement normal back button behaviour already.

Several brands have removed button navigation by default. I think you can still enable it in the settings, but the button bar at the bottom of the screen seems to be the exception these days.

Do you use Android with gesture based navigation or with the old style 3 buttons? With gesture based navigation, swiping back is the same as the old back button in any app.

Ah, I see. I haven't used Android in a while.

Then I don't really see what differentiates iOS and Android at all, other than that iOS still usually has the button in the top left.

Im trying the edge swipe thing now again on my iPhone and it’s pretty finicky and i sometimes need 2-3 times to get it right.

So, like in the past, I will dismiss these swipe gestures after a while and revert to hunting for the back button in the end.

Also, lots of apps have their “Done” or “Close” buttons on top, which are equivalent to “back”.

Apple should really enforce some consistency here.

Huh, I don't think I've had to retry the back gesture once, it's always just worked. Are you using a case which makes it hard to access the screen edge or something?

The convention is that it's in the top left [...]

Safari is bottom left.

In the logic of Apple's design patterns, the button on the bottom left doesn't take you back a view. It manipulates the browser view and asks it to go one step back. I'm not saying that this is really the best way to reason about it, but at least it's internally consistent.

As sibling commentor pointed out, the default (and standard) way to go back is a back gesture, there is no button to press anymore. The OS teaches you how to do this with an overlay tutorial. My mom, who is 68, was able to figure this out without any help when she upgraded to a Pixel 4A several years ago.

What is surprising to me is that using a Back button that's at the top of the phone would be acceptable to you. That's definitely the hardest part of the UI to reach one handed, and yet going back in an app is definitely something you should be able to do quickly without having to stretch your fingers to reach it. Perhaps you prefer smaller phones, but those are becoming pretty rare these days.

The convention is that it's in the top left and that the "swipe rightward from the left edge of the screen" gesture also goes back

So what's fun about that is from an iOS developer perspective, this is not always free, and the back gesture itself only works within your own app unless you do additional work. This is probably why you mention

But Android's approach is probably better at providing a decent UX with terrible apps.

As I could imagine the app's back navigation is a factor you must consider when the OS doesn't handle it. It's not a dimension that matters on Android- as all apps are going to play nice within the back gesture system automatically unless they block it intentionally, even if the app isn't particularly good. I cannot recall any app I've come across that actually blocks the back gesture (not even games, remote desktop, Steam Link).

A back button at the top of the screen isn't very usable. I think it kinda makes sense to have it there, but it's not something you should be using as the primary back input.

I don't know what you mean by "the back gesture itself only works within your app". I assume there are cases in Android where one app took you to another app and you can do the back gesture to go back to the app you came from? Anyway, the iOS model is that the back gesture just navigates within the app, and there are other features for navigating between apps. I won't make an argument about which is better, but I don't think iOS's model is obviously much worse.

I thought "swipe rightward from left edge" was usually "open the hidden menu" except in browsers.

No, swiping right from the left edge is pretty much universally "go back". Trying it now, it's true in pretty much every app with a navigation model where "back" makes sense; Mail, Settings, Notes, Bitwarden, Messages, Ivory, Nextcloud, a bunch of banking apps, Files, Signal, Slack, etc etc. If an app has a navigation model where "back" makes sense but swiping rightward from the left edge doesn't go back, I get very surprised; it pretty much never happens. I think Google Maps is the only example I can think of at the moment (and Google is generally impressively bad at following iOS platform conventions in my experience).

I guess Discord is an example of an app where swiping from the left opens a hidden menu, but that "opening the hidden menu" thing can be thought of navigating "back" from the channel view to the server/channel list view. In any case, it's not an example of a situation where there is a "navigate back" option on the screen but swiping from the left edge doesn't trigger it.

What’s worse is that the same apps have the same buttons in different places depending on if you’re on iPhone or iPad. While different form factors have different affordances, this is just bad for muscle memory.

The activity stack experience in Android is probably my favorite part of the system design. It produces a deep consistency that makes navigation effortless.

I really wish this had been built in to iOS in the same way.

The activity stack works across applications, which means a back gesture always brings you back to the screen before it, even when several applications work together on a task.

Don't iOS apps have that small black back icon on the top left that sometimes appears when you open another app?

sometimes is the problem. It's not consistent.

That's just not true.

I had to Google it and I think I've seen this thing in the status bar sometimes on iOS but it's definitely not consistent.

I wasn't even aware it was supposed to be a button

It appears every time you get into an app by clicking a notification while you're in another app, and it's 100% consistent in that context.

It is consistent when the apps are consistent.

But it will not appear if the app opens the webpage as its own View (instead of opening Safari). In that case, there is no button and the user has to hunt for how to go back. And the user has no way of knowing whether an app will open Safari or will open the webpage itself.

iOS requires users to build muscle memory in learning how to use each app. Android requires users to maintain a back stack in their head to remember what came before. Switching between the two is very jarring.

To be fair, captive browsers are also a plague on Android apps. I despise them and especially so if there's no way to turn them off in a particular app.

It appears every time

Would be consistent.

It appears every time [long list of qualifications]

Is inconsistent.

The fact that you had to explain how it works indicates that a bit more consistency might be beneficial.

It is consistent!

I don't remember ever seeing (or noticing) anything like that on ios. Do you have a screenshot?

This is for things like clicking ads in the New York Times. Safari will open, and then at the top left of the screen there will be a "< NY Times" indicator. It's below the clock and above the aA icon in the URL bar.

Not just Safari. Most any two apps that support passing things from one app to the next (e.g. via Share Sheet, or a deep link, or etc.), the next app has a back to first app.

That itty bitty teeny weeny thing? Yeah, it's occasionally there.

Swipe up from the bottom middle edge of the screen to bring that up on ios? Or do you mean something else?

Not that, it's about how you navigate through screens in the same app and in multiple apps. Since the back gesture and back stack is universal and all apps are presenting activities added to the back stack, you can seamlessly move between apps using "intents" which are abstracted messages that multiple apps understand, and even tunnel through an arbitrary number of apps, and back up through each of their screens as if they were all in the same application.

An example of an intent is "can anyone open this PDF file" or "the user wants to pick a file, can any app do that and let me know what they picked?"-- those file pickers could also be from your network browser app, or Dropbox, etc.

And since activities are serializable (well, technically the intents that led to those activities being started), Android can do this without requiring the apps deep in the app stack to be running. It can freeze those apps to reserve resources and restart them at the specific activity when the user returns, if necessary.

iOS does have limited inter-app linking (it's the tiny little back arrow and the previous app name that you'll sometimes see at the very top of the screen), but since back gestures aren't universal, the only reliable way to activate that feature is to tap it, since the app may not even understand back gestures, let alone do the extra work of relinquishing control when their own local back stack is empty.

The Share Menu is the worst. How a human being should figure that out?

If offers:

    * Contacts
    * Applications
    * Vertically
    * Horizontally
    * Other items below.
    * But only after you’ve figured out, that it needs pulled up.
    * It is always placed in a different locations of an app and the icon has nothing to do with “Share” or “Copy/Paste”.

People grown up with smartphones can handle it, as usual you can adapt as long as you weren’t older than 40/50 upon introduction. Most of modern stuff is horribly designed and often unreliable (Hello AppleTV. Can we speak today about changing a WiFi-Password? Why you don’t reboot when I press the ON/OFF-Button? It is needed to workaround bugs).

I have the perfect example. In safari iOS, “Share” is where the “Search in the page” feature is located! Just, why?!

Oh, thank you! Twelve years iPhone user here. Never knew it’s there.

It is also in the URL/search bar, type whatever you want to find on the page instead of a website address and the bottom option will be “On this page”.

I used this option just a couple of times when I desperately needed to find something on the page. Most of the time I’m not sure where that option is, so usually I just google it right before using.

Oh wow, that’s also pretty hidden, I never noticed it

It‘s redundant placement. You can also just use the url box to search the page. Seems like a good pragmatic approach to me.

Could they also introduce some kind of page action menu? Maybe.

How do you search the page via the url box? I don’t see the option

Oh. I’ve always used the URL/search bar. Only your post made me aware that there is also a “Search” hidden in the share-menu.

You can see that it's draggable because there's a drag indicator at the top. That's what the small elongated oval is supposed to indicate.

Hm? I don’t recognize/see a drag indicator. There is a tiny elongated black oval at bottom (like always).

No you're right, I misremembered. It is android that has a drag indicator for bottom sheets

Going back on Android is easy, and back can mean multiple things.

For me, this is one of the worst things about Android. There is zero consistency in what the 'back' button does. Even as a developer this is something I struggle with, what should the back button do in a specific case? Does it go back to the previous screen or does it go back one level in a drill-down navigation (which can sometimes, but not necessarily always, be the same thing).

Sometimes it's up one level in the navigation structure, sometimes it's go to the previous screen. Sometimes it's close a dialog. Sometimes it's even close the application. Depending on the context it could any of these, and it can be unclear which one if multiple could apply. The only way to find out is press the back button and see what happens.

I hate ambiguous user interface elements. When I click on something I'd like to know what action it will trigger.

I disagree, and side with the sibling comments consensus: having switched from Android to iOS this summer, this was the largest friction for me – this and the bad onscreen keyboard, and the buggy text selection (editing URLs is a chore, holding the spacebar to move the cursor is broken when you move too far...)

Also this has always bothered me before switching whenever I used a friend's iPhone for a moment.

The trouble alread begins when some link in Safari opens a 3rd party app.

Sounds weird, but Apple could really learn a lot about UX from Google regarding this "go back" interaction.

It really was a joy how reliable it works even for inception-level nested app interactions.

On iPhone, half of app switches (at least) require me to swipe up or go to the home screen.

And positioning the unreliable sometimes-available back button at the top left has made me drop my phone at least once.

For all that's to like about iOS, "navigation patterns" are not one of them for me.

You can swipe left/right on the very bottom of the screen to switch "back" to apps. The back swipe gesture is for "in app" navigation and is much better than what Android has. The Android back button can do like a million things: dismiss keyboard, go back a page, switch apps, go home, etc. It's a mess.

I'd argue this is a good thing. In Android UX guidelines, the "back" button's "promise" is not that you go back to a specific item, it's that you unwind your most recent action (notably, not unwind state, it's not an "undo" button, just that it unwinds the most recent action).

Apps get to decide what metaphor makes sense for an "action" (maybe it's a page, a screen, a dialog, etc). But users can be confident that the "back" button always takes them "backwards", even if the metaphor various apps use may differ.

Users can feel reasonably safe that the "back" button will take them "back" one 'step' or one 'action' worth, even if the app is using panels instead of pages, or modal dialogs instead of inline alerts

I think the Android approach is: the back button usually does what you want, unless what you want is consistency.

Thoughtfully designed apps tend to set up clear expectations and deliver on them. Thoughtless or malicious apps can be confusing or intentionally mislead.

Sometimes it's up one level in the navigation structure, sometimes it's go to the previous screen

Seems consistent to me?

And iOS is all that plus the ambiguity of the existence, location, and look of the button/action itself.

Small note, most people go back using the gesture navigation for Android now days. It's also consistent in going back a screen normally.

It's analogous to the browser navigation. It's entirely to the app to decide which screens and interactions are part of the navigation tree and which are not.

Not true at all. Read Apple’s HIG it’s all spelled out there. Some apps deviate from this but that isn’t the fault of iOS. Instagram on android is just as bad.

Go to Clock, Sleep|Wake up (yes that's really the label!), click Change, scroll down a bit, click "Edit sleep schedule in health". It opens another app in hyperlink style, which the article recommends against.

A lot of apps deviate constantly from the "blessed" patterns. The result is that as a user new to an app (or update), you have to click and gesture around to see what happens, and probably miss a lot of UI features because of that.

Go to Clock, Sleep|Wake up (yes that's really the label!), click Change, scroll down a bit, click "Edit sleep schedule in health". It opens another app in hyperlink style, which the article recommends against.

Most of the alternatives would be worse for either usability or maintenance, or both:

- don't track sleep in the Health app

- track sleep, don't provide alarms/notifications for the sleep/wake along with the schedule in the health app

- put almost all the UI for Health's sleep/wake in the Clock app instead

- provide almost identical UI in both the clock and health apps

I'm sure there are better implementations of the current UI tho'. E.G still link to the 2nd app, but have it _after_ the normal alarm clock in the vertical/reading order, and use better wording to explain the function and behaviour.

I wonder if they're trying to avoid having Clock ask for permission to read the HealthKit data, which presumably they would have to do in most other possible implementations.

It's the right thing to do, but it shows how broken "hyperlinking" is on iOS: after clicking the button, you get the health app on some specific screen. That screen has a "< Settings" button on the top left, which will obviously take you somewhere unrelated now. Assuming that we somehow recovered from clicking that, in the OS status bar there is a minuscule and ephemeral "< Clock" label, which _does_ take you back to the clock app, but disappears as soon as the user switches applications or to the home screen. However, the screen that took me there in the first place was some kind of "modal" which closed itself when the clock app went into background, so that's also broken.

But here's the key question - were you able to edit your sleep schedule? Do you think other people have been able to edit their sleep schedules?

UI has no 'correct' approach, the only thing that matters is if people can happily use it.

Some apps deviate from this but that isn’t the fault of iOS.

Then I suppose it's the fault of the App Store reviewers. The point is that Android handles the activity stack on the OS level and has much stronger control over what a back button does.

There's this phenomenon where people only notice an interface if they don't like it. There's heaps of well documented and well used patterns in lots of apps in iOS, I think when rplnt says "There's no patterns" he's happily ignoring everything that works.

Don't let developers use patterns, fix it on OS level.

I think Apple hasn't done this because it's not practically possible.

For example, if it's possible to change the content of a view (which it obviously should be), then it's possible to remove all content and and replace it with all new content. If triggered by some user action, this effectively is "going to a new screen". But the OS-level gesture won't work since the developer in question didn't use your proposed OS API call "createNewView", but instead just replaced the content of the current view.

However, Apple could make use of this OS API mandatory in order to pass review. Although I still think there's some subjectivity around what is "a new view" (that I can "go back" from) versus "an existing view with stuff changed" (that I can't "go back" from).

It is very possible to do so that

* There is a dedicated control for going back to a previous view / state, that control is always positioned by the OS in a predefined location, and cannot be removed or disabled.

* The OS automatically does the right thing, that is, navigates to the previous view, unless the developer has jumped through hoops to override this behavior (e.g. to warn about unsaved data).

Android does this, and it's very helpful and natural.

Gesture support on iOS feels natural because it's implemented by the application (?).

On Android back gestures usually aren't 1:1 because they behave like a back button. Swipe and let go, then the back action is executed.

Firefox on desktop Linux has better gestures than Android, namely swiping to the right goes back and swiping to the left goes forward. Firefox on Android doesn't, because the OS treats swiping in either direction as a back-button action.

iOS does this too. It doesn’t mean I can’t override it. And that’s what many, many, many people do. Try using an app made in Unity on iOS or Android. It immediately feels janky.

iOS has many faults, but not being able to go back is not one of them.

A navigation that I'd love to see on Android is swiping right to go forward

That would be quite hard to do without a special case, since the default action of the back button is to pop the current activity off the stack and return you to the prior one. (I know too much about this from trying to add a button in an existing app to do the same thing)

It's a shame it's not available though. It'd be useful for navigating tab history in firefox. (currently, hold down back button and select from menu)

It'd be useful for navigating tab history in firefox. (currently, hold down back button and select from menu)

Can you achieve this in Android Firefox when you don't have the UI back button enabled (because gestures are the default)?

Android's back button gesture isn't handled by the app, and Android currently doesn't have a global "forward" key. I don't think we'll see a forward swipe soon.

I'm also not so sure about the ergonomics of thst approach, I'm sure left-handed people would get annoyed that either their back gesture is now harder to pull off, or their forward gesture is pointing backwards (and doesn't work on right-handed phones).

One of my pet peeves is that there is no universal equivalent of a context menu. There’s long press, there’s the share button that is often used not just for sharing but for all kinds of context-menu-like functions, there are other buttons or hamburger/ellipsis menus, there’s the swipe left/right on an item with additional actions appearing and sometimes a “More…” secondary menu, there’s the text-edit “tap a selection and wait for a second or two for some options to appear”, and so on. The respective menus that may or may not appear also differ in their looks.

The lack of a uniform UI pattern for what is right-click on the desktop already surprised me way back in iPhone OS 3. Long press would have been the obvious choice, and you could have had a uniform context-menu function everywhere. Users would just learn “when in doubt, long-press for any and all additional actions” and wouldn’t have to try different gestures, look into the share menu or other random menu buttons.

The swipe sideways on an item is the worst, i once spent half an hour trying to delete a sleep record in the health app.

Even if you know an action is under swipe, it is often difficult to avoid triggering the default swipe action and to drag just the right amount if you really want to select one of the non-default swipe actions, or conversely (especially on iPad) you may have to drag inconveniently far to trigger the default swipe action. It’s just a bad UI pattern.

It is fixed on the OS level, but some people claim hybrid apps are indistinguishable between native apps. Except every time:

- Swipe LTR (on a LTR locale) does not go back

- The back button's size is exactly as big as it looks, instead of extending quite a bit below it's visible box in the navigation bar

- Swipe LTR (on a LTR locale) does not go back

Do you mean on iOS? Because on Android, both swipe from edge rightward and swipe from edge leftward both mean back when using the default gesture navigation settings, regardless of the RTL/LTR direction of the content or device locale. This is a side effect of the fact that Android does not have a notion of forward. I'm not convinced they should have done this, but eh.

I wasn't sure, I guess books are read from the same side in every culture?

iOS UINavigationController and the SwiftUI equivalent support it by default and it takes effort (or a crappy hybrid implementation) to stop it from working.

Android was, I think, even better in the early days.

It had 4 hardware buttons: back, menu, home and search. They lost menu and search along the way. Sure, they weren't always needed, but they were common enough functions that could warrant dedicated buttons. Now, everything is different and you never know how to popup a menu (hamburger menu? where? or is it a swipe?), even though it is always the same functionally.

Well, the menu and search were always context-dependent from what I remember (ie, on devices that used on-screen buttons as opposed to hardware buttons, they were only present when the app requested them to). This created a situation where the buttons were sort of weirdly sized and bolted onto the side of the standard three button layout. This wasn't ideal- and I don't recall an app that made particularly good use of them.

Now, everything is different and you never know how to popup a menu (hamburger menu? where? or is it a swipe?), even though it is always the same functionally.

Well if it's a hamburger menu than you can see it, and drag out sidebars can be checked with a drag in the middle of the screen (but not from the left edge lest you activate the back gesture), so it's pretty quick to figure out.

However I will nominate the Soundcloud app as the single worst app design I have seen when it comes to menuing. It is absolutely atrocious, and actually uses none of the above options. I'll leave it as an exercise to go try it out if anyone wants to laugh at bad app design (sorry if anyone who worked on it is reading this).

Can you expand on the design sins of the Soundcloud app? I use it a lot and have never noticed anything particularly funky. I'm on iOS.

Escaping an already-playing 30 second YouTube advert on their iOS app may be the most challenging UI experience in the modern era. I've landed on forcefully closing the app, and re-opening it as the only escape.

I generally prefer iOS to Android but man you’re so right. The number of times I’ve had to forcefully close an app (not just YouTube) because I cannot figure out how to go backwards in the UI stack.

Action which I find much more useful than Back is Up. I’m always annoyed when someone hands me their Android to do something and I need to go through 10 screens hitting Back instead of Up. I almost never want Back. I want Up. This is also reflected in my use of Finder on Mac e.g. where I often hit Cmd+Up, but never Cmd+Left.

Back can mean multiple things? That's a good thing? Sheesh. The Android back button as been broken for years.

The worst case of all is when a submenu on the control panel is open, then it doesn't matter if I swipe from the bottom or try the back gesture, I need to click somewhere in the screen to leave this menu.... Inconsistency FTW

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's official app. Consistent navigation, consistent gestures, consistent behaviors.

And it's not like these concepts are hard, you just have to care enough to follow them. It's really disheartening to see how many apps don't.

It’s an absolute shame that Steve Huffman ruined Reddit by way of the destruction of Apollo. I quit Reddit a few years earlier but this was the nail in the coffin.

Apollo is one of the few reasons I shell out the $100/year for an Apple Developer Account.

If someone is even mildly technical I'd recommend going the Sideloadly route for getting Apollo, ad-free/background-play YouTube, ad-free/backgroun-play Twitch, and ad-free Spotify.

Why not pay for Spotify and YouTube Premium?

Why would I?

I can't speak for them but my YouTube experience is in the toilet as of late. I've been a Premium subscriber for years now and they just keep making the apps worse. I can't even turn off shorts anymore. Despite paying for an "ad free experience," they serve me this shit:

* In-feed ads. These include ads for content prominence (preferential placement for creators), articles with link-out, ads for Google products and services like purchasing movies and shows in their store, and ads for Google product features.

* Modal ads in videos which they facilitate. That is, pop-up ads in content.

* Ads for merchandise under the content.

* Ads for paid subscription to channels.

* In-content ads in the form of creator sponsorships. These are becoming egregious.

At this point my experience is infinitely better with another front end which bundles SponsorBlock. Why am I paying for a FAR worse experience on their app? Their family subscription is not cheap where I live.

You can use altstore to sideload those for free, or at least i know you can for uyou+.

I believe there are two large caveats with Altstore. 1) It requires the use of a local "server" to phone home on a weekly basis. That means setting up and running another computer in the home, then configuring a regular check-in. Remote check-in (such as while traveling) sounds even more complicated. 2) There is a limit of three apps.

There is (was?) a sideloadable app called "reprovision" that did the re-signing on your device without needing to do a reinstall every time. Was useful for keeping a jailbreak app on an ipad 6. Worked great as long as I didn't turn the device off for over a week.

Looking forward to the EU's sideloading rules coming in though, so I never have to deal with this.

That’s good to know. spez really dropped a bollock on this.

Fuck u/spez

The recent overhaul of Narwhal for version 2 reworked the entire app to operate pretty close to what Apollo was at its core. It's extremely customizable as well. Their new subscription plan for covering the API costs is pretty fair and would be cheaper than what you are doing here.

I'm glad there's a spiritual successor to Apollo, but it's not entirely about comparing one cost to one cost.

Spotify: $10.99/mo ($132/yr)

YouTube: $13.99/mo ($168/yr)

Twitch: $11.99/mo ($144/yr)

Narwhal: $6/mo ($72/yr)

You'd be right, the $72/yr for Narwhal is less than the $100/yr developer certificate, but with all of the other sideloading opportunities it's no contest w.r.t cost.

I've noticed no change to the subreddits I'm active in. Obviously there was change when everyone was making a fuss, but now that that's died down, it seems like it never happened.

I've noticed some very big changes on my side, especially in terms of quality.

That's actually the reason I'm about to delete my account, the good contributors somehow left.

Interesting that you say that, in my subjective experience the overall quality of submissions and discussions has dropped significantly. I don't have any data about this of course, but the site just doesn't really capture my attention anymore the way it once did, and it's mostly down to the comments just not being an interesting read anymore (for me).

Some folks use a phone for everything. I just can't stand it and have never touched reddit on a phone. But I hate everything web and phone related. It's just too small for me.

I've never seen an app as confusing as the official reddit app, and I consider myself of normal intelligence

I moderate a 30K-member subreddit so I need to be able to use reddit from my phone, but... it's impossible. Everything requires so many actions, I never know where I currently am, it's pure garbage

I’m in the same boat. The UX on Reddit is in the same ballpark as AliExpress’ app.

Since Apollo was shut down, I’ve completely stopped using any Reddit app on my phone. Sink It[1] makes the mobile site tolerable, for cases when I end up on a Reddit thread off the back of a search engine query.

1. https://apps.apple.com/app/sink-it-for-reddit/id6449873635

I made this actually. Such a pleasant surprise to see it mentioned randomly on HN. :)

Happy to listen to any feedback or feature requests you may have.

Yeah, AliExpress' app navigation is on an entire other level. I sometimes get so deep in screens with no way to get back to the Home Screen that either spend a minute hitting the back button like 50 times, or just kill the app and start it again.

thank you for posting that link to Sink It, I never knew about it but it’s a great option to improve reddit after Apollo went away. I also like how you can just auto-redirect to old reddit if you want

Have you tried old.reddit.com?

Moderation via the old interface is problematic, especially if you have custom mod tools and actions set up.

...and old.reddit is not mobile responsive.

ever tried Snapchat ?

That’s the difference between an app that optimizes for being a good app and an app that optimizes for engagement and selling you things.

It’s similar to how supermarkets periodically shuffle around their shelving. Consistency in navigation, gestures, and behaviors allow the user to get what they want and get back out too efficiently.

Case in Point: I really like Costco, but if I ever cancel my membership then it is because of how they seem to reshuffle significant parts of the store every few weeks.

I don't know if they think I will buy more if I run around for fifteen minutes looking for something, but man it's annoying.

They probably think of it as 'increasing engagement'. To me it's just wasting my time.

They probably think of it as 'increasing engagement'. To me it's just wasting my time.

Here you've stated the fundamental truth about the so-called attention economy. The core tenet of it, is that money is made on friction. Attention is a finite resource everyone prefers to conserve for their own needs, therefore it needs to be stolen, so it can be redirected to ads, upsells, and other form of behavior manipulation.

That's why supermarkets are reshuffling stores so frequently. That's why so many websites are full of dark patterns and general annoyances. That's why ergonomics all but disappeared from software. Their inefficiency - wasting your limited lifespan in countless tiny ways - is how they make money.

That's why supermarkets are reshuffling stores so frequently.

Normal supermarkets in the US very rarely do this.

Walmart, Safeway, Whole Foods, HEB and all others I frequently shopped beyond Costco explicitly had very stable layouts.

It was literally a topic of news in my neighborhood when one of them rearranged for a remodel.

That might be for other reasons, because according to a study I've seen, Costco basically runs their stores "at cost" and wants to just make money off of the memberships

(https://minesafetydisclosures.com/blog/2018/6/18/costco, though it's from 5 years ago so things might have changed)

I don't see that happening at all in Germany unless they completely redo the whole store layout. I always know where the stuff I want is (if I had purchased it before). The only consistent pattern we have is expensive stuff is on eye height and the cheaper option is on the bottom.

I mean, if I would have to write curl scrips to access reddit, it would still be a better experience than the official reddit app, it’s not a high bar.

Honestly, I don’t think I could deliberately come up with a worse design.

OpenRed is basically this. It is a reddit app that parses the html instead of using the api so the dev can keep it free. It is a bit buggy but I use this over the official app because you don't get ads or random posts from subs you don't subscribe to.

For the nostalgic folks amongst us with a bit of a hacker spirit, you can apparently side-load Apollo and patch it to use your own reddit api key.

This will hopefully become easier with EU-imposed official side-loading.

Apollo was the best iOS app ever made. RIP.

For mobile browsing of Reddit, I found Sink It, iOS Safari extension, to help clean up the current mobile web version so I’m not struggling with old.reddit which isn’t mobile responsive.

https://gosinkit.com

The official Reddit app is one of the few where I regularly "get lost" and it takes too much mental energy to go back to the main view...and I just force quit and reopen it.

Even on Apollo you can get confused because you can open an infinite amount of layers (subreddits, user profiles, posts) on top of each other. After a few of them it gets very cumbersome to get back to the front page because you have to swipe / press back until you get there.

There probably is a magic gesture which I don't know about.

This sets off my alarm bells big time:

High-Friction Modal

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.

Low-Friction Modal

They are easy to dismiss: “Low friction” means not having to think about how to get back.

'CANCEL' ON A PROMPT IS NEVER, EVER DESTRUCTIVE. This is a huge red flag for the author's understanding of UI conventions. "Cancel" must always be safe. "Cancel" is the low-friction no-thinking way to dismiss a prompt. It should dismiss the prompt, and do nothing else.

Corollary to this is that you should avoid putting a "Cancel" 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 "are you sure" prompt with a cancel button (hence why you avoid using the word 'cancel' redundantly on the original form).

Not 100% sure about cancel vs. stop.

Say I'm creating a new calendar entry. I type a lot of information, then I get to save or cancel. Technically, cancel is safe because I'm not messing up my existing calendar. But all the typing I did (especially on mobile) would be lost. So is cancel really safe? But Stop wouldn't the right choice either...

What do you suggest?

Give the user an option to save it as a draft. Fantastical does this, not sure about Apple's own calendar.

Both apps show a ‘cancel’ button on the ‘add event’ popup, as per this post.

They both then show a ‘discard/keep editing’ prompt, but only fantastical has the extra option of a draft.

But in addition to that — fantastical’s popup isn’t even modal. You can push the sheet down to see and interact with the main calendar.

Unfortunately, fantastical doesn’t show the ‘drag handle’ that Mail and other apps use to show this functionality, so it’s not particularly discoverable.

My understanding is that if the navigation bar style starts with large then it should have the drag indicator.

Label your buttons "Save" and "Discard".

"Save", "Discard" (or "Don't save"), and "Cancel", where "Cancel" does not dismiss the editor.

(This is the three-button close prompt that's been the standard in desktop operating systems since at least the Windows 3.1 era, but I guess we have to rediscover these things when the same problems come up on mobile.)

That pattern makes more sense when you are A. Editing a document, as opposed to filling out an ephemeral form; and B. The document does not auto-save. This pattern is more likely on desktop, which is where you're getting the correlation from. It's unnecessarily complicated when filling out something that appears in a modal like the article is referring to, e.g. a calendar event.

Technically, cancel is safe

No, it's not safe in that scenario. "Destructive" means throwing away anything, even one word the user typed. Do not use the word "cancel" for that operation - use the word "Discard" or an X button, with an are-you-sure prompt that has a cancel button that safely brings you back to the editing interface.

Edit: OK, maybe "one word" is an exaggeration. Certainly for the case of a form of input fields a no-prompt cancel button is inappropriate. However, if you have a simple OK/Cancel dialogue that contains a single one-line input field, it is usually acceptable to have a Cancel button that throws away your input without prompting.

If I'm filling out a modal form and "Cancel" doesn't result in a clean form after I open it again, it should probably say something like "Hide" or "Finish later" instead.

That's not a cancel.

This is not true. Cancel is often destructive, we just have a bar over which it will ask you if you really meant to throw away your current work. Like, I just went to type a new message in iMessage and if I hit "Cancel" it gets rid of what I typed. That's because it's not worth the mental overhead of saving two lines of text that is the typical amount of unsaved content that a typical message contains. On the flip side, Mail will ask you if you want to save a draft if you exit.

I disagree that this is evidence that it is "often" destructive - however, this is mostly a semantic disagreement. As you have pointed out, "destructive" is subjective. I mention in another comment that I would consider throwing away the contents of "a single one-line input contained in a prompt" to be non-destructive. It's not a large leap to the contents of a single instant message, whether or not I agree that it qualifies. E.g. if iMessage would throw away a large amount of text un-prompted, I would disagree with iMessage's UX.

I'm not sure you really disagree with the core of what I'm saying, which is that "Cancel" is the universal easy way to safely dismiss a modal prompt, and also, regardless of what word you put on the button, if it would throw away a (subjective) threshold of data, you should prompt the user.

I went into this discussion with the suspicion that despite your ALL CAPS exhortation your opinion was not actually all that disagreeable or controversial.

Yeah, I would characterize it as a genuine all-caps exhortation only under the qualification that I am defining the word "prompt" as a simple prompt, not e.g. a message-composing UI (but the author is talking about modals in general, so I was not being precise enough about my disagreement with the author in my first comment).

You’re correct, the linked article contradicts the Human Interface Guide from Apple.

From the official docs [0]:

Always use “Cancel” to title a button that cancels the alert’s action …

“A specific button title like “Erase,” “Convert,” “Clear,” or “Delete” helps people understand the action they’re taking.”

In fact, I think the entire topic is much better explained (with considerations for each platform) in the docs.

[0] https://developer.apple.com/design/human-interface-guideline...

More on navigation:

https://developer.apple.com/design/human-interface-guideline...

https://developer.apple.com/videos/play/wwdc2022/10001

In the example of Apple Calendar, creation is arguably the "dangerous" event even if it's not destructive, so one might argue that what Apple is currently doing on Apple Calendar (cancel destroys the event) is compliant with the spirit of their HIG. I'd use the same argument of creation-is-dangerous for the alarm app, which also has a non-scary cancel button that destroys the input.

Then we go to something like Apple Notes where even the slightest bit of data is auto-saved without asking.

I don't follow. Apple Calendar shows a sheet to create a new event. The sheet has a primary action (Add) and a discard action (Cancel). If you hit Cancel after adding some data, you get an action sheet "Are you sure you want to discard this new event?" with the options to "Discard Changes" and "Keep editing"

The primary and secondary actions on a sheet are not the same (different modality and context) as the options on a modal action sheet (where we usually have to confirm or discard).

Oops, you're right, I just didn't change any data. However, on Apple Calendar for MacOS, using ⌘-n and dismissing the prompt will destroy your data. The same is true for alarms on iOS.

"Cancel" should never be on an "Are you sure" prompt.

Labels the buttons with what they DO.

"Don't delete", or "Keep", or "Save", and "Delete", would be appropriate button labels.

Sorry, I disagree. I've seen the pattern you're describing. Yes, it is perfectly acceptable (usually preferable, even) to replace "OK" or "Yes" with an explicit verb. But please do not do the same for the cancel button. It creates an unnecessary cognitive prompt. Always give the user a no-thinking safe way of dismissing a confirmation prompt - we have trained users for decades that "Cancel" is that escape hatch.

As another commenter pointed out, I agree with the HIG here: https://developer.apple.com/design/human-interface-guideline...

Always use “Cancel” to title a button that cancels the alert’s action.

Are you sure you want to cancel your flight?

[Cancel] [Cancel]

I totally agree that it is preferable to replace "OK" or "Yes" with an explicit verb. The same thing should be done to the usual "Cancel" button. If you are already thinking of an explicit verb to replace "OK" with, just add "Don't" to the other one.

And as always, the unstated first rule of UI is: Also use common sense :)

E.g. in this case, the first option should be "Cancel Flight" or "Yes", and the second option should be "Do Not Cancel" or "No", though I'm sure there are other reasonably explicit options.

Edit: We each made essentially the same suggestion as an edit to our posts at the same time. The only difference is that I consider this an exceptional case. I still contend that "Do Not XXX" requires more thinking than "Cancel" when there isn't an obvious semantic conflict. You say "if you are already thinking of an explicit verb...", but I am not concerned with saving myself cognitive effort - I am concerned with the user.

Edit: Also, note that this is all tangential. The only point I was interested in writing about at the top of the thread is that, when you do see a "Cancel" button, it should never be destructive.

In the case of a e.g. "New Widget" modal popup, I'm quite comfortable with a "cancel" button that means e.g. "this will discard whatever you typed / stopping the creation of a new widget". That kind of cancel button certainly results in lost information, and in some sense it is "destructive". But isn't "destructive" of data that we expect to persist. I typically use the word in the latter sense.

Hopefully people have a decent shared understanding of the term "destructive" or this is going to be very confusing for all involved. Is there a clear shared understanding? I don't run UX testing.

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.

Here are my questions so I can fully understand what you mean:

1A. Does it makes sense to have a button to (destroy/prevent) ("in-flight"/tentative) changes?

1B. if so, what do you think a button doing that should be named?

2A. You also think there should be a button to make the modal go away but keeping all inputed data just as it is?

2B. What should that button be called?

I'm wondering if you might answer: 1A: Yes. 1B: "Discard". 2A. Yes. 2B. "Dismiss".

I believe the author used “destructive” because that’s the name used by UIKit to style a cancel button with the system defaults.

Next, try addressing why they change all the time, and seemingly for no reason. It's infuriating.

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'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.

At this point I'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.

Overall I thought the watchOS changes were a huge upgrade to the visual design and power of the platform and its apps.

But I still end up opening the wrong view (control center or app drawer) at least once a day. And it’s been months! If the choice is so unintuitive a reasonably fanboyish user doesn’t learn it after months, it’s probably the wrong choice.

And you just know it's configurable (just like the original iPad allowed you to change the behavior of the slide switch), but they simply chose not to.

Interestingly, they did backtrack on removing the "swipe to change watch faces" functionality, and added back a configuration option for it today.

Although I’m noticing that mine now brings up every watch face with the time set to 10:09 and then takes a moment to animate changing to the correct time. It looks really stupid with the solar face.

And it doesn’t do it just once when a face first loads, it does it every time you switch faces.

Hopefully a bug but I’m wondering if someone said “we made it so you can’t switch watch faces quickly, now we can reclaim that RAM and save it for widgets that you didn’t want.”

I’ve also noticed issues with the time on the watch face being out of date. I’ve also seen the date be wrong.

It’s a pretty serious flaw that doesn’t get talked about enough. Been around for months at least, I got burned in September and ~May of this year.

And then ...

At this point I'm convinced they are making changes as a means to justify their existence.

I really hope this is humor and that you aren't convinced of this; that would a faulty generalization. There are plausible other interpretations.

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.

1. Apple regularly breaks expectations. What is a breaking change to some is often the expectation at Apple.

2. I challenge your assumption that this decision was a mistake. I would expect the pros and cons were calculated.

3. How do you know the decision didn't get approved by higher up the chain?

4. Even if it was a mistake, I challenge your claim that the appropriate response is to fire the managers. I would point you to a vast literature on effective modern management. My remaining points elaborate on this...

5. I disagree with what appears to be angry, impulsive decision to fire them.

6. These are people. I'm not seeing any indication that you value them.

7. Emotions and empathy aside, it would be in your interest to build a healthy culture where risk-taking is encouraged and one mistake doesn't get you fired. Everyone makes mistakes. And we can learn from them. (Yes, dishonesty and negligence gets you fired. And poor performance gets you fired, but this is not evaluated on the basis of only one mistake.)

8. I disagree with what appears to be a "I have everything I need to know about this" attitude. At the very least gather more information before you fire people. If you disagreed with the pro/con assessment, look into how that decision was made. What process(es) could be improved?

You've created a very long list over what looks to be hyperbole until 'wannacboatmovie actually does end up in a position at Apple where they handle staffing.

I consider you lucky if you think the attitude about 'just fire the people that made mistakes' is hyperbole. It a common attitude, so when ^^ says it, I believe that is what they mean.

Also, there is nothing wrong with a long list.

And I'm not here for hyperbole.

It's a common attitude on the internet, where people will also argue for people to be executed or thrown in jail for trivial slights because it makes their annoyance more visceral. Nobody in their right mind will actually end up doing that when push comes to shove. It can be appropriate to tell people to calm their rhetoric when they do this but I don't see "ok actually 1. there might be a reason and 2. maybe they made a mistake and 3. people who make mistakes should be allowed to learn and 4. …" being very useful.

I hate how they changed complication buttons in the last major update. It used to be if I raised my Watch I could immediately tap my timer complication and it'd open my timer app. Now it's like the screen is constantly partially transparent and tapping the complication doesn't do anything unless the watch is at exactly the right angle. So confusing.

Isn't that how the always-on display has worked since forever?

Nah. I have a Series 6. It works distinctly differently ever since I upgraded to WatchOS 10 (I think that's the latest major version that released when the latest iOS major release came out).

Imagine buying a wearable computer with automatic remote updates and thinking it will behave like an analog watch.

Actually, if one buys an appliance (which this is), I would expect and be fully okay with security updates only, and not for the basic means of operation/controls to change monthly.

Next, try addressing why they change all the time, and seemingly for no reason. It's infuriating.

No, the "Modern iOS Navigation Patterns" (the title of this article) don't change all the time. Not even close.

What you are talking about has to do with _buttons_ on watchOS.

I strive to leave a wide wide berth for what people consider on-topic, but to me, this comment is an unrelated rant that will empirically crowd out discussion around the topic at hand: iOS navigation patterns. I'm here on this thread to learn about how to make better iOS apps.

I hate these updates that change things around and break muscle memory. And most likely by coincidence it happens at the most unappropriate times.

I’m not sure if this is related enough or not, but here goes:

On Mac and now iPadOS (https://useyourloaf.com/blog/ipad-customizable-toolbars/), the built-in toolbar control supports a high degree of customization. You can try this in Finder, among many other native apps.

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.

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.

According to doc it is still there, but does anyone know of apps still using this pattern? https://developer.apple.com/documentation/uikit/uitabbarcont...

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.

The customizable tool bars are still around in SwiftUI and very nice to work with!

Yep back in the early days it was very common to be able to mix around tabs and take out out in the ones you wanted. Back when FB was still decent in the... iOS7? says it let you do this with chat, feed, notifications, groups, etc. as an example.

iTunes Store?

I still miss the ability to rearrange the toolbar in iOS apps like the music app. I never use 2 of the tabs in Apple Music literally ever. I wish I could make it go directly to playlists and albums.

On Mac I wish more apps used the standard toolbar. The customizability is nice and rarely found in bespoke implementations.

UITabBar has always been painfully limited in its customizability by the programmer and the customizability by the user aspect is something that few projects care about. By locking down its appearance so tightly, Apple pretty much ensured that everyone always replaces it with something else.

Various Apple apps like Apple Store and Music use a tab bar at the bottom, but they're not customizable. Everything I can think of outside of Apple switched over to completely undiscoverable hamburger menus a long time ago.

There's a few apps where I'd like to remove tab buttons as a user; but as a developer, nobody has ever asked me to implement the feature; and based on my parents regularly accidentally removing things from the MacOS dock instead of opening them and needing my help to get it back, I suspect the ability causes a lot of customer support issues.

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

I think the X/Twitter iOS app and the reddit app are guilty of this. I find myself way too often typing something out, then barely touching the edge of my phone, and my entire comment is gone.

On Twitter you can't swipe out of the tweet compose screen. You have to explicitly click the "Cancel" button in the top left, and if you have anything written it'll pop a dialogue to either delete the contents, save as a draft, or cancel (go back to composing)

I'm not sure how you'd swipe out of this screen.

Pro tip: Twitter works as PWA.

Swiping right from left to go back is a horrible horrible way of implementing a "back button" and you should never do it, always have an actual back. Why? Because left handed people exists. It's a not a natural of comfortable movement when done with your left thumb. You also can reverse the direction for left handed people, because if you normally read left to right, then swiping right seems like it should take you forward, not back.

Generally I'm not a fan of swiping to navigate. On iOS it's really bad, because swiping from the bottom up, you bring up some menu, which actually contain a bunch of important stuff, which you can never find when you need it, but which you will trigger constantly when scrolling a web page.

Perhaps more generally: iOS have devolved into a horribly complicated OS that is an absolute nightmare to navigate and I feel like Apple should start to take UI/UX serious again. Mostly the issue to me seems to be the expectation that the phone should handle a whole hosts of tasks for which it is ill suited.

I exclusively use my phone with my left hand and I have no issue with the swipe to go back gesture in iOS.

Sailfish OS does this properly and consistently - in all apps.

https://sailfishos.org/

I've found it overall simpler and better than both iOS and Android.

I'm sure Sailfish, too, allows you to prevent the gesture if you want. On iOS if you use the standard navigation controller, you get it automatically. If you're swimming against the tide and want to do something unusual, you have to implement it yourself, but it's easy enough with a readily available gesture recognizer.

The entire article can be summarized into one word: trees.

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).

The official docs can also be wrong and outdated, so there is no difference here. Besides they can also be poorly written, so there is nothing absolute here

Outdated, yes. Poorly written, sometimes. But how can you call documentation wrong without seeing the source code? And if the direct source is wrong, how could the secondary source then be right? Sounds to me like developer or designer arrogance is at play here, when they should be questioning the correctness of their own understanding.

But how can you call documentation wrong without seeing the source code?

Very easy - by observing reality, and how it matches to what's documented

And if the direct source is wrong, how could the secondary source then be right?

In exactly the same easy way - by observing and documenting reality. For the same reason this is a second primary source, not a secondary one

Sounds to me like developer or designer arrogance is at play here, when they should be questioning the correctness of their own understanding.

Good albeit slightly misdirected advice, we have a great case of misunderstanding pretty trivial things that lead to trivial questions and faulty personality assessment

My impression of this article is that it is not an interpretation of apples guide lines (ie a secondary source) but a write up of observations (ie a primary source)

This can be of interest for a few reasons, but particularly because such investigations might reveal “true” design philosophies over espoused philosophies.

What do you mean by true versus espoused? iOS’s modals, tab bars, navigation bars, and everything mentioned in the article are exactly the objects or value types that you deal with when you go to the code level and actually use the APIs.

On the first entry:

Drill-down navigation is stateless

I've been encountering this a lot lately, but: this seems the opposite to me, it's deeply 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't it would be awful.

A stateless UI would be, like, a one-step modal. It exists or it doesn't. Particularly strongly "stateless" if it's transient and you have no way to "resume" it.

I've been in and around quite a few discussions using the term "stateful" 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.

What does "stateful UI" mean to you all? I find the variation fascinating.

To me, stateful UI means that the front end is using variables to manage its behaviour.

This would mean it's strictly an implementation detail then? Since any state can be turned into configuration / construction / just make infinite views, each one customized to show one state.

Implementation differences are certainly a part, but people do interpret them differently.

For example, I'm working on an application that is transitioning some of our stateful navigation to be more stateless to hopefully address some end-user confusion. We have an overlapping hierarchy where many objects have multiple parents, and the same object would display different breadcrumbs depending on which path someone took to the object. This made people confused about whether they were looking at the same object.

I agree the use of "stateful UI" is ambiguous in general, but with respect to navigation I typically hear hierarchies referred to as stateless and activity stacks as stateful.

With a hierarchy like iOS every child is supposed to have exactly one parent so you only need to know the current page to know what the "back" button will do -- it will go up one level in the hierarchy to the page's parent regardless of how you arrived at the page.

With an activity stack like Android, it is not sufficient to know the current page, you must know how you got to that page because the "back" button refers to going back in the history.

Many websites support both -- the browser's back button is stateful and navigates your personal history, whereas on-page navigation like breadcrumbs are often stateless and do not depend on the particular path you took to get to the page. There are exceptions of course, many search interfaces are stateful in that drilling into an item and going back using the in-page navigation will return you to the prior query rather than the page's parent.

Frank Rausch created the best Wikipedia app ever, "V for Wiki"*

So when he speaks about iOS design and UX, I'm inclined to listen.

-----

* https://web.archive.org/web/20211223231349/https://v-for-wik...

On a side note, what ever happened to V For Wiki?! I used to use it every day and one day it just stopped working. Looked it up on the App Store and found that it was missing. I was heartbroken :(

I believe development stopped at some point, but the app of course remained working frozen in time. But then earlier this year Wikipedia changed their API and the app stopped working definitively.

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.

I agree. You also get 'trapped' on some screens because all of a sudden you've lost all navigation cues, even the swipe up bottom nav.

If you ever lose the bottom home bar it just means you're in a full-screen view where they want to prevent accidentally swiping to go home, like a full-screen video or a game. In those cases you just have to swipe up once to re-enable the home bar, and then again to actually go to the home screen.

The Home Screen actually uses the pyramid pattern and not the hub and spoke.

You can swipe between apps using the black bar at the bottom.

except that the stack you're swiping between is not represented in the layout of the icons - it's on how recently you've used the app.

ie: if i have photos, calender and safari all on the same row of the home screen, and i open photos, go back to the home screen and then open safari, if i swiped left to right (to go backwards) on the bar at the bottom i'd go directly back to photos, not to calender

iOS does this reasonably well

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.

whereas on Android, sometimes the 'Back' gesture lands you on the previous page and sometimes it completely closes the app. it's so inconsistent that I dropped 12 years of using Android and switched to iOS.

It has been like that right from the start. It amazes me that you put up with it for a whooping 12 years before deciding you've had enough.

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

Depends on the gestures, I guess. I have all gestrues by swiping from right side and cant be happier (back, home, swap last used app, list of last used apps, splitscreen, power button). All the same swipe, forked by the swipe direction (upwards, sidways, downwards) and whether I hold the finger down after finishing gesture.

Its amazing, and one of the main reasons I wont be switching to apple. Who thought that the back gesture should be swiping right from left edge? Why not left from right edge? Doesnt make any sense for right-handed people..

I like the presentation, it's understandable and well-structured.

From what I can see, Apple's guidelines look really similar to what Google suggests for Android apps - the only really big difference is visual presentation.

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.

I'm dead excited for 2040 when SwiftUI can handle all of these patterns natively.

And, maybe for 2043 when our n-3 OS target will let us support them in our app.

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.

That seemed to completely vanish when they went with the "flat" design - mainly I think because none of it made sense anymore. They went from very clear:

- make sure the user interaction is obvious

- this might be clickable, or it might be some text or maybe it's a long press...

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

Swiping right from the left edge of the screen does the same as pressing the Back button.

Wish you could disable that, so common horizontal scrolling in web pages that don't fit activates the Back function

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

Are there any good app examples of what Frank says here?

"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.

The step-by-step process is usually completed with a Done or Close button, which also closes the containing modal.

The sequence can have a variable number of steps and different paths depending on the options selected."

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.