I figured it out. It seems that when all English strings are provided via NSLocalizedString's value argument, en.lproj is not created. In fact, when mixing localized strings with and without default values, only those that have no default value are included in the final app's en.lproj/Localizable.strings. Still, when running the app, the default value is correctly presented, so I guess since it's not in the strings file it is hard-coded in the executable. Maybe I'm not supposed to use the value argument this way? Should I instead cut all the default values and insert them manually in the string catalog? I was already considering to move all English values for my other projects from the string catalog to the source code so that I directly know what a localized string's contents are, but I'm happy now I didn't do that yet. I created FB21733395.

The rows in the English column all contain black text, which is the text passed as the value argument to NSLocalizedString(_:value:comment:). The app also runs in English if I select it in the Xcode scheme editor.

The submitted app does indeed miss a en.lproj folder. How do I know if I'm using a string catalog? Isn't having Localizable.xcstrings enough? These are the project settings filtered by "catalog", they are the same for the other projects that show the correct languages on the App Store: The target build settings filtered by "catalog":

Thanks, that works. If not for this, what is UIAction.Identifier.pasteAndMatchStyle used for?

I created FB9832605 in January 2022 titled "Dragging folder onto Simulator causes permission error", but after answering some initial questions it never went forward. Though it displays "Recent Similar Reports: Less than 10".

Recently two users of my apps reported the same issue happening on macOS 15.7.2. Will it be fixed on both macOS 26 and 15?

Another user of my apps just reported the same issue again on macOS 15.7.2.

I don't have a bug number. I only got an email from a user who said they have this issue on macOS 15.7.2, that's all.

I created FB21290658.

A user of my app just reported the .nofollow issue and they have macOS 15.7.2. Until now this issue seemed to be related to macOS 26. Do you know if a fix is planned for macOS 15 as well?

While this issue is extremely annoying, I have no hope that it will ever be fixed. More than 5.5 years have passed since I filed my bug.

Just for the record, I've opened a separate post about the issue I mentioned above: Security-scoped bookmarks to external volumes are resolved to /

[quote='865462022, DTS Engineer, /thread/798402?answerId=865462022#865462022'] I'm not sure. [/quote] Luckily one of those users is a programmer and already ran a test project for me, confirming that the issue is related to bookmark resolution. Is there anything I can ask them to do to understand this issue better? I opened TSI 16931637 in case it helps.

So to summarize: 26.0 shipped with a bug, which evolved to an even more annoying bug in 26.1 which is supposedly fixed in 26.2 beta. I wish Apple considered issuing a fast patch rather than waiting for months until the next minor release, because this is affecting many users already, and we're only 1 week into 26.1 official release. So I'll have to reply to emails by frustrated users for another couple months...? Unfortunately users of my different apps also started reporting another issue that could be related: paths on an external volume, such as one mounted by "NTFS for Mac", or a path on a Synology volume, are "converted" to / (Macintosh HD) after going through laundry. Could someone at Apple confirm whether this is also a known issue? I wasn't sure if I should report this here or in my recent post.

Thanks for your input. I had a look at your link but got lost quite quickly, though I may get back to it if I get really desperate. The user had mentioned that they use a non-admin account, but I had discarded that fact as irrelevant. After your mention of "take a URL provided from an open panel and launder it through a bookmark before use" I felt inspired to create a non-admin test account and I was actually able to reproduce the issue. I originally wrote that when scanning a folder selected in an open panel it doesn't resolve any bookmark, but looking at the code again it turns out I was already doing that "URL laundry". What's even more interesting, I tried skipping the laundry (which would resolve the bookmark to a URL whose path property is /.nofollow) and when scanning the URL returned from the open panel directly (whose path property is /), the issue doesn't happen! Can someone at Apple confirm whether this is expected behaviour or what I have to do so that scanning a URL resolved from bookmark data behaves the same as scanning a URL returned from an open panel?