The HIG


« Pricing

Apple During the Pandemic »

One of my favorite things that Apple does for developers is go to great pains to describe the user experience and how we should support it is in the Human Interface Guideline better known as "The HIG".

"HIG" is pronounced to rhyme with "big" and not spelled out as Notorious B.I.G. would be. The name "Higgy Smalls" never caught on. But I digress.

You don't hear about apps being rejected for violating the HIG much any more, but it used to be a thing.

Part of the reason was that in the early days of iPhone, before there even was iOS, we had all these new controls and it wasn't clear how to use them. Or sometimes it was clear, but in order to get a particular effect, you might use one in a non standard way.

Here's a small example. You should use a UILabel for displaying a small amount of text but instead you use a UITextField and prevent editing. You are violating the HIG. The use of a text field implies to the user that they can edit the text and yet they can't. You should use the label instead.

And so the early versions of the HIG helped us reach for the right component.

The HIG has evolved and changed its focus and presentation quite a bit.

I would argue that we need a well thought out HIG to help us with SwiftUI on each platform and for multiplatform apps as well. The HIG should (as the current one does) help us understand architecture and moments in the app lifecycle as well as helping us know when, for example, we should use a disclosure group for a list and when we should navigate to another page.

We need so much from Apple right now if we are to appropriately adopt and use SwiftUI.

We need the API itself to continue to be filled out (Web View anyone?).

We need the existing components to work properly and appropriately on all target platforms.

We still need the docs to be filled in.

We need the rest of the sample code from the WWDC sessions to be released and we need additional sample code.

But in addition, we need more from Apple on the when and why to do things different ways.

I think this year and last year's sessions on Data Flow are exemplary in showing us when we would use each approach. Together they made it clear when I want State, Binding, Observed Object, State Object, and Environment.

I need more of that from the visual side of the house and perhaps more content on architecting with and without the help of Combine.

There needs to be a SwiftUI focused HIG.