Hook links to files are designed to be resilient to being moved and renamed and refactored, but there are limitations.
Hook uses both file path and file reference to maintain links to files.
The file reference is a persistent system UUID which Hook uses to link to a file even if it is renamed and moved around. So if you rename a file in Xcode or move the project folder around, links won’t be broken.
A file reference can be broken if a file is deleted and recreated. Some applications (not Xcode) do this when they save a file, replacing instead of amending existing files. So Hook uses file path to maintain links in case a file’s reference changes.
The only time you should expect links to break is if something happens to simutaneously delete a file and recreate it with a new name.
E.g. if you move a file (⌘drag) to a different drive or partition it changes the path and technically creates a new file, with a new reference, which Hook will not recognize as the same.
Or using git to check out a commit which changes the name of a file. Git handles that by deleting the old file and creating a new file with the new name, instead of just renaming the existing file.
Aside from those cases though, Hook links are very reliable. Refactoring source and renaming classes in Xcode, as you describe, is no problem. Even git is fine in 99% of cases, its only a problem when an operation changes the path and the file reference of a file at the same time.