Skip to content

Instantly share code, notes, and snippets.

@nickbauman
Last active November 1, 2019 12:10
Show Gist options
  • Star 28 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save nickbauman/9572694 to your computer and use it in GitHub Desktop.
Save nickbauman/9572694 to your computer and use it in GitHub Desktop.
Condensed iOS Human Interface Guidelines, formulated as imperatives.

Condensed iOS Human Interface Guidelines

Imperatives for AppStore approval

For iPhone app developers. Emphasis on getting the fastest app store approval. Everything stated as suggestion made into an imperative. When "violating" these imperatives, you can check for yourself what the caveats are. Generally speaking, deviating will more likely cause your app to be hung up in approval.

You can read this entire document in about 20 minutes. This is faster than reading and understanding the entire Human Interface Guidelines.

Overview

  1. iPhone apps home / start screen shall be portrait mode (11)
  2. Don't use standard gestures to do non-standard things (11, 60)
  3. Easy way to test app termination and restart by bringing up the suspended app dialog and killing it (13)
  4. Don't copy the look and feel of system components into a custom component (17)

Feedback

  1. An item in a List component shall only briefly highlight when touched (18, 125)
  2. Adding items to a list shall be programmed to animate into place (18)
  3. Sound can help to signal an event to the user, but you can't rely on it 100% (18)
  4. Any navigation (screen-flow / workflow) implies you are writing a navigation-based application (22, 44)

Information architecture

  1. Think top down on any screen design: the most important and highest level near the top, the less important low level near the bottom (44, 22)
  2. Put the most important data in the top half of the screen and allow people to scroll down if necessary (24)
  3. Don't reduce font size to fit the layout / screen (24)
  4. Don't needlessly customize the look of familiar components (26)
  5. Prototype an app by making a storyboard file and filling it with placeholder content and showing it to your users on an actual phone (27)
  6. Make one and only one path to a screen (45)
  7. The main function of your app shall be immediately clear (45)
  8. Be consistent with how UI components are used in built-in apps (46)
  9. Avoid date-speak. Saying "today" or "tomorrow" based on a timestamp is hard to get right based on locale, so try to use real dates (47, 102-3)
  10. Shortcut user input. Use appropriate widgets to get data more quickly. Don't make the user enter data they already store and you can query (47)
  11. Write your app like the filesystem doesn't exist to the user (48, 73)
  12. Avoid settings or preferences for your application (50, 63)
  13. Avoid all branding in the app. If you have branding make it subtle and unobtrusive (50)

Search

  1. Eagerly index your data for searching (51)
  2. Filter in real time, preferably while the user is typing. This includes remote data when possible. (51, 74)
  3. Don't use a tab for searching, integrate it wherever it's needed (51)
  4. Display placeholder content right away as you load real data (51)
  5. Use a scope bar if the data returned can be easily categorized. See Scope Bar: Page 148. (51)

Copywriting

  1. Don't write in all caps (52)
  2. Don't misspell words (52)
  3. Describe bug fixes to new versions in detail (52)
  4. Don't be loquacious: keep your wording short (52)
  5. Don't customize widgets unless you're making an immersive game (52)

Design, Look and Feel

  1. Don't use standard components to do non-standard things (53)
  2. Consider adding realism. A spirit-level app shall visually simulate the behavior of a real spirit level (54)
  3. Don't hardcode screen-sizes (56)

Device Orientation

  1. Don't constrain device orientation (57)
  2. Maintain focus when device changes orientation (57)
  3. Don't tell the user to change the device's orientation (57)
  4. If your app must run in a specific orientation, launch in that orientation (57)
  5. If you have a complex page that doesn't animate orientation change well, use a cross-fade transition (57)
  6. Check accelerometer if it matters on orientation changes (57)
  7. Don't scale up your content to fudge device orientation changes (58)

Events, Modes, Animations and Gestures

  1. Taps need a target area of 44x44 pixels, so don't make components smaller than that (59, 111)
  2. Don't define new gestures (61)
  3. Don't use animations in non-immersive games (60)
  4. Use an edit mode in a table to reveal a delete component (60)
  5. Don't prompt the user to save their work (61)
  6. Don't use modals (62, 138)
  7. If you must use modals, make them occasional and simple (62)
  8. Make the launch image a copy of your home screen or something that looks closely like it (63, 168)
  9. Don't ask users to supply setup information (63, 50, 47)
  10. Lazily request input for settings / preferences information as needed (63)
  11. Eschew requiring login information until the moment you need it (63)
  12. Restore the app state of when the app was last used when the user starts the application (64)
  13. Save user data as soon as possible and as often as needed (64)
  14. Never quit an iOS application.(64)
  15. Don't have users agree to an EULA (65)
  16. Don't add features that aren't focused on the main task (65)
  17. Use a segmented control in a toolbar to display different facets of the same data (68)
  18. Use a tab bar at the bottom of a screen (UIView) to switch between different information categories (68)

iCloud

  1. Respect the user's storage quotas and keep stored data to a minimum (the user pays for storage) (72)
  2. You can store Documents and small amounts of key/value data (72)
  3. Bookmarking the last thing done in an app is a good thing to store in iCloud (72)
  4. Preference storage should be stuff applicable to all iOS devices for this app / service (73)
  5. App should work reasonably when iCloud is not available (73)
  6. Let users turn on and off iCloud storage (73)
  7. Don't make users choose which pieces of data or content get put into iCloud on an a-la-cart basis (73)
  8. Don't give users an option of storing a document on the device (no local documents) (73)
  9. Try to update content automatically unless the documents are large (73)
  10. Large documents should have user control and should indicate with a spinner or progress bar when they're being updated (73)
  11. Warn users of deleting iCloud data (that it won't be available on other devices either) (73)
  12. Tell the user when a conflict is detected in shared iCloud data as soon as possible (74)
  13. Include iCloud content in searches (74)

Multitasking

  1. Handle interruptions or audio from other applications gracefully and quickly (75)
  2. Transition from foreground to background gracefully and quickly (75)
  3. Behave responsibly when not in the foreground (75)
  4. Beware the double-high status bar. This will often cover the top bit of your app if you're not prepared for it. You can simulate the double-high status bar using the simulator. This technique is described in Tools Workflow Guid for iOS. (75)
  5. Pause activities that require attention and participation (76)
  6. Make sure your audio handles interruptions from other audio tasks and resumes appropriately (76, 89)
  7. Avoid notifications. If you notify, do it sparingly (76)
  8. When appropriate, finish user initiated tasks in the background (76)

Notifications

  1. Use Notification Center to create local and push notifications (78)
  2. A banner is a small translucent view that appears onscreen and then disappears after a few seconds (78)
  3. An alert is a standard alert view that appears onscreen and requires user interaction to dismiss (78)
  4. A badge is a small red oval that displays the number of pending notification items (79)
  5. A push notification can only push one of the notification types it's registered for (79)
  6. A banner can only display a small number of characters. Try not to truncate banner text (80)
  7. Use title style capitalization in alerts and make them short enough so they don't truncate (80)
  8. Provide a sound that users can choose to hear when notification arrives (80)
  9. You may provide a different launch image if your app was launched from an alert (80)

Printing

  1. More information on printing from your app can be found in Drawing and Printing Guide for iOS (81)
  2. Use the system-provided Action button in your toolbar or navigation bar for printing (81)
  3. Display the Print Action Button when printing is the primary function in the current context (81)
  4. You may want to allow users to select page ranges and multiple copies where appropriate (82)
  5. Don't display Print Action buttons if the device can't print (82)

iAds

  1. iPhone standard ad banners shall be 320 x 50 points (a point is 2 pixels on a retina display) (83)
  2. iPhone full screen ad banners changes depending on orientation (83)
  3. Place a standard banner view at or near the bottom of the page (83)
  4. Don't allow standard banners to scroll off the screen (88)
  5. Pause activities when users interact with ads (88)
  6. Don't stop an ad from playing (88)

Document Previews

  1. You can code for a quick preview of your document for the user even if the user can't really load the document. Supporting Quick Views of a document is covered in Document Interaction Programming Topics for iOS (88)
  2. Display a document preview in a Navigation view on the iPhone (89)

Sound

  1. The system volume controls all sound volume, not your app (91)
  2. Users expect to be able to select the audio route of sound coming from your app. Make sure you allow for this by using the MPVolumeView in your app (91)
  3. If you need to display a volume slider, be sure to use the system-provided volume silver available when you use the MPVolumeView class (91)
  4. If you only need to render sound effects that are incidental to the functionality of your app, use System Sound Services (91)
  5. If sound plays an important role in your application, use Audio Session Services (91)
  6. Audio Session Services: Select a category based on it's meaning, not its set of behaviors (92)
  7. Audio Session Services: Avoid adding a property to the audio session to modify a category's standard behavior (92)
  8. Audio Session Services: Take into account what the device is doing when choosing the audio category (92)
  9. Audio Session Services: Don't change session categories while the app is running (92)
  10. Audio Session Services: HIG goes through specific choices of category based on use case (93)
  11. Audio Session Services: Identify the type of audio interruption your app can cause (95)
  12. Audio Session Services: Respond appropriately when your app gets control back after an audio interruptions occurs (95)
  13. Audio Session Services: If your audio interruption is determined to be a resumable interruption, deactivate your audio session with a AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation (96)
  14. Audio Session Services: If your app is a non-resumable audio interruption, deactivate your audio session without any flags (96)
  15. Audio Session Services: Determine if your need to resume when an audio interruption ends (97)

Remote Control

  1. Limit your app's eligibility to receive remote control events where appropriate (97)
  2. Use system-provided controls to offer AirPlay support (97)
  3. Don't repurpose remote control events (98)
  4. VoiceOver: Custom UI components require additional work to make VoiceOver accessible for blind or low-vision users. Standard ones do not and just work out of the box (98)

Edit, Copy and Paste

  1. Check out "Copy and Paste Operations" in iOS App Programming Guide (99)
  2. Don't display cut or copy if nothing is selected (99)
  3. You should control how the edit menu appears so that important parts of the UI are not obscured by it (99)
  4. Support touch and hold plus double tap to invoke the edit menu (100)
  5. Don't make a button in your app that does what the edit menu does (100)
  6. Consider enabling the selection of static text if it might be useful to the user (100)
  7. Don't make button titles selectable (100)
  8. Combine support for undo / redo with copy and paste (100)
  9. When you need to enable actions the utilize selected text or object in a way that's external to the current context, use an Action Sheet as described on page 135 (100)

Custom Edit Menu Items

  1. Make edit items that edit, alter or otherwise act directly on the user's selection (101)
  2. List custom items after all system-provided items (101)
  3. Limit the number of Custom Edit Menu Items (101)
  4. Make them succinct and verbs. Initial-capitalize words if you have to use more than one (101)

Undo and Redo

  1. Undos, Re-dos and Cancel Undos are initiated by shaking the phone (101)
  2. Supporting undos et al are covered in "Undo Architecture" (101)
  3. Supply brief descriptive phrases to tell the user what it is they're about to un/redo (101)
  4. Avoid text that's too long (102)
  5. Don't overload the shake gesture (102)
  6. Use the system-proved Undo and Redo buttons if undo and redo buttons are fundamental tasks in your app (102)
  7. Relate undo and redo capability with the user's immediate context, not some other context (102)

Keyboards and Input Views

  1. If you create custom input views (i.e. special keyboards) for specialty input to make it easier for your users (102)
  2. You can also add keyboard accessories views which go along the top of your keyboard (103)

Location Services

  1. Make sure users understand why they're being asked to turn Location Services on (104)
  2. Check the user's Location Services preference to avoid triggering the alert unnecessarily (104)
  3. Display the Location Services when your app starts only if your app cannot perform its primary function without knowing the user's location (104)
  4. Don't make programmatic calls that could trigger the the alert before the user actually selects the feature that needs the location.

iOS UI Elements

Status Bar

  1. Changing the status bar style should only be done via the Info.plist setting (105)
  2. Don't hide the status bar unless you're writing a full-screen immersive game or watching a movie (106)
  3. Don't create a custom status bar (106)
  4. Display network activity where appropriate (106, 144)
  5. Specify the color of the status bar on the iPhone (107)
  6. Set whether a change in the color of the status bar should be animated (107)

Navigation Bar

  1. Defining a navigation bar is covered in "Navigation Controllers" and UINavigationBar Class Reference (107)
  2. The title of the current view shall be the title of the navigation bar (108)
  3. Use the system font in the navigation bar title (108)
  4. Use a toolbar instead of a navigation bar if you need a larger set of controls or you don't need navigation (108)
  5. Consider using a segmented control in a navigation bar at the top level of the application (108)
  6. Avoid additional controls in the navigation bar. You should have either a back button with a title and one other control for the view's contents or a segmented control without a title with a back button and nothing else (108)
  7. Use system-provided buttons according to their standard meaning (108)
  8. You may customize the appearance of the navigation bar (108)
  9. Make sure that a customizable back button still looks like a back button (109)
  10. Don't make a multi-segmented back button (109)
  11. Take into account the automatic change in navigation bar height that occurs when the device is rotated. Look at how UIBarMetrics is used. (109)
  12. A toolbar contains controls that perform actions related to object in the screen or view (110)
  13. Use a toolbar to give people a selection of frequently used commands that make sense in the current context (110, 150)
  14. You may customize the appearance of a toolbar (110)
  15. Use system-provided toolbar items according to their standard meaning (111)
  16. You may customize the appearance of toolbar items (111)
  17. Don't mix styles if toolbar items (111)
  18. Take into account the automatic change in toolbar height that occurs when the device is rotated. Look at how UIBarMetrics is used. (111)
  19. A tab bar gives people the ability to switch between different subtasks, views or modes (111)
  20. A tab bar is not to give users controls that act on elements in the current mode or screen (112)
  21. Use a tab bar to organize information at the application level (112)
  22. Don't remove tab elements when that function is not available, disable instead (112)
  23. Badge a tab bar icon to signal new information is associated with that mode (113)
  24. Use system-provided tab bar items according to their standard meaning (113)
  25. You may customize the appearance of tab bar items (113)
  26. If you have a custom tint for a tab bar, define a selection indicator image that's translucent (113)

Table View

  1. Check out Table View Programming Guide for iOS and UITableView Class Reference (119)
  2. Plain tables can have rows that can be separated into labeled sections and an optional index can appear vertically along the right edge (120)
  3. Grouped tables can have one or more have grouped items preceded by header and footer text and does not include an index (121)

Elements

  1. Checkmark elements indicates a row selection (121)
  2. Disclosure Indicator displays another table associated with this row (121)
  3. Detail disclosure button displays additional details about the row in a new view (121, 143)
  4. Row reorder indicates that a row can be dragged to another location in the table (121)
  5. Row Insert Add a new row to the table (122)
  6. Delete button control reveals and hides the delete button from a row when editing (122)
  7. Delete button Deletes the row (122)
  8. Default cell style UITableViewCellStyleDefault includes an optional image in the left and a left-aligned title in black (122)
  9. Subtitle cell style UITableViewCellStyleSubtitle is the same as default with a subtitle beneath the title (123)
  10. Value 1 style UITableViewCellStyleValue1 has a left aligned title with a right aligned title in blue. Don't use images with this (123)
  11. Value 2 style UITableViewCellStyleValue2 has a right aligned title in a small, blue font followed on the same line by a left aligned subtitle in a larger black font (124)
  12. Provide a list of options from which users can select (124)
  13. Display hierarchical information. (124)
  14. Display conceptually grouped information (125)
  15. Use an index to facilitate lookup, but be aware that disclosure indicators interfere with indexes (125)
  16. Provide feedback when users select an item. Highlight briefly on tap / touch (125)
  17. Animate user changes to list items (125)
  18. When table elements are complex, don't wait until all the data is available before displaying anything (125)
  19. Display stale data while waiting for new data to arrive (125)
  20. If loading is slow, provide users with a signal that processing is continuing (125)
  21. Don't have variable row heights in a plain table (126)
  22. Don't use white in areas of an image that you want to look transparent (126)
  23. If it helps users understand your app better, use a custom title for the delete button (126)
  24. Use the grouped tables for UITableViewCellStyleValue1 and UITableViewCellStyleValue2 cell styles (126)
  25. Don't truncate text labels (127)
  26. If think you need to lay out your cells in a non-standard way, create your own table style. Check out Table View Programming Guide for iOS (128)

Text View

  1. Display multiple lines of text and can be editable. You have control over the font metrics of the view but only on the entirety of the text, not parts (129)

UI Web View

  1. Used to display rich HTML content. Check UIWebView Class Reference (129)
  2. Don't use a web view to create an application that looks and behaves like a mini web browser (130)

Container View Controller

  1. This is for custom sets of child views that are navigated in a custom way. Check out UIViewController Class Reference (130)
  2. Avoid implementing Custom View Controllers (130)
  3. Make sure it works in all orientations (130)
  4. Avoid flashy view transitions (131)

Alerts

  1. Avoid creating unnecessary alerts. Guidelines are on page: (132)
  2. Titles shall be one-liners (132)
  3. Descriptions shall describe the situation and what users can do about it (132)
  4. Don't use single-word titles (133)
  5. Sentence fragments are often easier to understand than complete sentences in titles (133)
  6. Don't hesitate to be negative (really, Apple? I had no idea you were like that) (133)
  7. Don't use pronouns in your text or refer to people directly (133)
  8. Use punctuation correctly (133)
  9. Use a complete sentence in the alert text (133)
  10. Don't make alert texts long enough cause the alert to scroll (133)
  11. Don't indicate which buttons to tap by saying "tap x to do y", for instance (134)
  12. Test your alerts in all orientations (134)
  13. Use two buttons in your alert (134)
  14. In a two-button that proposes a risky action, the button that cancels the action shall be on the right and light-colored (134)
  15. In an alert button that proposes a benign action, reverse this (left and light colored) (134).
  16. Pressing the home button on an alert should auto-execute the "cancel" action button and move the app into the background (134)
  17. Use short one or two word titles on buttons that are initial capitalized. Don't use humor or pronouns. (135)

Action Sheets

  1. For displaying a set of choices related to a task initiated by a user. To use an action sheet, check out UIActionSheet Class Reference (135)
  2. Always contain at least 2 buttons (136)
  3. Coordinate its appearance with navigation bars and toolbars (137)
  4. Always include a cancel button (137)
  5. Use a red button color to provide for a potentially destructive action (137)
  6. Don't make users scroll through an action sheet (138)

Modal Views

  1. Make more sense on an iPad than an iPhone (138)
  2. Coordinate the look of the view with the appearance of your app (139)
  3. Display a title that identifies the task in question (140)
  4. Choose the appropriate transition style: Vertical, Flip and Partial Curl. Each have their reasons to choose (140)

iOS UI Controls

Activity Indicator

  1. Shows a that a task is progressing and has a spinner and an optional label. Information on implementing this can be found in UIActivityIndicatorView Class Reference (141)
  2. Don't display a stationary activity indicator (141)
  3. Use one to assure the user that a process has not stalled (141)
  4. Coordinate the size and color of it to match any customizations you may have of the background view (141)

Date and Time Picker

  1. Working with this is documented in the UIDatePicker Class Reference (142)
  2. Has 4 modes. Date and time, Time, Date and Countdown Timer (142)
  3. You may want to coarsen the minutes part of the picker to, say, quarter or half hour intervals if it makes sense (143)

Detail Disclosure Button

  1. Check out UITableViewCellAccessoryDetailDisclosureButton information in UITableViewCell Class Reference (143)

Info Button

  1. For revealing config details about an app, typically on the back of the current view. More on this is in the UIButton Class Reference (143)
  2. Use this to flip the screen and reveal more information and / or config options (144)

Label

  1. Used to display Static Text, keep it simple, not fancy. Details covered in UILabel Class Reference (144)

Network Activity Indicator

  1. Appears in the status bar and shows that network activity is occurring (144)
  2. Use UIApplication networkActivityIndicatorVisible to control the indicator's visibility (145)

Page Indicator

  1. Shows how many views are open and which one is currently visible (145)
  2. Don't use it in conjunction with hierarchical views, only sequential views (145)
  3. Vertically center a page indicator between the bottom edge of an open view and the bottom edge of the screen (145)

Picker

  1. Displays a set of value from which the user picks one (146)
  2. Consider using a table view instead if you have a large number of values to choose from (146)
  3. Use the translucent selection bar to display contextual information (146)

Progress View

  1. Shows progress of a task or process that has a known duration (147)
  2. Comes in two styles, default and bar (147)
  3. Default is best for main content areas (147)
  4. Bar is best suited for toolbars (147)
  5. You may customize the appearance of the progress bar (147)

Rounded Rectangle Button

  1. Performs an app-specific action. Check out UIButton Class Reference (147)
  2. Use title-style (initial cap) capitalization for button titles. Don't make it too long that it truncates (148)

Scope Bar

  1. Allows a user to define the scope of a search. Only available in conjunction with a search bar (148)
  2. Check out UISearchBar Class Reference and UISearchDisplayController (148, 149)

Search Bar

  1. Accepts text for use in search (149)
  2. Optional elements are: PLaceholder text, Bookmarks button, Clear button, a Prompt title and Results list icon (149)
  3. A linear set of segments each of which functions as a button that can display a different view (150)

Segmented Control

  1. Make sure each segment is easy to tap (150)
  2. Maintain consistency in the size of each segment (151)
  3. Don't mix text and images in a segmented control (151)
  4. You may customize the appearance of a segmented control (151)

Slider

  1. Allows for users to make adjustments in a range. Check out UISlider Class Reference (151)

Stepper

  1. Allows for users to increase or decrease a value by a constant amount (152)
  2. Make it obvious which value a stepper affects (152)

Switch

  1. Manipulates a mutually exclusive choice or state (used in table views only). Check out UISwitch Class Reference (153)
  2. You may customize the appearance of a switch (154)

Text Field

  1. Accepts a single line of user input. Check out UITextField Class Reference (153)
  2. Customize it only if it helps the user understand how they should use it (154)
  3. Display the Clear button in the right end of the text field when appropriate (154)
  4. Display a hint in the text field if it helps the users understand its purpose (154)
  5. Specify different keyboards for different types of content. Checkout "Managing the keyboard" in iOS App Programming Guide (155)

iOS UI System-provided Elements

  1. Consist of the following. Action, Camera, Compose, Bookmarks, Search, Add, Trash, Organize, Reply, Stop, Refresh, Play, FastForward, Pause, Rewind. Each of these is one of UIBarButtonSystemItem. Check out UIBarButtonItem Class Reference (156)
  2. Consist of the following: Edit, Cancel, Save, Done, Undo, Redo for use in navigation bars and toolbars (157)
  3. You may also use the page curl in a toolbar, but not in a navigation bar. Don't use the page curl button to flip the screen, use the info button instead (143, 157)
  4. The following icons are OK to use in a tab bar: Bookmarks, Contacts, Downloads, Favorites, Featured, History, More, MostRecent, MostViewed, Recents, Search, TopRated. Don't use an icon for other than it's intended purpose as stated in the HIG. Check out UITabBarSystemItem in UITabBarItem Class Reference to find out how to specify them. (52, 158)

iOS UI System-provided table row buttons

  1. ContactAdd allows you to add a contact to a table item (159)
  2. DetailDisclosure Display a new view that contains details about the current item. It can be used outside of tables, though (119, 159)
  3. Info flips to the back of the view to display config options or more information (159)
  4. Don't deviate from their pre-defined meanings / intended uses (159)

iOS UI Custom Icon and Image Creation Guidelines

  1. These are the specifications. If you are customizing an element (and you shouldn't be), you should read page 160 and 161 in the HIG to make sure you're doing it in an acceptable way to Apple. (160, 161)
  2. For best results, enlist the help of a professional graphic designer (162)
  3. Use universal imagery people will recognize. Embrace simplicity. (162)
  4. Use color and shadow carefully (162)
  5. Don't use "greek" text or wavy lines to indicate text (163)
  6. Avoid using a photo instead use an idealized version of the object of the icon (163)
  7. Don't use existing iOS images in your artwork (163)
  8. Portray the materials of your icon's object realistically. Don't make everything look like it's made out of plastic. (163)
  9. Use transparency where it makes sense (163)

Retina Display

  1. Items should be the following. Richer in texture, More detailed, More realistic (164)
  2. You can scale up your original artwork 200% using nearest neighbor algorithm and or add detail and depth (164)
  3. Consider softening scaled up elements (165)
  4. Consider adding blur for engraving or drop shadows (165)

iOS UI Application Icons

  1. Your app icon should have two version: one 72 x 72 and one 114 x 114 (166)
  2. Your app icon should have the following characteristics: Has 90 degree corners. Does not have a drop shadow, Does not have a shine or gloss (unless you've set it not to render this in the Info.plist of your app). Does not have an alpha transparency (167)
  3. Give your icon a discernible background, not a transparent one (168)
  4. Don't play with translucency in your icon, make sure it extends to the border of the image area (167)
  5. Create a large version of your app icon for the app store: a 512 x 512 version and a 1024 x 1024 version (168)

iOS UI Launch Image

  1. Your launch image should look like your first screen, not a splash screen, a branding screen or an about window. Avoid text or components that can change in this image. Include the status bar. Check out the image examples on 170 (169, 170)
  2. Two versions: 320 x 480 and 640 x 960. (169)

iOS UI Small Icons

  1. Small icons are used by search and settings. The sizes are: 29 x 29 and 58 x 58 (171)

iOS UI Document Icons

  1. Used for custom documents if your app creates them. They're rendered from your app icon by default. Check out the examples on page 172 (171-2)
  2. Customizing: You can make your own document icons. The sizes are 22 x 29 and 44 x 58. Check out the examples on 172. (172)

iOS Misc Icons

  1. Icons for Nav Bars, Toolbars and Tab bars: If you plan on making your own (and you shouldn't: you should be using the system-provided ones) see page 176 for this (176)
@leyink
Copy link

leyink commented Mar 6, 2015

Thank you so much for doing this! It's perfect and really needed.

@nickbauman
Copy link
Author

You're welcome! I did this because the original HIG was close to 200 pages which takes days to go through. Today, I think it needs updating but Apple no longer has a single place where all this information exists (i.e. there is no official HIG document anymore).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment