Seriously, designing app mockups for iOS is scary as hell. Everytime I try to do an iOS mockup, I keep thinking of those "rules" in the Apple Human Interface Guidelines that says you can't do this this this, and that thing must be so and so color etc.

Say, if we try something like this :

enter image description here

Is this ok? Or must all iOS apps have a white background, buttons must not have borders, use only the standard iOS controls etc.?

  • it may only take more time to review and be approved, but as long as it works as expected, you won't have any problems
    – Devin
    Commented May 13, 2016 at 16:49
  • 1
    Related from SO: stackoverflow.com/questions/18097834/…
    – DasBeasto
    Commented May 13, 2016 at 17:09
  • tks guys, i'm just concerned that if it doesn't get approved, i will look bad in front of my boss and client. Commented May 14, 2016 at 5:52

4 Answers 4


The Apple Human Interface Guidelines are 'Guidelines', not 'rules' - you don't have to follow them entirely, design and build what you like.

  • 1
    tks, what i'm worried about is Apple might not approve the app and make me look really bad in front of my boss and client. Commented May 14, 2016 at 5:51

Guidelines are guidelines.

If you follow the guidelines, you are leveraging the platform's consistency. This reduces the cognitive load for your users because they already have an innate understanding of how to use your app, and because your app is more likely to feel like it fits along with everything else on their phone.

If you choose not to follow the guidelines, be able to clearly articulate why you're not following them. "I don't want to" is probably not a good reason. Keep your user's experience first and foremost in your mind. After all, the guidelines are for general app development, and they don't necessarily make sense for every application or every workflow. Any app should be user tested; this is more important the further that you get from the guidelines. If users aren't able to find an important control because you've chosen not to use the system controls, you might need to re-think some aspects of your design. If you have a well-articulated case for why the guidelines don't fit, and if you have data from user tests to back up breaking the guidelines, your boss and clients are going to be a lot more comfortable.

There are many reasons for an app to get rejected by the App Store. They're often easy to fix. Don't treat a rejection from the App Store like it's the end of the world. Accept that it's a possibility, and be responsive to it if it does happen. Don't waste your time worrying about it happening. Spend your time on creating and testing an awesome user experience.


Look at pttrns.com and see how visually rich existing apps already are. You may think of the human interface guidelines as suggestions for what to do when you don't already have a solution in mind. It's one thing to ignore the HIG because of being unfamiliar with it, and another matter entirely of consciously choosing to do something differently than the guidelines suggest.


These are guidelines and no more or less than that.

Saying that, the company I worked for have quite a few apps in the app store and we we recently got some of them critiqued by Apple due to wanting to be featured in a particular app store.

Out of this, they flagged up many issues regarding UX and also commented on us not using their guidelines as much as we should have. I found this very interesting as internally we thought we had a great app which did still have some elements of iOS guidelines.

So I guess what I am trying to say is:

  • Design custom screens if you feel the app and the users would benefit greatly from the custom screen - but keep consistancy throughout your custom screens
  • Try and stick to the guidelines as much as possible, where you can for things like Navigation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.