Fix: File not found libarclite_iphoneos.a in Xcode

Why this happens

The build failure File not found: .../usr/lib/arc/libarclite_iphoneos.a is a linker error introduced when compiling projects with Xcode 14.3 or newer. The compiler attempts to link against libarclite, a runtime compatibility shim that Apple originally bundled to backport Automatic Reference Counting (ARC) to older OS releases like iOS 4 and iOS 5.

Historically, when a target’s deployment target was set lower than the OS version where ARC became native (iOS 6), the Clang driver automatically injected -larc into the linker arguments. Starting with Xcode 14.3, Apple removed the arc directory and all libarclite binaries from the default toolchain (XcodeDefault.xctoolchain) because modern toolchains no longer support deployment targets that require these legacy ARC shims.

If your project relies on third-party libraries—most frequently integrated via CocoaPods—whose specification files still define an obsolete deployment target such as iOS 8.0, 9.0, or 11.0, the compiler attempts to locate libarclite_iphoneos.a in the toolchain directory. Because the file does not exist, the build terminates immediately.

How to fix it

1. Update the deployment target in your Podfile (Recommended)

The most reliable and maintainable solution is to ensure every dependency in your Pods project targets a modern iOS release. You can enforce this globally without editing individual vendor files by using a CocoaPods post_install hook.

Open your project’s Podfile in a code editor and locate the post_install block. If one already exists, merge the target configuration logic below. If not, add this block to the bottom of the file:

post_install do |installer|
  installer.generated_projects.each do |project|
    project.targets.each do |target|
      target.build_configurations.each do |config|
        current_target = config.build_settings['IPHONEOS_DEPLOYMENT_TARGET']
        if current_target.nil? || current_target.to_f < 13.0
          config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '13.0'
        end
      end
    end
  end
end

Save the Podfile, close Xcode, and re-run CocoaPods from your terminal:

pod install

Reopen your .xcworkspace file in Xcode, clean the build folder (Product > Clean Build Folder or Shift + Command + K), and run the build again.

2. Manually adjust the deployment target in Xcode

If you are not using CocoaPods or if you need to quickly verify which target is triggering the error, you can raise the deployment target directly in the Xcode project hierarchy:

1. In the Project Navigator, select the Pods project (or your parent project if not using pods).
2. Under Targets, click through each target to find those with an outdated minimum version.
3. Open the Build Settings tab.
4. Ensure All and Combined are selected at the top of the tab.
5. Search for iOS Deployment Target (IPHONEOS_DEPLOYMENT_TARGET).
6. Change any value lower than 13.0 (such as 8.0 or 9.0) to 13.0 or match your main application’s minimum target.
7. Repeat this for all targets under the Pods project.

Note: While this resolves the error immediately, re-running pod install or pod update will overwrite these manual changes unless you implement the post_install hook described in step 1.

3. Update or replace unmaintained dependencies

Libraries that default to iOS 8 or iOS 9 are often unmaintained and may cause additional toolchain failures down the road, such as bitcode deprecation issues or signature validation errors.

Inspect your Podfile.lock to see which dependencies require these legacy deployment targets:

pod outdated

Check the repositories of those libraries to see if newer releases support recent iOS versions. If a library has been abandoned, consider replacing it with an actively supported alternative or integrating it as an internal Swift Package with a modern minimum deployment target.

Why you should not manually inject libarclite into Xcode

A common workaround found online involves downloading libarclite_iphoneos.a from third-party repositories and pasting it into /Applications/Xcode.app/Contents/Developer/Toolchains/... using sudo.

Avoid this workaround. Modifying the internal contents of Xcode.app invalidates Apple’s code signature on the developer tools, fails completely in automated CI/CD environments (such as GitHub Actions or Xcode Cloud), and will be wiped out whenever Xcode updates. Adjusting the deployment target in your build configuration solves the underlying configuration mismatch cleanly.

How to prevent it

• Specify minimum targets in the Podfile: Set an explicit platform version at the top of your Podfile (for example, platform :ios, '15.0').
• Keep the post_install hook permanent: Leave the deployment target normalization block in your Podfile to protect against newly added legacy pods.
• Audit third-party dependencies: Review your dependency graph annually and remove libraries that have not seen commits or updates in several years.
• Migrate to Swift Package Manager: Where possible, migrate CocoaPods dependencies to SPM, which enforces stricter platform compatibility and eliminates many legacy linker shims.

FAQ

What minimum iOS deployment target is required to stop linking libarclite?

Setting the target to at least iOS 13.0 guarantees that Clang will not attempt to link libarclite. Even iOS 11.0 or 12.0 avoids the ARC shim in most toolchains, but iOS 13.0 aligns with standard baseline requirements across modern Xcode releases.

Can this error happen with macOS, watchOS, or tvOS targets?

Yes. The error manifests as libarclite_macosx.a, libarclite_watchos.a, or libarclite_appletvos.a if those platforms are configured with obsolete deployment targets. Applying the same deployment target bump to those respective platform settings resolves the issue.

Why did Xcode build my project fine before upgrading?

Earlier versions of Xcode (Xcode 14.2 and lower) still shipped with the legacy arc directory inside their toolchain to maintain backward compatibility for projects targeting older iOS versions. When Apple removed support for those legacy deployment targets in Xcode 14.3, the static library files were deleted from the toolchain bundle.