I thought I understood what Always Embed Swift Standard Libraries was doing, but now i'm confused.
I pushed an update to a MacOS app to the App Store and a user said it was crashing for him on macOS High Sierra. After a very quick investigation, it seems the swift libraries were missing and one of my frameworks was written in swift (Main app was ObjC). I switched Always Embed Swift Standard Libraries to YES, re-uploaded a new build and everything was great with the world.
I have now uploaded a brand new iOS app to Testflight that is build for iOS 9.3+ and remembered about this issue so thought i'd test it out.
The Always Embed Swift Standard Libraries setting is set to NO which must have been the Xcode default. I downloaded the app through TestFlight on an iOS 9.3.2 device expecting it to crash on launch, but no, the app works perfectly fine.
How can a macOS app crash running on 1 major version behind of macOS but an iOS app can run perfectly fine on iOS that's 4 major versions behind?
Am I completely misunderstanding what this setting does?
When should we use Always Embed Swift Standard Libraries?
----- EDIT
I've just checked the .app contents and it seems it does have the swift libraries in it, which would explain why t didn't crash on iOS 9.3.2. So an additional question. Why would the swift libraries be there when Always Embed Swift Standard Libraries is set to NO?
I had to read the documentation several times, to get a clue what's going on:
Always Embed Swift Standard Libraries (ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES)
Always embed the Swift standard libraries in the target's products, even if the target does not contain any Swift code.
This means
if you set ALWAYS... to YES, the libraries will definitely be embedded.
if you set it to NO, they will not always be embedded - they might or might not be embedded, regarding of how clever the build system is able to decide that it needs them or nor (depending on the target version or so).
This is a common misinterpretation: The negation of always is not never, it is just not always (e.g. sometimes or so).
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 have just create a simple project using swift language, then i compile and archive it to generate .ipa file. IPA file is so big, it is about 5 MB.
is it right(no problem) at there? when i create it in Objective-C, it is only about 500kb.
Yes, that's about right. The libraries containing the entire Swift language have to be embedded in the IPA. Those libraries are part of the app, not part of the system - because Swift has to work even with backwards compatibility, in part because it is constantly changing (independently of system updates), and in part in order to work on iOS 7 (where the system has never heard of Swift). And they are about 5MB in size.
To expand on matt's answer, here's a quote from the Swift blog on compatibility:
You can trust that your app will work well into the future. […] This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.
So if your newest app version was built with Xcode 6.0, and a user of your app is running iOS 8.1, and breaking changes to Swift were introduced to your app in between, your app won't break due to the iOS update. If your app just used system libraries, it could.
This allows the developers of Swift to iterate more quickly without needing to build backwards compatibility between every version.
An additional warning:
While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.
I have just create a simple project using swift language, then i compile and archive it to generate .ipa file. IPA file is so big, it is about 5 MB.
is it right(no problem) at there? when i create it in Objective-C, it is only about 500kb.
Yes, that's about right. The libraries containing the entire Swift language have to be embedded in the IPA. Those libraries are part of the app, not part of the system - because Swift has to work even with backwards compatibility, in part because it is constantly changing (independently of system updates), and in part in order to work on iOS 7 (where the system has never heard of Swift). And they are about 5MB in size.
To expand on matt's answer, here's a quote from the Swift blog on compatibility:
You can trust that your app will work well into the future. […] This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.
So if your newest app version was built with Xcode 6.0, and a user of your app is running iOS 8.1, and breaking changes to Swift were introduced to your app in between, your app won't break due to the iOS update. If your app just used system libraries, it could.
This allows the developers of Swift to iterate more quickly without needing to build backwards compatibility between every version.
An additional warning:
While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.
I am in a process of learning ios development. I am beginning to learn storyboards and i found out that its only IOS 5 compatible. I searched here and found some answers but i wanted to find out if it make sense at this point to use storyboards. How does application behave that requires 5.0 in the app store? Does it show up for people that have 4.3 and lower? When i look through new application i don't see any that says 5.0 required in the description. Does that mean most people do not use storyboards to develop apps yet?
Thanks in advance!
story board is available in SDK 4.2 with which you can build for iOS 5, you can certainly set your deployment target to 4.x and it will work like a charm..!!
Updated : as #FirozeLafeer told, I confirmed my knowledge that he is right - XCode displays a message that "storyboards are unavailable on iOS 4.3 or prior"
From Apple: Storyboards are supported in iOS 5 and later and are enabled by default for new projects. If your app must run on earlier versions of iOS, though, you cannot use storyboards and should continue to use nib files.
Source: https://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/AppDesignBasics/AppDesignBasics.html
I know this has been discussed before, but I didn't quote understand most of the answers. As you can tell from my other questions on here, I'm a complete newbie when it comes to app creation using XCode. I only have the SDK for iOS 4.3.
A friend of mine wants my app, but he only has an iPhone 3. He has not upgraded to iOS4. I don't see any reason my app couldn't run at a lower iOS version, it's pretty simple.
So what I'd like to know is how can I add previous SDKs to my XCode library? Do I just download a previous version of XCode w/ it's SDK and install that? Will that brick XCode? If so, what then? Is there anything I can do, I'd really like this to be written with 3.x and above in mind.
The most simple and more straight forward answers without jargon will be extremely appreciated!
Thank you!
if you have the iOS 4.3 SDK, you also can target any iOS version preceding it. In your Xcode project build settings, make sure your base SDK is set to the highest you have (in this case 4.3) but change your deployment target to whatever iOS version you want (try not to go lower than 3.0).
Make sure you test it though, to be sure that you are not using any features that are not present in the SDK version you are targeting.
Each download of the iOS contains each (most) of the previous versions. They're in installer bundles in a folder on the disk image. For example in the xcode_4.0.1_and_ios_sdk_4.3.dmg, (after you have installed the main package) open the Packages folder, install the iPhoneSDK3_2.pkg, and iPhoneSimulatorSDK3_2.pkg (if needed).