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.
Related
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).
Recently I have read a few articles about Swift 5 being ABI Stable (which basically means you won't need to pack app's own version of the Swift Dynamic Library within the App bundle) and here is the confusing part:
because Swift will be embedded within the iOS Operating System.
Now that sounds like Swift Dynamic Library would now go directly into iOS. Would that mean that Apps compiled Swift 5 will be able to run only on specific iOS versions?
You're on the right track, but the point is that the app would only run on a specific iOS version or later. The whole goal of ABI stability is to allow a Swift binary (i.e. an app) that was compiled with one version of Swift to be able to interoperate with a binary (i.e. a framework) that was compiled with a different version of Swift.
But yes, to make use of ABI stability, your app would only be able to run on iOS 13 (or whatever version it turns out to be), or later.
This is how things work in ObjC (and C and C++ and most languages). I can build my Objective-C app on iOS 10 and expect that it will link with Foundation and UIKit on iOS 11 without trouble. You can't do that with a Swift library today.
Our project is Objective-C. But after mixing with Swift, the IPA size changed a lot. Even if there are only a few Swift files, the package increases a lot and I don't know how to solve it.
See app size in app store, all updated apps are greater than 100MB, don't worry about that.
It's due to Apple new App Thining and Bitcode Impact introduced with iOS 9
Swift runtime libraries are copied into your application bundle and it is around 30MB alone.
If you create new app with swift and create IPA without anything, It would also very big in size (Check this on your system)
Check this link as well
https://forums.developer.apple.com/thread/16339
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.
In XCode I can specify Base SDK. I am wondering how does that work behind the scenes? If I am running an app, for example, on a device that has iOS 7 and my base SDK is iOS 6, then how come the app has the old 'look and feel'? Does XCode compile the older SDK and include it within my app or does new version of iOS comes with older libraries/SDKs?
In other words, does the run time know this app is compiled with lower base SDK and somewhere in UIKit's code it does:
if (lower SDK) {
//show old look/feel
} else {
//show new look/feel
}
or does the app itself include the old library and load it ?
Thanks
iOS applications are forward compatible with new versions of iOS. The reason is :
Almost all changes to the iOS versions are additive and hence an
application build using lower version still runs on the higher iOS
version.
Though, we need to take care of this point:
As frameworks evolve through various releases, APIs are introduced or
deprecated and behaviors of existing APIs may occasionally change.
Apple makes every effort to minimize changes that may cause
incompatibilities, in some cases providing alternate behaviors based
on the framework version. In rare cases, your code needs to determine
the framework version and adjust accordingly
To understand more, read this
Apple never changes / deletes / renames classes or methods. They only add new ones.
If they don't want you to use it anymore, they mark it as deprecated.
This is a very important point.
At compile-time, the compiler checks if all classes and method signatures are available in the SDK your building your app with.
If that's the case, you can build and deploy your app. Because those classes and methods will never be deleted from newer versions of the framework, your app will run just fine.
On the other hand, you can build apps and deploy them to systems, which do not actually support the current SDK. For example, you can use Autolayout (NSLayoutConstraint class is available since 10.7) and deploy it for Mac OS X 10.6. The compiler will not say a word.
The app will crash though on systems prior to 10.7.
You should set your target to ios 5.0 (via your project target settings) for making sure that none of the ios6 methods are used (or else a compilation error will prevent you from building it).
In order to support new features and check if ios6 is available on the device you have two ways :
During compilation (so you can still build your app with lower targets and newer together) use the following macro
#if __IPHONE_OS_VERSION_MIN_REQUIRED > __IPHONE_6_0
// Your ios6 code goes here
#endif
2: During runtime : [[[UIDevice currentDevice] systemVersion] floatValue] > 6.0
Your project is built against the Current SDK. If you have an older Deployment Target, then your code base is compiled against that. So if you are building against 7.0, but have a 6.0 deployment target, iOS 7 specific deprecations will not be triggered. Everything will be compiled against the oldest specified deployment target.
This will however put the pressure on you as a developer to make sure you are not using iOS 7 specific code. The compiler will still assume you mean to allow newer users to run your application as well and that all the newest methods are available to you and your latest version users. You can either test your code base against the older SDK with older devices or Simulators to make sure it runs well, or use an application like Deploymate that will test for methods you are using that could potentially cause problems.
If you plan to use any of the latest methods, you will need to wrap them up in the compiler if statement (like Peter Fidemraizer answered) or in normal if statements checking the version in the Foundation framework.
if (floor(NSFoundationVersionNumber) <= NSFoundationVersionNumber_iOS_6_1) {
// Load resources for iOS 6.1 or earlier
} else {
// Load resources for iOS 7 or later
}
Base SDK means, the SDK that your app is going to be built on. SDK's have some frameworks etc. that are differantiated as the version of the SDK changes. For example;
Let's say your current Base SDK in your XCode is iOS 6:
You can have the frameworks and feautres that iOS 6 SDK provided you to.
Your app will be usable in any iOS SDK that you specify as "Minimum iOS SDK". Minimum iOS device gives you some restrictions on components to use. be aware of that.
Your app will be usable in iOS 7 too, just like it works in iOS 5 or iOS 6. Because iOS versions have backward compatibility. That means, iOS 7 will run the apps that are running in iOS 6 too.
Let's say your current Base SDK is iOS 6 and you want to make it iOS 7
Your app will be built with a brand new SDK, so, if the new SDK has
some big changes in it, you will see the differences immediately when
you run the app. For example, in iOS 7 SDK, you can use status bar
(20 px) as a view component too. That may ruin your view hierarchy.
You need to test your app again to check that your code is compatible with iOS 7
If you want to use new iOS 7 frameworks or features, you are in the correct way, you can use them now :)
In short, Base iOS SDK is on what iOS version your app is compiled & built on. running it on a iOS X? device is a different concept.
Hope this helps
Base SDK is the SDK that you want to use to build the app. Use "Deployment target" to specify the minimum OS you want your app to run on.
If you want to know the iOS version, check out this question.
While updating the Apple frameworks itself,Apple takes care of support for multiple iOS versions;However you need to follow some basics checks, which are explained here