Linked by Thom Holwerda on Fri 27th May 2016 09:33 UTC

Jason Snell, in an article about Google's iOS applications importing Material Design into iOS:

Users choose platforms for various reasons, but once they’ve chosen a platform, they deserve consistency.

Someone should tell this to Apple and virtually all iOS application developers, because iOS is an inconsistent mess of an operating system.

Here's a few examples taken from my never-to-be-published iPhone 6S/iOS 9 review that I wrote during the six months I used the thing (up until a few weeks ago, when I went running back to Android because iOS couldn't even get the basics like multitasking and inter-application communication right).

Take something like application settings. In Outlook, tap the settings icon in the bottom bar. In Alien Blue, tap the blue dot in the top right, then settings. In Tweetbot, tap your account picture (!?), then settings. In the Wikipedia application, tap the W logo, then "More..." (!?). For many cross-platform applications that are also available on Android, tap the hamburger, then find something that sounds like settings. For Apple's own applications, close the application (I wish I was joking), open iOS' Settings application, scroll down for days, figure out in which unnamed grouping it belongs, then tap its name.


So it goes for settings, so it goes for many other things. Navigating between main parts of the user interface of an application is sometimes done via a tab bar at the bottom, sometimes it's done via a full-screen root-level list menu, sometimes it's done with a slide-in drawer, sometimes there's a tab bar at the top. Sometimes you can swipe between tabs, sometimes you can't. Animations for identical actions often differ from application to application (e.g. closing an image in iMessage vs. closing it in TweetBot).


It goes deeper than that, though. The official Twitter application, as well as Apple's own compose tweet dialog, for instance, replace the enter key on the iOS keyboard with a pound sign, hiding the enter key in the numbers panel. Why is this even allowed in the first place? Or, even more infuriating: the "switch between keyboards button" (the globe) is actually in a different place on the Emoji keyboard compared to regular language keyboards. So when I'm cycling between my keyboards - which I do a million times a day - from English to Dutch, the process comes to a grinding halt because of the Emoji keyboard.

The problem is that while Google's efforts on first Holo and then Material Design have given Android developers a relatively clear set of rules and instructions on how Android applications should look, feel, and behave, there's no such set of clear rules for iOS. The iOS HIG is vague, open to interpretation, and Apple itself regularly casts it aside to do whatever it feels like (look up the section on where to put application settings. It's comically open to interpretation so as to be effectively useless).

That's how you end up with impenetrably convoluted applications like TweetBot - often held up as a shining light of iOS application design - where you can perform up to 15-20 different actions with various gestures, taps, taps-and-holds, hard-taps, etc., both operating system-level and application-level, on a single tweet in its timeline (good luck not mixing those up, either because you used the wrong gesture or tap or because the operating system's touch/tap algorithms buckle under the pressure). Or, the popular and praised Overcast podcasting application by iOS star developer Marco Arment, which ditches the standard iOS fonts for its own comical font because... Reasons? And on it goes.

I've been a strong proponent of militant consistency in user interface design and behaviour for as long as I can remember, and while neither iOS nor Android are shining examples of the concept, there's absolutely no doubt in my mind that Holo and Material Design have done a far better job of propelling at least a modicum of consistency in Android application design than anything Apple has ever done for iOS. From that same never-to-be-published iOS review:

Interactions with a smartphone tend to be quick, focused, and often involve cycling through a number of applications very quickly. Unlike desktops or laptops, we tend to not use the same application for long periods of time, but instead quickly jump in and out of a number of applications, and then put the phone back in our pocket. Given this usage pattern, the less you have to think about where stuff is and how to do a thing, the more fluid and pleasant your workflow will be.

And this is one of the many reasons why using iOS is such an incredibly frustrating experience for me. Every step of the way, I have to fight with iOS to get it to do what I want, whether it's every application doing things in its own specific way, applications not at all talking to each other, the inability to set default applications - it all adds up to an experience where I have to spend way too much time and energy thinking about how to get around iOS' limitations, iOS developers' auteur application design, and Apple's inability to write, apply, and consistently enforce its own HIG - even after six months of exclusive use and spending €800 (I really tried).

It's great to ask of Google to make its iOS applications consistent with iOS' design principles - but you might want to ask Apple what those are, exactly, first.

Permalink for comment 629505
To read all comments associated with this story, please click here.
iOS developer
by wigry on Fri 27th May 2016 11:56 UTC
Member since:

I work daily as iOS app developer and my work is driven by Android. The designs are always oriented around Android phones but customer also wants iOS version which actually turns out to be a port as customer has no money nor interest to create a separate UX specifically for iOS. So I have to use magic to get it all working on iOS.

Second thing about transitions. If I want a new window onto a screen, I explicitly have to tell how, if at all, is it animated. There is no default provided by OS. Also when I use window stack (navigation bar) and ask for animated transition, it is animated from the right. If I however want to make a window which is not part of navigation stack, then it is transitioned from the bottom. Why I want to make a window which is not part of navigation stack? Because if the window is part of the stack, then iOS has a "long swipe" gesture which allows user to dismiss the screen by swipeing in from the left edge. If the window happens to be input form, then I really don't want the user to be able to accidentally dismiss it, so I have to make it a standalone screen on top of screens belonging onto a stack. And if you now add animations, then some screens pop in from the bottom, some from the left. If you want to switch from one window to the next, then first window slides down, revealing what was there before and then new one slides in from the bottom - freaking the user out as there is too much animation. Instead I opt to turn the animation off, bringing inconsistency where sometimes screen transitions are animated and sometimes they are just appearing out of nowhere.

So from developers point of view, the Apple iOS API is very very flexible and hence the mess. Every developer does things differently.

Regarding settings. iOS has a determined space for every application to contain its settings. Go to settings, scroll down and find the app icon and there you see things like location services and data services flags. App can open this screen directly with single line of code, so it would be cool to centralize all app settings here? Well not so fast. You can do very limited design here and also the communication back to the app that its settings have changed, is done in very limited fashion. So instead it is recommended that every app designs its own in-app settings screen and storage behavior.

Reply Score: 5