I have MSL .metal files generated by a parser that go into a blue reference folder. Xcode barely highlights "half" and "return" in purple and nothing else. .metal files that are included in project have blue and other highlights.
It's also quite limiting that VSCode has hlsl and a metal plugin, but Xcode doesn't syntax highlight my source HLSL files that I generate the .metal files from. This is quite common to go from HLSL or spirv back to MSL, since there is no path from MSL to spriv.
Also setting C source, C++ source, Metal source, OpenGL Shading Language on the .hlsl makes no difference. I at least get some highlighting on includes that are set to "Default - C header". The .metal file is set to "Default - Metal Shading Language" but doesn't syntax highlight properly as described above.
blue reference folder
As I understand you got this by adding the directory in your project and choosing "Create folder reference" rather than "Create groups". When doing this, the folder is added in the project hierarchy for easy access from Xcode but is not part of any target, not indexed (so only very basic autocompletion) and consequently lacks highlighting.
Unless you make your files belong to a target (thus choosing "Create groups" when adding the folder) I guess you'll only have this limited experience.
Contrast this with VSCode that highlights any .metal or .hlsl file or containing folder dropped onto it. The files are in the project. They are just not a part of the build. The files are a result of what the CLI tools build.
Also limiting that console can’t click through to error file/line like every other IDE. The console cannot jump to files or url links.
I added a dummy xcodeproject and add the files to that project and even that doesn't help. I use the syntax highlighting for metal even though I have source hlsl files. These have u/int, float, half elements that are valid MSL types. These should be highlighted but are not. It's like Xcode tries to parse them as MSL, but fails, and then doesn't highlight anything. Syntax highlighting should be simple name lookup and coloring at a basic level. It shouldn't need complex parsing. Also the plugin architecture for the editor seems undocumented, but there are few brave souls that reverse engineered it for lua/typescript. A code editor shouldn't be this hard to use and extend.
I finally got the dummy project to print warnings/errors from running the CLI tool. Quinn had posted a message 7 years ago on the forums, but printf needs the following format. This doesn't fix the lack of syntax highlighting, but at least does provide error clickthrough.
/AbsolutePath/filename.metal:12: error: mesage
/AbsolutePath/filename.metal:12: warning: mesage
Log_Error("%s:%d: %s: %s\n", m_fileName, m_lineNumber, isError ? "error" : "warning", buffer);