如何通过Fastlane脚本为Xcode添加本地化语言（多Target场景）

Got it, let's work through this problem together. You need to add your existing English localization strings to Target B only during development, while making sure they never show up in your App Store builds. Here are a few practical, easy-to-implement solutions tailored to your setup:

1. Use a Dev-Only Localization File + Conditional Compilation #

This approach keeps your production and dev localization files separate, with clear control over which gets included:

• First, duplicate your existing English Localizable.strings file and rename it to something like Localizable-Dev.strings (so it's obvious it's for development only).
• Add this new file to Target B in Xcode, then tweak its build settings to only copy it during Debug builds:
  1. Go to your project settings > select Target B > navigate to the Build Phases tab.
  2. Expand the Copy Bundle Resources section, find Localizable-Dev.strings, and double-click its "Condition" column.
  3. Enter $(CONFIGURATION) == Debug to restrict it to Debug builds.
• Update your string-reading logic to switch between files based on build mode. For example, in Swift:

  func getLocalizedString(for key: String) -> String {
      #if DEBUG
          guard let devBundlePath = Bundle.main.path(forResource: "Localizable-Dev", ofType: "strings"),
                let devBundle = Bundle(path: devBundlePath) else {
              return NSLocalizedString(key, comment: "")
          }
          return devBundle.localizedString(forKey: key, value: nil, table: nil)
      #else
          return NSLocalizedString(key, comment: "")
      #endif
  }
  

  Debug builds will pull from the dev English file; Release builds stick to your original non-localized strings.

2. Leverage Xcode Configurations for Target Membership #

If you prefer not to modify code, use Xcode's configuration-specific target membership:

• Create a dedicated Debug configuration for Target B (e.g., Debug-B) if you don't already have one. Go to Project Settings > Info > Configurations and duplicate the existing Debug config.
• Add a custom compile macro to this Debug config: go to Target B's Build Settings > search for "Swift Compiler - Custom Flags" (or "Other C Flags" for Objective-C) > add -DINCLUDE_ENGLISH_LOCALIZATION under the Debug-B config.
• Select your original English Localizable.strings file, open the File Inspector on the right, and adjust its Target Membership for Target B: uncheck all Release configs, and only check the Debug-B config.
• Xcode will automatically include the English file in Debug-B builds and exclude it from all Release builds—no code changes needed.

3. Auto-Manage Files with a Build Script #

For hands-off control, add a run script to handle copying/removing the English file based on build type:

• Go to Target B's Build Phases tab, click the + button > select New Run Script Phase.
• Move this script phase after the "Copy Bundle Resources" phase, then paste this script (update the source path to match your actual English strings file):

  # Replace the source path with your actual English Localizable.strings location
  ENGLISH_STRINGS_PATH="${SRCROOT}/YourProject/Resources/en.lproj/Localizable.strings"
  BUNDLE_ENGLISH_DIR="${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/en.lproj"
  
  if [ "${CONFIGURATION}" = "Debug" ]; then
      # Create the en.lproj directory if it doesn't exist
      mkdir -p "${BUNDLE_ENGLISH_DIR}"
      # Copy the English strings into the bundle
      cp "${ENGLISH_STRINGS_PATH}" "${BUNDLE_ENGLISH_DIR}/Localizable.strings"
  else
      # Delete the English localization directory from the bundle in Release builds
      rm -rf "${BUNDLE_ENGLISH_DIR}"
  fi
  

Quick Sanity Check #

Before submitting to the App Store, always do an Archive build and verify: right-click the archive > Show in Finder > right-click the .xcarchive file > Show Package Contents > navigate to Products/Applications/YourApp.app > right-click > Show Package Contents. Make sure there's no en.lproj folder present.

内容的提问来源于stack exchange，提问作者JimmyJammed