I updated Xcode to the last version, and now when I'm trying to compile the project I'm getting an error "Invalid bitcode signature", hovewer, the bitcode for my project is disabled. How can I fix it? What should I change to sign my bitcode correctly?
My Podfile:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks!
target 'MyProjectName' do
pod 'Realm'
pod 'CorePlot'
pod 'GoogleMaps'
end
I checked already, everything is fine with it.
I'm not sure if you have the same situation with me. I only have this issue when I tried to test with iPhone device. It turns out that the debug configuration with Build Active Architecture Only is set to NO. After I set to YES, I can test with my iPhone.
I experienced this error, but it happened only when building for an iOS 10.3 iPad (despite working on an iOS 10.3 iPhone and an iOS 11.0 iPad, and all the iOS 10.3 and 11.0 simulators). Through painful process of elimination (and creating a new project from scratch), I found that my Cocoapods weren't at fault, nor was my code signing settings, nor my AppExtension, nor my tests, nor my 'build for active architecture only' setting, nor any build setting related to the term 'bitcode'.
In my setup, I had a C++ Xcode project nested within my main Swift/iOS Xcode project. Because it was never intended specifically for use in iOS, the "iOS Deployment target" had never been set (it was left on 'default'). Upon setting it explicitly to 10.3, it worked without complaint.
Nested C++ app's project settings (set iOS deployment target to the lowest iOS version you support):
Nested C++ app's target settings (for reference):
If you using pod then please check the version of all libraries, some library may be not supporting in new version , you have to update pod files for that library.
In my case, I was trying to build for a device with an iOS version lower than the deployment target.
This kind of problem came up when I linked a new static library project to my workspace. In order to solve it I tried to set both the Build Active Architecture Only and the Bitcode settings of the library to NO but no luck. Then I got across the thing that the library's Deployment Target was set to 11.0 as Xcode set the latest value to all new projects. After fixing the setting to 5.0 the problem was solved.
On my case problem occured because of I was using a 3rd party static library with different files for each architecture
I fixed the problem by removing binaries of invalid architectures.
Instead I added a multi-arch FAT binary for the 3rd party static library
Hope helps
For my case, the solution was removing a c++ library.
I found that my issue was with using 'Modules'.
Just turned off modules (had to update some header files), but that resolved my issue.
Enable Modules In Settings
In my case, the widget included in the project was causing the bitcode error.
I changed my pod file from this:
target "App" do
pod 'A'
pod 'B'
end
target "App Widget" do
pod 'A'
end
to this:
target "App" do
pod 'A'
pod 'B'
target "App Widget" do
pod 'A'
end
end
To fix this issue, most answers recommend a workaround whereby you clean your Xcode workspace/project, close Xcode, delete your Derived Data folder (this is kept in the root directory of your project by default), then finally re-open your project.
However, the above steps may not work for you. This is a hint that your project structure is in error.
When the bitcode intermediary representation of your project was released with iOS 9.0, it was done so on the provision that your entire project, including dependencies, either totally agree to use bitcode or not. From my experience, it is vital to work through all of your Pods and included Libraries/Frameworks and ensure they all use the same setting; either Yes or No. By default, this selection is Yes.
If a single dependency does not match the intended bitcode setting, this error can be thrown.
When sanity checking your dependencies and overarching project, it is important to note that there is a Use Bitcode setting for both the Project and the Target settings, so be sure to check both perspectives of the Build Settings.
I was adding static library . I created fat binary of the same library including all architectures and included in my project. This resolved my issue
In my case, I am Using Cordova Project. While building it with Xcode had the same issue and Resolved by Removing and Adding the IOS platform.
cordova platform remove ios
cordova platform add ios
If you are using cocoa pods then do "pod update"
Targets -> Build Settings ->Build Active Architecture Only
Debug -> YES
Release -> NO to YES
I face the same problem only on archiving the app.
Who can tell me the reason? You can teach all developers. It's awesome.
This solution work for me. First, try to remove all pod using terminal command pod deintegrate and then reinstall pod using terminal command pod install.
This can also occur when building for the simulator if including a framework built for ARM only (and I assume vice-versa as well).
I've just updated my Xcode from 7.31 to 8.
I have an Objective-C project that uses cocoapods.
When I double-clicked on xcworkspace file, it gave me error like:
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly."
So I opened Build Settings for the project and pod proj, but I still can't find any options named "Use Legacy Swift Language".
I looked over some articles about this, so I tried to set this flag to NO or YES from undefined. but I can't find this option.
I am developing a command line macOS application(with Objective-C) which uses other 3rd party Swift libraries. I am retrieving an error says
"dyld: Library not loaded: #rpath/libswiftAppKit.dylib"
Previous answers recommend to set "Embedded Content Contains Swift Code" flag to true. However, this flag is missing with Xcode 8 beta.
I have tried "ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES", which i believe a new flag for Xcode 8. It doesn't work either :(
Is anyone tried to compile and execute a command line application with Xcode 8 beta that is;
- developed using Objective-C
- having 3rd party swift library dependencies
Update:
I ended up copying everything under "/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx" into the folder where the executable stands. Not a perfect solution but it works.
Check this mentioned in Xcode 8 beta 2 Release Notes:
The new build setting ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES replaces the use of EMBEDDED_CONTENT_CONTAINS_SWIFT. This setting indicates that Xcode should always embed Swift standard libraries in a target for which it has been set, whether or not the target contains Swift code. A typical scenario for using this setting is when a target directly uses or embeds another product which contains Swift code.
Note: EMBEDDED_CONTENT_CONTAINS_SWIFT has been deprecated. (26158130).
Today I've updated to Xcode 6.2/iOS SDK 8.2 and I've updated my project's Parse framework to 1.6.4 simultaneously. Now, I'm getting this error:
Definition of 'PFInstallation' must be imported from module 'Parse.PFInstallation' before it is required.
and
Definition of 'PFFile' must be imported from module 'Parse.PFFile' before it is required.
Both manifest as errors, not warnings, though interestingly my app builds.
I think modules are a Swift thing, though I'm on Objective-C and my project has nothing to do with Swift. What should I do?
UPDATE: Cleaning the build folder and restarting Xcode and rebuilding got me rid of the installation one, though file error is still here.
Congratulations!
You've found (yet another) bug in Xcode.
File it on bugreporter.apple.com
Cause it's still there one major release later in xcode 7.2.1
and I have to rm -rf ~/Library/Developer/Xcode/DerivedData all the time
to have the project build and run
(I do have swift content in the outer framework of mine though)
UPD 2016.02.18 this either seems fixed in 7.3 beta 3 OR I have strategically killed an #import somewhere which took care of this. Do not hesitate to share YOUR experience in the comments and/or answers ;-)
Try to import the file with framework reference like this:
#import <Parse/PFInstallation.h>
I have an old computer that cannot upgrade to Lion, but I would like to use it for coding while still taking advantage of syntax such as instancetype and Objective-C literals. Has anyone tried to compile a newer Clang and LLVM to use with an older Xcode and been successful?
There are various ways to use the newest LLVM/Clang version.
(1) Plugins, as described in the comments above, e.g.:
http://blog.wadetregaskis.com/tot-clang-llvm-in-xcode/
As pointed out in the linked blog post, you may get errors/warnings from Xcode's real-time syntax checking as Xcode uses an older version of libclang (more on that under (3)). It is likely to compile fine, but editing source code won't be a lot of fun.
(2) Set the compiler via the CC flag. This is probably the easiest/fastest solution and the setting only affects one project. Go to the project's Build Settings, choose "Add Build Setting" -> "Add User-Defined Setting" (in Xcode 5, this is hidden in the Editor menu), name it CC and set the value to the path of your version of Clang. Worked fine for me, but as with (1), you might get conflicts with the live error reporting, especially if you want to use new syntax such as literals, or pass flags for warnings that the older version does not understand.
(3) Replace the compiler. Make sure you back up any files before replacing them. There are two files that need to be replaced: the Clang binary, and libclang.dylib. Go to /Applications/Xcode.app/ -> Option-Click -> "Show Package Contents" -> /Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr. clang is in /bin, libclang.dylib is in /lib.
Both binaries can either be compiled from source (which will give you an even newer version, of course) or just copied from the latest Xcode package. I ran into trouble using a customised version of libclang, but I suspect the problem originates from my modifications there. If in doubt, use libclang from a later Xcode version.
Note: My modified libclang binary used ARC and is therefore incompatible with Xcode 4 which runs with garbage collection. Xcode 5 itself uses ARC so the problem has vanished. If you compile libclang unmodified, you shouldn't come across the issue in either Xcode 4 or 5.