I'm working on a framework that has two dependencies, one of them is built to support iOS10 and has armv7 and i386 slices and arm64 and x86_64. The second is iOS11+, and there are no arm7 and i386.
So, I set my own framework min iOS version to 11. But the build failed due to the missing slices (armv7) in the iOS 11 framework.
Is there any chance to build my framework by ignoring armv7 and i836 slices from the dependent framework?
Both frameworks are added by cocoapods.
Thanks in advance.
Related
In Xcode 13 we have a new possibility, that is default on, to update binary version that is uploaded to appstoreconnect.
It is called Manage Version and Build Number.
It updates versions of the main app binary and also for embedded frameworks that are also compiled as a part of the project.
I would like to opt out for some frameworks from that behaviour. Is there a way to tell, that this particular framework version must not be updated?
I have uploaded an IPA with below details:
version - 1.0.4
build - 1.0.4
the above IPA is in my Activity section in iTunes connect.
My question is can I upload an IPA with below detail:
version - 1.0.5
**build - 1.0**
Please suggest.
YES You can do it, if the app version is changed from 1.0.4 to 1.0.5 than you can set the build version to 1.0
It's allowed with iOS, although macOS it is not.
All of the builds that you provide for a particular version of your app is called that version's "release train" (eg. 1.0.4, 1.0.5, etc). For iOS Apps you can use the same build numbers again in different release trains if you want to.
For macOS apps, build numbers must monotonically increase even across
different versions. In other words, for macOS apps you cannot use the
same build numbers again in different release trains. iOS apps have
no such restriction and you can re-use the same build numbers again in
different release trains.
↳ Version Numbers and Build Numbers
I am using Xcode 4.3.
I have an existing Xcode Project (originally created in Xcode 3) for a embeddable Mac OS X Framework. This Project has a few Targets, but the primary Target in this project is for my Framework. This Framework is designed to be embedded in Mac Apps and has the appropriate Installation Directory properties set. (#executable_path/../Frameworks)
I have a new Xcode Project (created just now in Xcode 4) for a Mac OS X Application. There is only a single Mac App Target in this Project.
I would like to combine my old Framework Project and/or Target into the new App Project so that I can build both the App and Framework from source in a single, combined build process. (I have done this in Xcode 3 many times, but cannot figure it out in Xcode 4).
I do not (unless it's the only way) want to build my Framework separately and then just link to it from my App Project. I want to combine the Framework Target into my Mac App Project.
Here's Apple's outdated documentation describing how to do what I want in Xcode 3:
Embedding a Private Framework in Your Application Bundle > Using Separate Xcode Projects For Each Target
How do you do this in Xcode 4?
Note: I just need to know how to add my Framework Target to the new Project. From there, I know how to add the dependencies and do all the Build Phases of linking and copying the built Framework into the app bundle.
After working through a tricky issue in Xcode 4.3.1, I discovered how to do this. I've given a full/detailed example in my answer to another question about how to embed ParseKit in a Mac App.
I also found excellent information on the topic in Chapter 16 of Mastering Xcode 4 by Joshua Nozzi.
You actually have 2 separate Xcode project files here: Application and Framework. The answer is the section below the one you find: Using Separate Xcode Projects For Each Target
Edit:
OK. Now I remember. You need to create a workspace and add both projects to it. Then you can add target in one project to the other for dependency: Adding an Existing Project to a Workspace
I don't have all the details since I don't have a Mac now. But I think you can figure it out once you created the workspace.
I have a problem :-( When I build my application for release XCode shows a warning saying:
iPhone apps with a deployment target lower than 4.3 should include an armv6 architecture (current IPHONEOS_DEPLOYMENT_TARGET = "3.0", ARCHS = "armv7").
But how can I set armv6 in my build settings? I'm using XCode 4.2 and here's my build settings:
Thanks!
I haven't used the version, but the current Xcode won't support signing for iOS 2.0 , so when iOS 5 comes out, 3.0 might have the same issue of not being supported
This is from http://www.weston-fl.com/blog/?p=3050 (This site has helped me resolve so many errors, so props to Mike D.)
In Xcode navigate to Build Settings and find Architectures group (it’s on the top, so hard to miss). Add armv6 to Architectures line. It should contain armv6, armv7 or Standard (armv6 armv7)
Set Base SDK to Latest iOS (currently set to iOS …)
Uncheck Build Active Architecture Only or set it to NO.
Valid Architectures must show armv6 armv7
When your project uses your own dependent libraries, build them with the same (correct) configuration.
When adding gcov to an Xcode project, I'm getting linker errors: the symbols __gcov_init and __gcov_merge_add are not found.
This is on Mac OS X 10.5 and Xcode 3.1.4, it's a Quartz Composer Plugin project and I'm trying to add gcov to the OCUnit test cases target. The Base SDK and Deployment Target are both set to Mac OS X 10.5. The GCC version is set to 4.0.
I was able to successfully create another (very simple) Quartz Composer Plugin project with gcov and OCUnit. I may be missing something but the build settings between the two projects seemed identical in anything that could possibly affect gcov linkage. (The only differences I see are the C Language Dialect, some extra settings in the not-working project for Interface Builder Compiler, and a user-defined setting that runs Clang.)
Any suggestions would be appreciated.
Shaggy Frog had the right idea-- the -lgcov flag was not appearing in the output. My project had a unit testing target and separate configurations for with and without coverage. The Other Linker Flags setting was different in the unit testing target and the coverage configuration, with -lgcov being set in only one of those. Instead of adding in all of the flags, Xcode was overriding one set of flags with the other.