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.

Thread beginning with 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

RE: iOS developer
by Thom_Holwerda on Fri 27th May 2016 12:12 in reply to "iOS developer"
Thom_Holwerda Member since:

Regarding settings: in the mentioned iOS review, I go into quite some detail about how the settings mess in iOS came to be. It effectively comes down to Apple not having the guts to set and enforce a single standard.

Which, in turn, is emblematic for the wavering state iOS has been in post-iOS6: there's no captain on deck. No leader. What I'm hearing from inside Apple is that after Scott Forstall left, the position of captain has been effectively vacant.

And it shows.

Edited 2016-05-27 12:12 UTC

Reply Parent Score: 1

RE[2]: iOS developer
by arkeo on Fri 27th May 2016 14:08 in reply to "RE: iOS developer"
arkeo Member since:

Thom, from a UI perspective there's been a captain missing for a long long time.
On the desktop this is ever more relevant than on handheld devices. I ran away from OS X Jag-wyre (as He Almighty brother-to-Jesus pronounced it) soon after it was released.
That's 2003/4.
XP seemed the lesser evil. And it was, both technically and aesthetically speaking: never had a virus (been using Firefox since the earliest betas, and it seems it was enough) and although XP looked like shit it was somewhat consistent. W10 is crap, I feel ashamed using it.
But in all this mess, despite how much I don't trust The Big G, my S6 is a friggin' heaven. Well, except for the fact that it is made of glass (?!??)

Reply Parent Score: 1

RE[2]: iOS developer
by sergio on Sat 28th May 2016 00:52 in reply to "RE: iOS developer"
sergio Member since:

Regarding settings: in the mentioned iOS review, I go into quite some detail about how the settings mess in iOS came to be. It effectively comes down to Apple not having the guts to set and enforce a single standard.

And Who cares? Why enforcing a single standard is better than the current situation? I prefer some flexibility to unavoidable rules, let's the developers figure it out!

You mentioned Twitter for iOS... what's the problem with it? It works perfect!! It's super usable, the "problem" that you mentioned is not really a problem, It's a freakin detail (a very minor one).

I think you overestimate consistency because is something YOU care about... but the rest of the world really cares about it? I don't think so.

Reply Parent Score: 1

RE: iOS developer
by wigry on Fri 27th May 2016 15:44 in reply to "iOS developer"
wigry Member since:

More notes regarding consistency.

On Android, there is an extensive set of assets and icons from the OS exposed to the developer to be used in custom apps. All for promoting consistency where the same system-provided icon is used on similarly functioning buttons on different apps. No such luck on iOS.

Yes the iOS also has about 30 system-provided icons but they have huge technical limitation - they are only available on toolbar buttons which in turn can only be used on toolbars. You cannot put that system-provided icon onto a regular button. Well there is a hack to get it there anyway by adding an invisible toolbarbutton onto an invisible toolbar and then traversing the component hierarchy until you reach an UIImage object reference and then assigning that reference to your own button - hence stealing Apple provided icon from the guts of system component. But it is a hack.

Also have you noticed a missing UI elements in iOS? In fact iOS does not contain following regularly used components: checkbox, radiobutton and combobox. There is a substitute for two of them.

The replacement for checkbox should be switch. Well in some cases the "switching" might be OK but in other cases it is just awkward. While I would want to "switch" off a location service usage, I would feel really awkward to switch on the agreement to privacy policy. Fortunately the regular iOS button may be set into several different states and different images could be assigned to those states, so usually the checkbox is emulated by images of unchecked/checked box designed specifically for the app.

The replacement for the combobox is picker component. While picking a date or maybe even long list f languages would be sometimes OK, picking an object type would be silly. You can assign input view to any textfield, and when you activate the textfield, a picker will slide in from the bottom. If the text field was at the top of the screen, then transitioning to the bottom to make a selection seems awkward. And stopping a scrollable list in the picker is considered making a selection causing the picker to dissappear and filoing in the textfield. This severely limits the users ability to browse the list of available options. Workaround is to add a toolbar with "done" button to the picker window.

"However ther is no substitute for radiobutton. Apple says that all selections should be donw via picker but that is really strange thing to fit onto many input forms. So instead many will work around the limitation to add several buttons onto the screen and manually ensuring only one is in "selected" state and provide different images to different states emulating the radiobutton functionality. Again design is different on every app as there is no system component.

What iOS has that Android doesn't? Two absolutely mindbogglingly complex and featurerich frameworks: UIDynamics and since iOS 8 the SceneKit

UIDynamics allows you to assign gravity to UI components and they would start ot behave like objects in real world. I mean you can literally make all the labels and buttons and textfields drop from their place to bottom of the screen where they pil up and which ever way you move your phone the gravity field follows and the freely moving labels and textboxes slide and roll around the screen. Totally useless but cool anyway - to implement complete physics engine into UI controls.

SceneKit is a complete 3d engine based on OpenGL ES built right into OS. You can take an animated scene from Blender, export it as Collada, import it into iOS project and with couple of lines of code get it on the screen and animating via SceneKit. Performance is very good and it is really quick to get 3D working from Blender to phone. Again if you are into 3D stuff and making for example augmented reality app or a game, then thats a plus but for regular email/messaging/social/photo apps it is utterly useless. And all it does is to add download size to the OS image.

Reply Parent Score: 5

RE: iOS developer
by javispedro on Fri 27th May 2016 20:03 in reply to "iOS developer"
javispedro Member since:

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.

You're part of the problem here.

If the environment has UI rules, _just follow them_, even if you believe (wrongly or not) that they lead to user frustration. Because the inconsistency of not being able to swipe that one to the right leads to much worse frustration.

Reply Parent Score: 1