Fixing "Build Input File Cannot Be Found" in iOS Archive Builds

If you've ever tried to archive an iOS app for TestFlight or release, only to be stopped by a cryptic build error that never appears during development, you're not alone. One of the more frustrating issues involves resource bundles and the Swift Standard Libraries.

In this post, I'll walk you through a specific case where the build fails with error: Build input file cannot be found, explain why it happens, and provide a robust programmatic fix for your Podfile.

The Symptoms

The issue typically manifests only during the Archive process (Release configuration). You might see an error message resembling this:

error: Build input file cannot be found: 
'.../UserMessagingPlatformResources.bundle/UserMessagingPlatformResources'

This error often flags resource-only targets, such as:

• GoogleUserMessagingPlatform-UserMessagingPlatformResources
• GoogleMobileAdsResources
• Other CocoaPods-generated resource bundles

Root Cause Analysis

To understand the fix, we first need to understand the failure.

1. Resource Bundles Are Not Binaries: The failing targets are defined as Resource Bundles (com.apple.product-type.bundle). Their sole purpose is to hold assets like images, strings, and xibs. Crucially, they do not contain a compiled binary executable.

2. The Misguided Build Phase: The build system is attempting to run the "Copy Swift Standard Libraries" build phase on these resource bundles. This phase uses a tool called swift-stdlib-tool to scan a binary, determine which Swift libraries it needs, and embed them.

3. The Conflict: Since a resource bundle has no binary executable to scan, swift-stdlib-tool looks for an input file that simply doesn't exist. This triggers the fatal error: Build input file cannot be found.

4. Why Now?: This usually happens when the ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES flag is globally set to YES in your project settings, or when CocoaPods inadvertently applies this rule to all targets, including those that don't need it.

The Solution

Manually changing build settings for Pod targets is temporary—they'll be overwritten the next time you run pod install. The correct, permanent solution is to use a post_install hook in your Podfile to programmatically adjust the settings.

We need to iterate through all targets, identify which ones are resource bundles, and strictly disable the Swift embedding logic for them.

The Fix

Add the following code block to the post_install section of your Podfile (usually found in ios/Podfile or native/engine/ios/Podfile depending on your project structure):

post_install do |installer|
  installer.pods_project.targets.each do |target|
    # Filter: Apply only to resource bundles
    if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
      
      # Action 1: Explicitly disable the Swift Embedding Build Setting
      target.build_configurations.each do |config|
          config.build_settings['ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES'] = 'NO'
      end

      # Action 2: Remove the "Copy Swift Standard Libraries" Build Phase
      target.build_phases.each do |phase|
          if phase.respond_to?(:name) && phase.name == "Copy Swift Standard Libraries"
              phase.remove_from_project
              puts "Removed Copy Swift Standard Libraries phase from #{target.name}"
          end
      end
    end
  end
end

How It Works

1. Iterate: We loop through every target generated by CocoaPods.
2. Identify: We check target.product_type to see if it matches com.apple.product-type.bundle. This ensures we don't accidentally modify your main app or framework targets.
3. Correct:
   • We set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to NO.
   • We proactively remove the offending build phase if it exists, preventing the build system from even attempting the task.

Verification

After updating your Podfile, run:

pod install

You should see output indicating that the build phases are being removed. Now, try running your Archive build again. The process should complete successfully, with resource bundles built purely as resources and your main application handling the Swift runtime embedding correctly.

Happy coding!