My project uses third-party xcframeworks but one of the xcframework does not support simulator which leads to building fail. Is there any way to exclude that particular xcframework from simulator build but in device build?
Related
I have two .a static lib files named: libxxx-ios.a and libxxx-ios-sim.a.
In my test, libxxx-ios.a cannot be linked with a iOS simulator build and libxxx-ios-sim.a cannot be linked with a iOS real device build.
Which setting should I use to apply libxxx-ios.a for an iOS real device build and libxxx-ios-sim.a for an iOS simulator build automatically? Then it can auto switch the .a file when i change the build target.
I've tried to use lipo to combine those two .a files, but it failed.
Simulator builds fail in Xcode where a 3rd party framework is being used and that framework is only provided in compiled form.
Device builds are successful, but simulator builds on M1 Macs give an error:
Module compiled with Swift 5.4.2 cannot be imported by the Swift 5.5.1 compiler
The error regarding Swift versions is misleading; as noted in the question, device builds work. It is only simulator builds that fail.
The actual cause is that the framework was built without an M1 simulator slice and so Xcode cannot complete the simulator build.
The framework supplier needs to supply an updated build that includes both x86 and M1 simulator slices.
A work-around is to get Xcode to create X86 simulator builds.
In the Build Settings for your project, specify the x86_64 architecture for iOS simulator builds:
I have a project with iOS 10 deployment target. In this project i am using 3rd party frameworks. This frameworks deployment targets iOS 11. So frameworks just have arm64 builds. When i try to build gives me error: armv7 build is missing for iOS 10. I am embedding 3rd party frameworks.
Is there a way to use iOS 11 frameworks in iOS deployment target project without armv7 build?
Can i exclude 3rd party frameworks in build phases with run script or anything else?
Thanks
No, you cannot. You need to drop iOS 10 support or ask the 3rd party framework provider for a binary with both armv7 and arm64 support.
Building my React Native app in Xcode 11.3.1 gives me the error:
"React/RCTBridgeDelegate.h" file not found in AppDelegate.h
only when building an additional target (Release Scheme) directly in Xcode. When building the standard development target, I have no problems.
More detailed:
I have a React Native app with a Watch companion app. The app is equipped with different additional React Native modules. The app runs smoothly when building it in the standard build target (Development scheme) via React Native CLI (react-native run-ios) as well as when building the standard build target (Development scheme) directly in Xcode.
Already a while ago, I have created a duplicate set of targets in Xcode (Release scheme). Building the duplicate target for the iOS app in Xcode bundles the React Native code and images as an additional build phase to be able to deploy the app on an iPhone not depending on the development server. Building this target worked out smoothly as well for a long time.
Now all of a sudden since some days when I want to build my duplicate target (Release scheme) in Xcode I am getting the error
I can still build the standard build target (Development scheme) via console react-native run-ios and also directly in Xcode with no problems. I am not sure what caused this issue now, the only change to my config I have made some days ago is that I have added some additional modules to my React Native app, e.g. react-native-keychain and react-native-push-notification. Both have been configured correctly as I would assume, also pods have been installed as necessary and I can see that those modules also work well when building the development target, so I don't think that adding those additional modules caused the issue.
I have read all issues on StackOverflow describing this problem and have already tried all of the following solution proposals with no effect, unfortunately:
Make sure that "Parallelize builds" is deactivated in the scheme (had already done that by the time when duplicating the development target creating a release target). Also make sure that target "React" is listed above the app build target in "Build" option of the scheme.
De-integrate pods and re-install pods
List additional target in the Podfile with "inherit! :search_paths", again de-integrate and re-install pods --> gives me a warning that the additional target in the Podfile "overrides the HEADER_SEARCH_PATHS build setting"
Clean the build and repeat step 2
Add the React path directly in the HEADER_SEARCH_PATHS in target build settings --> gives me linker errors
Explicitly build target "React" first - Clean Build, Build target "React", then build my release target
I am stuck and would really appreciate your help - do you have further ideas on what I can try out to solve this problem?
I have a number of iOS Xcode projects that all use the same subproject. This subproject builds a static library, that's then linked to the master project. Up until now this subproject and all master projects have been 32-bit.
I want to build a new project with 64-bit support, so have set the architecture to "armv7, armv7s, arm64".
Of course, I had to update the shared subproject to "armv7, armv7s, arm64" as well.
Everything builds fine.
However, now when I build old 32-bit-only projects to run on 64-bit devices it fails, because Xcode builds a 64-bit non-fat version of the static library from the subproject, which it can't link to.
Is there a way to tell Xcode (linker flag?) to build and link to the 32-bit version of the subproject, because the master project is 32-bit?
Thanks,
Russell.
Answer was that I had "Build Active Architecture Only" set to Yes in the subproject by mistake, causing it to always build a thin library. Setting to no, builds a thick lib with all supported architectures, meaning it'll work with a parent 32-bit project!