Hello, I am facing a validation error when uploading a macOS app with a Network Extension. The Error: Invalid system extension. The system extension at “[T] TEXT.app/Contents/Library/SystemExtensions/company_name.network-extension.systemextension” resides in an unexpected location. The Problem: Validation fails only when the app's Product Name contains square brackets: [T] TEXT. If I remove the brackets from the Product Name, validation passes. What I've tried: Setting Product Name to TEXT (without brackets) and CFBundleDisplayName to [T] TEXT. Cleaning Derived Data and rebuilding the archive. Verified that the extension is physically located at Contents/Library/SystemExtensions/. It seems the Apple validation tool fails to parse the bundle path correctly when it contains characters like [ or ]. Question: How can I keep the app name with brackets for the user (in System Settings and Menu Bar) while ensuring the Network Extension passes validation? Is there a way to escape these characters or a specific Info.plist configuration to satisfy the validator?"
You should definitely file a bug against the App Store validator. There’s nothing fundamentally wrong with using square brackets in your app name.
Please post your bug number, just for the record.
On the workaround front, the idea of setting your app’s on-disk name to something without the square brackets and then applying the square brackets at the display level seems reasonable. However, it’s not as simple as setting CFBundleDisplayName. Rather, you have to go through the localisation subsystem.
macOS does support localised app names but there are complications:
- The bundle name (
CFBundleName) must match the file name on disk (without the.appextension, obviously) [1]. - If they do match, it checks for
LSHasLocalizedDisplayName. - And if that’s set, it tries to get the localised version of
CFBundleDisplayName.
Note There are further complications related to CFBundleDisplayName, but I didn’t explore those in depth. My goal was just to get anything to work (-:
So, consider this app:
% plutil -p Test817684_3.app/Contents/Info.plist
{
…
"CFBundleExecutable" => "Test817684_3"
…
"CFBundleName" => "Test817684_3"
…
"LSHasLocalizedDisplayName" => true
…
}
% plutil -p Test817684_3.app/Contents/Resources/en.lproj/InfoPlist.strings
{
"CFBundleName" => "Test817684"
}
% plutil -p Test817684_3.app/Contents/Resources/de.lproj/InfoPlist.strings
{
"CFBundleName" => "TEST817684"
}
Its on-disk name has the _3 suffix [2]. It’s non-localised CFBundleName matches that. It has LSHasLocalizedDisplayName set. And it has English and German localised variants of that.
I put this app on a test VM (running macOS 26.3) and saw these results:
- English users got
Test817684, from theenlocalisation. - German users got
TEST817684, from thedelocalisation. - Spanish users (so, matching no localisation) got
Test817684, that is, the same as English users.
One thing to note here is that I removed the CFBundleDevelopmentRegion property. I found that its presence, set to en naturally, prevented the system from honouring the value in en localisation. That kinda makes sense when you think about how base localisation is meant to work, but it removing that property doesn’t really sit well with me.
None of this is much fun, which I why I consider it just a workaround.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] If they don’t match, macOS assumes that the user has renamed the app, and displays it verbatim.
[2] Because this was my third attempt at getting this to work O-: And that includes two bug reports:
- Document how to localise
Info.plistproperties (r. 172204115) - Document
LSHasLocalizedDisplayName(r. 172373774)