Xcode 5.0.2 dyld: Library not loaded: @rpath/XCTest.framework/Versions/A/XCTest

Question

I have problems running a project in Xcode 5.0.2

I get the following error:

dyld: Library not loaded: @rpath/XCTest.framework/Versions/A/XCTest
  Referenced from: /Users/chris/Library/Developer/Xcode/DerivedData/relatio-cwlmozvklaldmictbbjthzuoxnxz/Build/Products/Debug/relatio.app/Contents/MacOS/relatio

Reason: image not found (lldb)

How do I solve this issue?

Incidental

This is how I solved the problem: 1. Navigate to the project's "Build Settings" 2. Search for "Runpath Search Paths" 3. Enter the following path in the column below the product name: /Applications/Xcode.app/Contents/Developer/Library/Frameworks/ – Incidental

You can answer your own question by writing an answer instead of a comment. – Isotropic

Answer 1

It looks like your main target is linking to XCTest.framework as well as your test target. It should only be linked to the main target.

1) Go to Project settings

2) Go to your apps main target -> other linker flags

3) remove '-framework XCTest'

4) make sure the 'other linker flags' field for your test target still contains '-framework XCTest'

Cornu

I followd this. but not helped – Expediential

Good answer, but what I have there is $(inherited) to bring in the data from CocoaPods. – Cathee

Instead of removing, you can also make your framework optional by doing -weak_framework "XCTest" – Egest

I don't have test target anymore, I've removed it from the app. Still I'm getting the same error. – Commode

Answer 2

I ran into this error by renaming my targets one of which was a testing target. After reading the other answers I realized that my Build Phases > Compile Sources was including test classes as compile sources for non-test targets which then tried to import the XCTest framework.

Removing the test classes from my regular target’s Compile Sources solved this for my case.

Neutrality

Answer 3

I solved this problem this way. I have edited scheme, at "Build" tab ticked "Run".

Gine

Answer 4

The problem here is that, according to the dyld error message you posted, your application is linking against XCTest.framework. That's incorrect; only your test bundle needs to link against XCTest.framework since only your test bundle contains tests.

Hendricks

Answer 5

I had similar problem with OCMock library and solution is:

target :"Application Tests", :exclusive => true do
    pod 'OCMock'
end

Zinciferous

For those dummies like me, if your application is named MyApp, the target here is MyAppTests ... – Mousse

Careful, if you do 'exclusive => true' you are NOT including any more pods from other targets. – Egest

Note that :exclusive has since been replaced with inherit! :search_paths. See blog.cocoapods.org/CocoaPods-1.0-Migration-Guide – Glassine

@LeszekZarna Sure, I added the post 1.0 syntax to your existing example. – Glassine

Answer 6

In my case It was RxTests added by Swift Package Manager to main application target. In pods you decide which Rx components add to which target, but SPM adds it all to main target as default.

Antalkali

Yes I removed from the main target and it works fine now. Thanks – Consolata

I moved RxTest pod to test target in Podfile then deleted Xcode Derived data, then the problem solved. – Yonah

Answer 7

This is how I solved the problem:

1. Navigate to the project's "Build Settings"
2. Search for "Runpath Search Paths"
3. Enter the following path in the column below the product name: /Applications/Xcode.app/Contents/Developer/Library/Frameworks/

Incidental

This is incorrect in a couple of ways. First, it will lead to a dependency of your application on XCTedt.framework, which is only available within Xcode. Second, you're using an absolute path, which isn't guaranteed to be the same from Mac to Mac (for example if you have multiple versions of Xcode installed). – Hendricks

@ChrisHanson: This is really working with Xcode 5.1.1. But note that you don't need to provide Absolute Path, relative path should be provided. My scenario was, I have build Dynamic Frameworks with Xcode 6, then i tried to used it in Xcode 5.1.1 in my application, I received same issue describe here... I tried giving path of my Dynamic framework in "Runpath Search paths" and it worked.. – Schade

Answer 8

In my main Target's "Link Binary With Libraries" (under Build Phases), it was the testing framework I was using (Nimble.framework) that was causing the problem. Removed it, and everything's fine!

Cayenne

Answer 9

enter the reference of your framework on framework search path AND Run path search path under "Build Settings"---...Now all set to invoke your projects by using import

Bellicose

Answer 10

I have same issue is because i add a new file into the framework. So just run "pod install" solved my issue. But make sure your pod under Tests target too.

Dorren

Answer 11

Just for the ones that came up with the same issue:

Check on the lateral right menu which has to look like that:

And has not have to look like that:

Prominent

You could probably explain that applies for all and only your test files. – Polymerize

Answer 12

For our case, we want to use Mockingjay for both app target and test target

target 'MyProject' do
  pod 'Mockingjay/Core'
  # all pods that are not test go here

  target 'MyProjectTest' do
      inherit! :search_paths
      pod 'Mockingjay/XCTest'
      pod 'Quick', ' ~> 0.9.2'
      # .. all test pods go here
  end
end

Sandrocottus

Answer 13

A solution that worked for me was changing your test target's inherit attribute in your Podfile from :search_paths to :complete. Although this answer suggests that :search_paths is designed for test environments.

target 'myapp' do    
  use_frameworks!

  target 'myappTests' do
    #inherit! :search_paths
    inherit! :complete
  end

end

Lark

Answer 14

I had this error using ios-snapshot-test-case v5.0.2 via Carthage. The problem is related to XCode 11. Apple renamed libswiftXCTest.dylib to libXCTestSwiftSupport.dylib and added XCTest.swiftmodule which has the same symbols in it and can work in place of the old one. But Apple forgot to tell iOS 11.x simulators about this change.

So you need to fix the older iOS version simulators. Here is the terminal command that fixed it for me:

sudo zsh -c ' sourcedir="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/lib"; 
targetdir="/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 11.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib"; 
ln -s $sourcedir/libXCTestSwiftSupport.dylib $targetdir/libswiftXCTest.dylib;
ln -s $sourcedir/XCTest.swiftmodule $targetdir/XCTest.swiftmodule'

See my comment here: https://github.com/CocoaPods/CocoaPods/issues/9165#issuecomment-573523322

Danielldaniella

Answer 15

Go to General > Targets (Left side).

You might have 2nd item containing the word test/s. Click it.

In this general settings > Testing > Host application > Select from options (your app name). That's it!

Sitzmark

Answer 16

If you are using cocoapods, double check that the default_subspec (which by omission includes all available subspecs) does not accidentaly bundle XCTest, e.g. For the following .podspec

Pod::Spec.new do |s|
  s.name = 'MySpec'
  # ... spec definition details

  # "Normal" subspecs

  s.subspec 'NormalSubspec1' do |subspec|
      # ... subspec details
  end

  s.subspec 'NormalSubspec2' do |subspec|
      # ... subspec details
  end
  
  # Testing subspec

  s.subspec 'TestingSubspec' do |subspec|
      subspec.frameworks = 'XCTest'
      # ... subspec details
  end
end

if you were to depend on it in a Podfile as

target 'MyTarget' do
   pod 'MySpec'
end

it would include all subspecs (MySpec/NormalSubspec1, MySpec/NormalSubspec2, and MySpec/TestingSubspec).

Whereas, if you also define default_subspec, then you can exclude MySpec/TestingSubspec from the default dependency.

Pod::Spec.new do |s|
  s.name = 'MySpec'
  # ... spec definition details

  s.default_subspec = 'NormalSubspec1', 'NormalSubspec2'

  # "Normal" subspecs

  s.subspec 'NormalSubspec1' do |subspec|
      # ... subspec details
  end

  s.subspec 'NormalSubspec2' do |subspec|
      # ... subspec details
  end
  
  # Testing subspec

  s.subspec 'TestingSubspec' do |subspec|
      # ... subspec details
      subspec.frameworks = 'XCTest'
  end
end

and it would now behave the same way as if you had explicity dependend on the subspecs

target 'MyTarget' do
   pod 'MySpec/NormalSubspec1'
   pod 'MySpec/NormalSubspec2'
end

Sagittal