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.
Related
I am building an iOS App using a personal C++ library mylib.a , With the current Xcode version (13.1) When I include this library in my Frameworks and try to run on physical iOS device I have the following issue :
building for iOS, but linking in object file built for iOS Simulator, for architecture arm64
When I include my library built with a previous XCode version (I think it was Xcode 11) the app builds and runs on the device.
The issue appears both on Mac intel and M1.
You can try and exlude architectures or add a user defined setting called "VALID_ARCHS" in targets build settings[enter image description here][1]
look at image
[1]: https://i.stack.imgur.com/EAkWm.png
I have a native iOS app (Swift) with Unity integrated as a library following this guide:
https://forum.unity.com/threads/integration-unity-as-a-library-in-native-ios-app.685219/
XCode 12.5.1, Unity 2019.4.12f, CocoaPods 1.10.2
For the last 3 days, I am getting this error when I attempt to archive with an AppStore provisioning profile:
/Users/../Bridging-Header.h:9:9: 'UnityFramework/UnityFramework.h'
file not found
Failed to emit precompiled header
'/Users/../Build/Intermediates.noindex/ArchiveIntermediates/appname-testflight-qa/PrecompiledHeaders/Bridging-Header-swift_OMITED-clang_OMITED.pch'
for bridging header '/Users/../Bridging-Header.h'
When I do a regular build using any Provisioning Profile (PP), it builds successfully and I can run on device. When I archive using an Ad-Hoc PP, it succeeds as well.
It only happens during archiving using a manually specified AppStore PP, which I need for doing command-line builds for automated deployments. I've confirmed it happens in both commandline and in XCode editor. I need the Bridging Header so that I can allow native iOS to interact with Unity to pass it some information.
Here's the bridging header:
#ifndef BRIDGING_HEADER
#define BRIDGING_HEADER
#import <UIKit/UIKit.h>
#import <UnityFramework/UnityFramework.h>
#import <UnityFramework/NativeCallProxy.h>
#endif /* BRIDGING_HEADER */
I've tried the following suggestions already on all the other UnityFramework.h not found questions to no avail:
Switch off Parallize Build
Add UnityFramework.framework and/or Unity-iPhone project as a target first in the build process
Cleaned up project, delete DerivedData, deleted/reinstalled Pods
Switched to another scheme that will archive an Ad-Hoc PP, and changed to using AppStore PP
Reintegrated the Unity project all-over again
Build target set to Device (not simulator) through all these tests
I tried switching to: "../UnityFramework/UnityFramework.h" inside the Bridging header
Made Framework optional inside Build Phases - Link Binary With Libraries (and tried to add Copy File Build Phase - this caused an error saying this copy step was being duplicated)
Validated Runpath already includes #executable_path/Frameworks
Tried changing Pods and Project to iOS 12.1 min version and set Pods' Build Active Architecture Only to YES
Any help or suggestions would be very appreciated. I'm completely out of ideas.
The issue resided with naming of Configurations between the primary project and the Unity-iPhone subproject. Since the Unity project didn't have a matching configuration, it chose from one of the other available configurations, in my case, Debug (QA). When the archive went looking for the UnityFramework, it was in the wrong folder.
Essentially, if you have custom Configurations, make sure all of them in your primary project are also in the Unity-iPhone Project with exact same name.
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?
I try to build a static library with cmake for iPad simulation as well as iPad device. When the library is built, it will be put in a location that is determined by the built target (simulation or device). With cmake, I was wondering whether there is a variable that can tell the built target. Thanks.
In a Mixed 3.2.5 iOS/MacOS project, there is an existing iOS static library target, and I'm adding a MacOS static library. In the target build settings(all configurations) I
set the Base SDK to "Latest Mac OS X"
set Architectures to $(NATIVE_ARCH)
set Valid Architectures to i386 only
use my own PCH file
drag headers into Copy Headers, Mac target
drag source into Compile Sources, Mac target
add the Foundation.framework found at /System/Library/Frameworks/Foundation.framework, set it to the new Mac target
(/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/System/Library/Frameworks/Foundation.framework is also present, but set to the iOS target static lib)
the target compiles but the product appears NOT in "Debug" but in "Debug-iphonesimulator" instead. I'm assuming this is linking to the iOS Foundation? Whatever it's doing I can't assume that's safe.
changing the order of how I add things seems to have no effect.
any suggestions?
I suggest upgrading to Xcode 4. I have projects that build Mac and iOS libraries and both work as expected.