Boarding pass Live Activity ignores localized destinationCityName — "Willkommen bei Munich" on de_DE device

Platform: iOS 26.5 · PassKit (semantic boarding pass)

Summary

When a .pkpass boarding pass uses the iOS 26 upgraded semantic format (preferredStyleSchemes: ["semanticBoardingPass", "boardingPass"]) for a real, scheduled flight that Apple's live flight data feed recognizes, the Wallet Live Activity (Lock Screen, Dynamic Island, and Wallet card "Welcome to …" copy) renders the destination city name in English, regardless of the value supplied in semantics.destinationCityName or the device's locale.

On a German-locale iPhone, a flight arriving at MUC produces the grammatically broken string "Willkommen bei Munich" — German system-supplied prefix concatenated with the English city noun from Apple's flight data, instead of the expected "Willkommen in München".

Steps to reproduce

1. Build a .pkpass for any real, currently-scheduled flight whose destination city has a German-language variant (e.g. SK2657 CPH→MUC, 4Y1261 HER→MUC).

2. Populate semantics with full iOS 26 fields including:

   "destinationAirportCode": "MUC",
   "destinationAirportName": "München",
   "destinationCityName":    "München",
   "destinationLocationDescription": "Flughafen München Franz Josef Strauß"
   

3. Install on an iPhone running iOS 26.1+ with Language: Deutsch, Region: Deutschland.

4. Open the pass within Wallet's live-activity window.

Expected: "Willkommen in München"

Actual: "Willkommen bei Munich"

What I believe is happening

Apple's live flight data feed overrides the destinationCityName semantic tag with an English-only value sourced from the feed (presumably IATA / OAG). The iOS 26.1 liveDataConfiguration.excludedSemantics allow-list does not include destinationCityName or destinationAirportName, so there is currently no developer-side mechanism to either:

• submit a localized destination city, or
• opt out of the override while keeping live updates active.

The PassKit destinationCityName schema is typed as a plain localizable string (single value), with no translations variant comparable to what some third-party pass APIs expose. The "localizable" annotation in the docs is misleading for this field, because pass.strings lookups are not applied to semantic values once the live flight feed supplies them.

What I'd like to know

1. Is this the intended behavior, or is destinationCityName missing from the documented excludedSemantics allow-list by omission rather than design?
2. Is there a supported way for an airline (or a developer issuing passes on an airline's behalf) to ship localized destination city names that survive the live-data merge?
3. If neither (1) nor (2): is there an intent to either localize Apple's flight-data city tokens by device locale, or expand excludedSemantics to cover destination/departure city + airport names in a future iOS 26.x release?