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 629517
To read all comments associated with this story, please click here.
RE: iOS developer
by wigry on Fri 27th May 2016 15:44 UTC in reply to "iOS developer"
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