In order to do less typing I set the working directory to the Resources directory in the help bundle, using the chdir pathname command. I use the command: hiutil -Cf Resources/English.lproj/help.helpindex English.lproj This creates a help.helpindex file in the English.lproj folder. As per the documentation the other html files are in a sub directory. To be sure that I'm not looking at a cached version of the application's help I use the terminal command: rm -rf ~/Library/Caches/com.apple.help* The name of the help.helpindex file is in the help bundle's info.plist file in the HPDBookIndexPath dictionary. My application's help is still not searchable. Only the main help page is searchable. When I open the index file with BBEdit I see lots of keywords from the other html files but the Help application won't find them. Using the parameter -Caf doesn't help. it's likely that I need some other file specifier but I can't see what it would be.

Based on posts I found, with newer versions of the OS you have to create an index using the hiutil command in the terminal. The type of index file created by the indexer application won't work. Of course this is completely undocumented. hiutil can create two types if index files. Supposedly you have to create the type that's used by Spotlight. The documentation mentions hiutil and hiutil(1). Although I have been programming the Mac since 1988 I have absolutely no idea of how to use terminal commands so when I type man hiutil into the terminal it's just complete ishcabibble to me. Computers with GUIs were invented so you wouldn't have to deal with very complex command line programming. It seems ironic that I would have to learn ANOTHER very complex technology just to create one file in my application. If anyone has any guidance about what terminal command to enter I'll try it, otherwise I won't bother.

Update: Apple is still telling developers to include a Help Book in its User interface guidelines, BUT: Apple help viewer is buggy - some things don't even work. The documentation is terrible and hasn't been updated since a minor change - IN 2013! The Help indexer application is terrible and is from 2015. It is no longer available from Apple. If Apple wants to get rid of Help Books it should just tell us. This is a terrible way to do it and this is a terrible way to treat developers.

The keys in the .plists are displayed differently in XCode than they actually are in the file. For example when you open the application’s .plist in Xcode it shows the CFBundleHelpBookName as Help Book Name. This is not helpful. In the Apple Help Programming Guide these are given as their actual names in the <key> fields so I advise you to open and edit them with an external editor like BBEdit. The CFBundleHelpBookFolder should be appname.help (name of the help bundle). The CFBundleHelpBookName should be the title of the Help Book as it is in the Apple Title meta tag in the home page of the Help Book as it is in the illustration, NOT com.mycompany.appname.help as it says in the text. Because Help Books are cached you will have to clear the cache every time you edit the Help Book with the terminal command rm -rf ~/Library/Caches/com.apple.help* The Apple Help Programming Guide is poor and out of date. An example of how to add a Help book to your application can be found on GitHub: https://github.com/Red-Menace/RubyMotionRonin/tree/master/Help%20Book%20Sample. The Help Indexer application you can download from Xcode Additional Tools is terrible: It can’t open files in a bundle so you have to create your Help Book as a folder and rename it as a .help when you’re done, before adding it to your .xcodeproj. I can follow the instructions to give my application a Help Book but I want it to be searchable. After many hours of trying I find that it’s impossible to do it. The guide says to put the .helpindex in the localized .lproj folder and include its name in the Help Book’s info.plist in the HPDBookIndexPath key. This doesn’t work. Adding a Help Book to a Mac application has been a real PITA for years. This is something that Apple should improve.