We have been provided two frameworks from another team for inclusion in our iOS app. A Debug version that contains simulator and device symbols and the Release version that contains only device symbols. They asked us to include the framework as an embedded binary.
How do we conditionally include an embedded binary the way we specify release and debug paths for frameworks in Build Settings? We do not want to manually intervene when it is time to build for the App Store and we want to include the release version of the library.
My current solution is to create a new Target and remove the embedded binary. Then in your code use compiler directives to conditionally include the headers/code.
I don't think it's ideal, but got me working!
Related
I've built a Framework for distribution (not open source),everything is working despite Xcode not having a nice support for developing Frameworks.
The problem is that when archiving for AppStore you get the error:
The executable <EXECUTABLE_NAME_AND_PATH>.framework contains unsupported architectures[x86_64,i386]
The solution to the error above is to strip out the architectures mentioned, as already discussed in this question and in other sources as well.
The problem is that to use the binary on Xcode it is necessary to have all architectures, but to archive I cannot have all of them. How to build the framework in a way that it contains all the architectures (or in a way that simulators accept it) and still be able to archive and upload to AppStore without using the custom scripts to strip the exceeding architectures?
It looks like you need to build two fat libraries, one for development and another one for deployment.
This way you can create two targets into your project (you can duplicate the existing target). One target will be used for development and be linked with the full framework. The other target will be used for archiving and will be linked to the reduced framework.
Hoping this helps...
I have a target that links with a framework (both of which I develop). If I build the target it builds the framework before hand for use in the target.
What I want during certain builds is to bring in an existing already built version of that framework and use it during the build of that target. Is there a way to force xcode to build using an already compiled version of a dependant framework
(The reason I'm doing this is because I have multiple targets that are built separately and want them all to be built using the same framework binary)
I finally solved this, this can be done by turning off the "Find Implicit Dependencies" under your build scheme.
Some good reading can be found here on the topic here: https://pewpewthespells.com/blog/managing_xcode.html#scheme-action
Why this two frameworks can be used in any iOS App, but there's no need to link against them? I am assuming that when the App is build they are added as a dependency automatically, but how does this process work and how does Xcode decide this? I have never seen any configuration in build settings or build phases that includes this automatically.
And also, if is added automatically (or if is just part of the iOS SDK core), why you can also add them manually (in Build Phases)? Is there any case when you actually need to do this?
Well, it seems is because Link Frameworks Automatically is set to YES, and this will automatically add any referenced framework that supports modules.
In Core-plot 1.4, I can use the pre-built Binaries/iOS/libCorePlot-CocoaTouch.a library in my iOS app, but only if I delete "arm64" as a valid architecture in BuildSettings/ValidArchitecture script.
Can I rebuild this library to include arm64 using Source/framework/CorePlot-CocoaTouch.xcodeproj, setting its BuildSetting/Architecture to arm64?
The same question applies to CorePlot1.5.1. In 1.5.1, where can I easily find the CorePlotHeaders folder, which conveniently is Binaries/iOS/ in 1.4.
When I build, I get the Debug products, but do not see Release products in places where Build Settings says they should be. What am I (still new'ish to Xcode5) missing?
Why would I want to include CorePlot as a dependent item, rather than simply include its static library in my Xcode project app? The latter is simpler.
Can I rebuild this library to include arm64 using Source/framework/CorePlot-CocoaTouch.xcodeproj, setting its BuildSetting/Architecture to arm64?
Yes. Build the "Universal Library" target to make a complete release binary with both device and simulator code.
The same question applies to CorePlot1.5.1. In 1.5.1, where can I easily find the CorePlotHeaders folder, which conveniently is Binaries/iOS/ in 1.4.
The headers are in the same place in the 1.5 and 1.5.1 release folders, too.
When I build, I get the Debug products, but do not see Release products in places where Build Settings says they should be. What am I (still new'ish to Xcode5) missing?
This is determined by the selected "scheme". By default, building or running makes a debug version while profiling or archiving makes a release version.
Why would I want to include CorePlot as a dependent item, rather than simply include its static library in my Xcode project app?
You would use the dependent library build if you were keeping up with the latest code from Github or using your own private fork. You can always build a static library from source (see question #1, above), but if the Core Plot code is changing often, its easier to include the project directly.
I'm having a problem building libraries that have a "configure" script, namely such scripts are not meant for compiling for iOS.
Is there a set of environment variables that I can set to induce "configure" to work for iOS?
I tried setting CC but that was not nearly enough.
Thanks.
Github project with static libraries and headers that build properly for iOS.
From the readme (Nov 2011):
LibArchive Static Library for iOS Unfortunately, while
libarchive.dylib and libbz2.dylib are included in the iOS SDK, the
header files are not. This means that they are private APIs and cannot
be used if you intend to submit to the App Store.
Never fear! This repository contains everything you need to build a
static version of libarchive for iOS. libbz2 is also included for
extra goodness.
To keep naming of things sane, we build the library as libarc.a.
For iOS 4.3+ copy the header files and library from the
build-for-iOS-4.3 directory into your project.
For iOS 4.2 copy the header files and library from the
build-for-iOS-4.2 directory into your project.
If you need to build this for an earlier version of iOS, you can
easily modify the build.sh script to point to whatever SDKs you like.
It should build fine on 3.x.
TO GET IT FULLY LINKING you must also include libz.dylib in your list
of linked libraries. To do this in XCode 4, click on your project,
choose the Build Phases tab, go to Link Binary With Libraries, press
+, and choose libz.dylib from the (long) list of possible libraries to link against. This is because libarc.a links dynamically to libz.dylib
-- this is okay since, for whatever reason, AAPL saw fit to include the libz headers in the iOS SDK.
The current libarchive version is 2.8.4. The bzlib2 version is 1.0.6.