├── .editorconfig ├── .gitattributes ├── .github └── funding.yml ├── contributing.md ├── license └── readme.md /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | indent_style = tab 5 | end_of_line = lf 6 | charset = utf-8 7 | trim_trailing_whitespace = true 8 | insert_final_newline = true 9 | -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | * text=auto eol=lf 2 | *.ai binary 3 | readme.md merge=union 4 | -------------------------------------------------------------------------------- /.github/funding.yml: -------------------------------------------------------------------------------- 1 | github: sindresorhus 2 | -------------------------------------------------------------------------------- /contributing.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | **Open an issue for discussion before submitting a pull request.** 4 | 5 | ## Issue 6 | 7 | - Should be well written and reasoned. 8 | - Include any prior art. 9 | - Answer how Apple's apps handle it. 10 | 11 | ## Pull request 12 | 13 | - Submit a Feedback Assistant report about it (also [here](https://github.com/feedback-assistant/reports)). The eventual goal is for this project to make itself obsolete. 14 | - Do your best. High-quality is expected. 15 | - Check grammar. 16 | - Include images. 17 | - Link to relevant apps. 18 | -------------------------------------------------------------------------------- /license: -------------------------------------------------------------------------------- 1 | CC0 1.0 Universal 2 | 3 | Statement of Purpose 4 | 5 | The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work"). 6 | 7 | Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others. 8 | 9 | For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights. 10 | 11 | Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following: 12 | i. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work; 13 | 14 | ii. moral rights retained by the original author(s) and/or performer(s); 15 | 16 | iii. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work; 17 | 18 | iv. rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below; 19 | 20 | v. rights protecting the extraction, dissemination, use and reuse of data in a Work; 21 | 22 | vi. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and 23 | 24 | vii. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof. 25 | 26 | Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose. 27 | 28 | Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose. 29 | 30 | Limitations and Disclaimers. 31 | 32 | a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. 33 | 34 | b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law. 35 | 36 | c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work. 37 | 38 | d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work. 39 | 40 | For more information, please see https://creativecommons.org/publicdomain/zero/1.0 41 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # Human Interface Guidelines Extras 2 | 3 | > Community additions to Apple's Human Interface Guidelines 4 | 5 | Apple's [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) are amazingly well done. However, there are many details they don't clearly specify. This is an attempt to document the best conventions and patterns in the community. 6 | 7 | **[Contribute →](contributing.md)** 8 | 9 | ## Contents 10 | 11 | - [macOS](#macOS) 12 | - [iOS](#ios) 13 | - [watchOS](#watchos) 14 | - [tvOS](#tvOS) 15 | 16 | ## macOS 17 | 18 | ### Don't remove default menu items 19 | 20 | When you create a new macOS app project in Xcode, it includes a main menu with a lot of items. You might be tempted to remove stuff you don't need. For example, I have seen many apps remove “Undo” and “Redo” because their app doesn't support that. This is usually because they don't realize how the [responder chain](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html) works. I made this mistake myself. 21 | 22 | The reason you should not remove such menu items is that you cannot foresee what will need it. For example, if your app has a way to save a file, the filename text field in the save panel supports undo/redo and the “Undo” menu item works when the text field is key (focused). Another example, my [Black Out](https://sindresorhus.com/black-out) app has a “Quick Action” extension, and if the user runs it from Finder, the extension is able to use Finder's “Undo” and “Redo” menu items. 23 | 24 | So what default menu items can be removed? 25 | 26 | - The `Settings` menu item in the app menu. 27 | - All menu items in the `File` menu except for `Close`. 28 | - `Find` and the below menu items in the `Edit` menu if your app doesn't include text editing. 29 | - The `Format` menu. 30 | - The toolbar and sidebar menu items in the `View` menu if your app doesn't need those. 31 | 32 | ### Settings window 33 | 34 | - Use `Form` with `.formStyle(.grouped)`. Group controls with `Section`. 35 | - The window should not be translucent. 36 | - The minimize and maximize traffic light buttons should be disabled, but not removed. 37 | - The “General” tab should use the `gearshape` symbol (not `gear`). 38 | - The “Advanced” tab should use the `gearshape.2` symbol. 39 | - You should not have license or update functionality there. Nor should you have an "About" tab. It's a **settings** window. 40 | 41 | [Learn More](https://developer.apple.com/design/human-interface-guidelines/patterns/settings/#macos) 42 | 43 | ### Drag and drop files 44 | 45 | If your app has a drag and drop target for files, don't forget to also make it possible to click the drop area to open files through an open panel instead of dragging. Alternatively, add an “Open” button inside the drop target. 46 | 47 | ### “Always on top” functionality 48 | 49 | 50 | 51 | You might want to let the user set your app's window to always be on top. You can find this behavior in the Simulator app. 52 | 53 | The menu bar item that toggles this functionality should be named “Stay on Top” and should be in the “Window” menu below “Enter Full Screen”, or if it's not there, below “Tile Window to Right of Screen”. 54 | 55 | The setting should be persisted in `UserDefaults`. 56 | 57 | When enabled, the window should be set to `window.level = .floating`. 58 | 59 | ### Include an Internet Access Policy 60 | 61 | If your app needs to access the internet for any reason, I would strongly recommend including a [Internet Access Policy](https://www.obdev.at/iap/index.html). This lets firewall apps present to the user what and why your app needs access to. It also makes it more likely the user will grant access. 62 | 63 | [Example policy.](https://github.com/sindresorhus/Gifski/blob/main/Gifski/InternetAccessPolicy.json) 64 | 65 | ### Number text field convenience 66 | 67 | If your app has a text field where the user can set a number, for example, for the width of something, make it convenient to increase/decrease the number. 68 | 69 | 1. Place a [stepper control](https://developer.apple.com/design/human-interface-guidelines/macos/selectors/steppers/) on the right side of the text field. 70 | 2. When the text field is focused, make it possible to use arrow up/down keys change the number by 1. 71 | 3. If the user also holds down the Option key, change the number by 10. 72 | 4. If the user reaches a lower or upper limit, shake the text field contents to indicate that. 73 | 74 | You can find a real-world example of this in my [Gifski app](https://github.com/sindresorhus/Gifski) (missing the stepper though) ([source](https://github.com/sindresorhus/Gifski/blob/8ff31b387338b43f0c91cd481b3ebe0a4741b208/Gifski/IntTextField.swift)). 75 | 76 | [Read more about text fields.](https://developer.apple.com/design/human-interface-guidelines/macos/fields-and-labels/text-fields/) 77 | 78 | ## iOS 79 | 80 | ### Settings sheet dismiss button 81 | 82 | 83 | 84 | The most common conventions I have seen for a settings sheet dismissal button is either a “Done” button on the right side (primary position) of the navigation bar or an [“X” icon](https://twitter.com/sindresorhus/status/1317548489463762945/photo/2) on the left side (navigational position). 85 | 86 | There are several benefits to using a “Done” button on the right side: 87 | 88 | - Apple does that in most apps. You cannot go wrong following what Apple does. 89 | - “Done” has a larger tap target. 90 | - Friendlier. An “X” might make people think the settings will not be saved. 91 | - Easier to reach for right-handed people, the majority. 92 | - An informal [Twitter poll](https://twitter.com/sindresorhus/status/1317548882054742016) tells us that most users prefer this. 93 | 94 | What you should definitely not do: 95 | 96 | - “Done” button on the left side. 97 | - “Cancel” button on either side. 98 | - “Dismiss” button on either side. 99 | 100 |
101 | Click here to see how you correctly do a settings screen in SwiftUI. 102 | 103 | ```swift 104 | struct SettingsScreen: View { 105 | @Environment(\.dismiss) private var dismiss 106 | 107 | var body: some View { 108 | NavigationStack { 109 | Form { 110 | Section("Unicorn") { 111 | // … 112 | } 113 | } 114 | .navigationTitle("Settings") 115 | .navigationBarTitleDisplayMode(.inline) 116 | .toolbar { 117 | // Note that it's `.confirmationAction` and not `.primaryAction`. 118 | ToolbarItem(placement: .confirmationAction) { 119 | Button("Done") { 120 | dismiss() 121 | } 122 | } 123 | } 124 | } 125 | } 126 | } 127 | ``` 128 |
129 | 130 | ### Settings sheet title 131 | 132 | People seem [undecided](https://twitter.com/sindresorhus/status/1317557474677882889) on whether to use a normal or large navigation bar title for a settings sheet. 133 | 134 | [Discuss →](https://github.com/sindresorhus/human-interface-guidelines-extras/issues/1) 135 | 136 | ## watchOS 137 | 138 | *Nothing yet* 139 | 140 | ## tvOS 141 | 142 | *Nothing yet* 143 | --------------------------------------------------------------------------------