Recently, I observed section named Text-based API in Xcode build settings. In Xcode 7.X it's under Linking section. But now with Xcode 8.X, it's separated out as another section in Xcode build settings. I'm interested to know what exactly it will do?
Image for reference:
From Xcode 8.0 and above version, Text-based API is in Build setting as it have different business logic
Related
Somehow "Always Embed Swift Standard Libraries" for all of my targets is YES. Probably due to historical development from Swift 1 to 5.
I'm using Xcode 10.2 now, upgraded the targets and my "Swift language version" is 5 for all of them.
Out of interest I created an empty new project with Xcode 10.2 and it is created with "Always Embed Swift Standard Libraries" as NO for both Debug and Release builds.
I have a feeling that even if I leave it as it is, Apple will strip standard Swift libraries anyway as a part of thinning for iOS 12.2+?
So what's the correct default since swift 5? Any benefits from either keeping it at YES or changing to NO?
[Update] Thanks to Cœur for a comment. It really looks like that one of the CocoaPods versions did it. Project is set to NO, but all the targets using CocoadPods were YES.
The default for new projects is NO and (as far as I know) always has been. I have never had "Always embed" set to YES, and my projects have always worked just fine. So unless there is some really good reason why this was YES, it probably shouldn't have been.
Note that the libraries are stripped out only if you are building against the 12.2 SDK and going onto a machine with 12.2 (or later). The libraries are still needed to run on a 12.1 or earlier machine.
I came here because I've updated my development environment to :
XCode 10.2
iOS 12.2
WatchOS 5.1.3
And my apps refused to even start on the watch, with a single message to console, saying library image not found. (using Swift4 build setting)
Setting "always embed" to on makes the app install process incredibly slow on the watch.
I updated the project to use Swift5, now the app at least starts up again.
FYI
If you set true for ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES on the target framework, you will probably receive ERROR ITMS-90206: Invalid Bundle.
In my case, I set true for target that is App / Unit Tests / UI Tests.
If you set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES NO your app may lead to crash while open with iOS 12.1 and lower version.
I'm running into compatibility issues for some external frameworks I'm using in my project. Is there a way to change the Base SDK on Xcode 8? Currently in the project settings only show me the Latest SDK.
I've tried copying the older SDK from another version of Xcode to here but it didn't work:
/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/
Starting with Xcode 7.3, in addition to copying in the SDK, you must also edit a certain Info.plist file, as described here for macOS in the post by agx. It looks like there is a similar file for iOS, at
Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Info.plist
Try changing the value of MinimumSDKVersion in there from 10.0 to whatever SDK version you want.
I've not tried this with iOS, but, using this workaround, I was just able to build a macOS target with macOS 10.6 using Xcode 8.0 (8A218a) (the "GM").
UPDATE
The hack described above stopped working for me in Xcode 9. If you want to use Xcode 9+, see my more recent answer dated Nov 22, 2017.
My original answer, although it worked with Xcode 8, for some strange reason which is not worth explaining, no longer works with Xcode 9 on a particular client's old project. So I've been using an alternative workflow which is really not too bad.
To work on this project, I open it in both the older Xcode, which can build it with the required SDK, and in a recent Xcode. I put the old Xcode window in the background and do my work in the recent Xcode. When I am ready to test changes, I do a File > Save All (⌥⌘S), then switch to the old Xcode and Build (⌘B). When the build is done, I switch back to the recent Xcode and Product > Perform Action > Run without Building (⌃⌘R). Because the dSYM file format has not changed, breakpoints work as expected.
The advantages are that no hacking of Xcode is required, and the only thing I need to remember about the old Xcode (Xcode 3 in my case) is, mercifully: ⌘B.
One little warning: In this particular project's Target, in Build Settings, it has a custom Build Products Path. This is typical of the way Mac apps were built years ago. To ensure that both of your Xcodes are working with the same product, if your old and recent Xcodes straddle the version which changed the default Build Products Path, you may need to set Build Products Path.
The workflow could probably be made even easier by scripting the xcodebuild and xcode-select command line tools, but this is good enough. With Apple's announcement at this year's WWDC about support for 32-bit Mac apps going away during the next two years, my client has some tough decisions ahead in any case.
You just have to change the "Deployment Target" settings. You basically use the latest available SDK as base SDK but select a target OS X version.
Of course it depends on why you want to use an older SDK?
My Xcode project builds and runs on a device but it does not build against the simulator. I am using a custom Framework in my project. This post seems to indicate that when you build a Framework to be included in another project you can only build it for the simulator or a device, but not both. Is this the case?
I am using Xcode 6.3.1
You're correct that you can only build for one platform at a time, but the answer in your link explains how to use a script to build a binary that contains the framework for both platforms.
I just upgraded from Xcode 6 Beta 2 to Xcode Beta 3 and am now getting the following warning when building my project:
ld: warning: relocatable dylibs (e.g. embedded frameworks) are only supported on iOS 8.0 and later (#rpath/libswift_stdlib_core.dylib)
It is a warning but seems to mean my current setup will not work on iOS 7.1, which is my deployment target. How can I track down which frameworks are embedded, and how can I fix this for iOS < 8.0?
This appears to be a bug of Beta 3. As pointed out by Apple Engineer on this post.
I have also been living with this warning when running apps on iOS 7.1 device.
You see and add them on the project page when you select the target: tab General->Embedded Binaries (and they then appear in Build Phases->Embed Frameworks).
Embedded frameworks for OSX were available in Xcode 5, but not for iOS.
WWDC session regarding new features in Xcode 6 specifically promised dynamic frameworks for iOS 8 (someone please add citation when developer center comes back online). So far, with all Xcode 6 betas, I have had no problems compiling and debugging an app with frameworks on iOS 7.
But since this wasn't promised, frameworks for iOS7 is something you cannot depend on (e.g. this may stop working in later betas; an app with embedded framework for iOS 7 may be rejected, etc.). That may explain why they added an explicit warning.
There's not much you can do if this feature turns out to be indeed unsupported, other than remove the frameworks from the target and use static libraries as we did with Xcode 5. Or go the iOS8-only route.
After using XCode 6.1.1 I am able to put the code on iOS 8+ iOS7.1.2 and iOS 6.1.3 Although the warning is still there but the app works absolutely fine on all the 3 OSs
======================
Lucky guy... My project keeps failing to compile after I referenced the PushKit framework.
The project is a new project created by Xcode with only 3 new functions for testing Push Notification.
The workaround is to put the PushKit framework as "embedded", but this is not a good solution since my working Xcode project will be generated from Unity3d. Making the changes manually will break the auto build process.
I had this error after adding a C++ framework (DeepBelief) to a project. Adding an empty .cpp file to the project fixed it.
I'm using Beta4, and found the answer on the DeepBelief github site:
XCode may be skipping the standard C++ library, and that's needed by
the DeepBelief.framework code. One workaround I've found is to include
an empty .mm or .cpp file in the project to trick XCode into treating
it as a C++
project.
Read this github post from ReactiveCocoa
The bug is still present in XCode6 GM and so XCode6 final release:
Well, I get the exact same issue in xcode6GM no matter whether I
create framework for swift OR objc :-[[[[[[[[[[[[[[[
According to Apple Extension Programming Guide:
You can make a containing app available to users running iOS 7 or earlier, but then must take precautions to safely link embedded frameworks when running in iOS 8 or later.
talking about app extensions, but if you read it, you can understand that this applies to embedded frameworks in general.
this is happening because one of your embedded binaries's deployment target is lower than your applications target. lower your embeded binaries's building target and be fine.
this was the error cause in xcode 6.1.1
i was using xcglogger with deployment target ios 8.0, and my application's deployment target 7.0. set the xcglogger's deployment target ios 7.0 and problem solved.
After using XCode 6.1.1 I am able to put the code on iOS 8+ iOS7.1.2 and iOS 6.1.3
Although the warning is still there but the app works absolutely fine on all the 3 OSs
Yes not able to submit the app for review.
Had to do by changing the modern frameworks to Static libs.
I've created a project in Xcode 5.0 (yes, Developer Preview) for the beta iOS7 software because I wanted to play around with the new beta stuff. But I actually decided to submit the App I was playing around with to the App Store and since this is not possible with preview Xcode versions I fixed all compatibility issues to make the code work with Xcode 4.6.3 and iOS 6. Except for one thing.
And that's importing third party frameworks like Flurry (analytics framework) or Crashlytics (crash reporting framework).
Both are correctly imported and set up with targets (it's all working in Xcode 5.0) but I'm getting a 'Crashlytics/Crashlytics.h' file not found in the line I'm importing the needed classes (#import <Crashlytics/Crashlytics.h>) in Xcode 4.6.
The same is true for the Flurry framework analogously. The crazy thing is, both libraries show up in the targets 'Link Binary With Libraries' list, even in Xcode 4.6.
Does anyone have an idea how I can get things work in Xcode 4.6? Are there any further ways to influence the importing?
The link binary with libraries is not the issue here. You have to confirm your Header Search Paths in your build settings. I think Xcode 5 might use a different variable for it, and that is why Xcode 4.6 will get confused (just a guess though). Anyway, confirm that the path to those headers is in your Header Search Path. The Crashlytics app will automatically add it for you, actually.