I am developing with Xamarin IOS. Recently I have faced the problem of too large APP size of my iOS application. I have enabled all things from iOS build menu that can help reduce app size such as Linker, LLVM optimizer and so on.
Unfortunatelly it has reduced app size not enough. In App Store it has something around 86Mb, what is over the top.
Than I have noticed such thing in build menu as Supported Architectures.
In configuration of two architectures (ARMv7 + ARM64) it produces two app files in app archive.
whereas if target only ARM64 it would be only one: .
So, my questions:
What does AppStore sends to user device when the one downloads the Application? Does it sends only necessary files ore all at once? How can I check estimated AppStore sizes of output apps for each CPU Architecture? Thanks in advance.
Related
I want to analyze the size of an iOS app I created using flutter. As per this flutter doc, you have to archive your app in Xcode and distribute it (Ad Hoc, Development, or Enterprise) after to see the size of your app. However, I am, unfortunately, not enrolled in the apple developer program since I'm only doing some testing for my bachelor's thesis and thus can't distribute it.
So how do I get the size of my flutter iOS release build?
One thing I did try, was just checking the app size in the iOS settings (General>Storage), but I'm not sure that's really accurate because the flutter release build is surprisingly a lot bigger in size compared to the debug build (110 MB vs 230 MB) according to the settings.
Select "Generic iOS device" from the list of devices.
Build your project.
Search for .app file and copy that file to some other location.
Zip that file.
Change extension from .zip to .ipa. It will reconfirm if you want to keep the same or update it to the new one.
This will give you APPROX size of your app.
Please check section Create the App Size Report in below link https://developer.apple.com/documentation/xcode/reducing_your_app_s_size
I are maintaining an application with ArcGIS.framework for iOS. I am upgrading from version 10.2~ to 100+. I have prolonged this hoping that at some point the application size problem will be resolved. The application size with the newer framework went up from just 26MB to over 360MB. This will not be accepted by clients. I have been searching for a good and simple way of reducing the app size without using app thinning which requires bitcode to be enable which for some other reasons I can't enable.
Stripping x86_64 and i386 architectures does not reduce the framework size that much.
Are there flags, other compiler or linking settings we can provide Xcode with at compile time?
You can take advantage of App Thinning without having to enable bitcode, and if you're targeting iOS 9 and upwards you will only ever see a Thinned .ipa deployed to any device (although a Universal .ipa will get generated and uploaded to iTunes Connect).
In practice, that means if you're using Runtime 100.x, your app will use app thinning.
Here is how we assess this to see what will end up on an iOS 9+ device (required for Runtime 100.2):
In Xcode's menu, select Product -> Archive (make sure you have Generic iOS Device or an actual device selected as the target device).
Once finished, the Organizer window should pop open and you should be able to see the latest archive in the archives tab.
Select the archive and hit the Export button on the right.
Choose Development and hit Next.
Choose a team if asked.
In the App Thinning menu, choose a specific device and hit Next.
Select your signing method and hit Next.
Review the summary, and hit Export.
You will end up with a folder containing the thinned .ipa and some reports on the thinning process, including what usage to expect to see on the device.
For example, here is the App Thinning Size Report.txt for a Runtime app targeting iPhone 8 (with bitcode disabled):
App Thinning Size Report for All Variants of MyRuntime100App
Variant: MyRuntime100App-iPhone 8.ipa
Supported devices: iPhone 8
App + On Demand Resources size: 31 MB compressed, 89.7 MB uncompressed
App size: 31 MB compressed, 89.7 MB uncompressed
On Demand Resources size: Zero KB compressed, Zero KB uncompressed
So the above app would be an over the air download of 31 MB and would take up 89.7 MB on the device (and that example happens to include a 19.8 MB Mobile Map Package).
Hope that helps.
I would also encourage you to post future questions to our iOS Runtime SDK forum if you can.
Adding the arcgis framework manually rather than by cocoa pod will help to decrease its final downloadable size on the devices by about 70 MB
Here is how to do that
Download the SDK from https://developers.arcgis.com/downloads/apis-and-sdks
Install the .pkg file , it will install by default to ${HOME}/Library folder.
Open your project on xcode and drag the ${HOME}/Library/SDKs/ArcGIS/iOS/Frameworks/Static/ArcGIS.framework to your frameworks folder of your project through xcode
Add framework to the search paths of your project https://developers.arcgis.com/ios/latest/swift/guide/install.htm#ESRI_SECTION3_2304BFA5F5A14A679B5A92B2DDEC859E
Note that the ipa size may not different in size but the final downloadable app size will be less by about 70MB.
I have a framework I finished writing (with bit code enabled). I want to know how much is my framework is adding to an app after they upload the app to the store.
I understood that i need to archive the app to ad hoc and choose a variant (a device) then recompile with out my framework and see what is the difference.
When i compile the demo app with bitcode. After selecting ad hoc it won't le me select variant xcode returns 14 domain error.When i remove bit code i can see the variants. Is this ok ?
You could simply create a Simple View Application and archive then export it once with your framework and once without. Then compare the two IPA sizes.
Update
To have the size for all architectures, export your iPA with the Export one app for all compatible devices option.
If you need to have the size for a special architecture use the Export for specific devices option.
Before iOS 9, our IPA size was roughly 6MB. After Archiving and exporting our IPA through Xcode 7, our IPA increased to about 17MB. Upon further investigation, we found out that enabling the "Bitcode" option in the export settings is what caused the large filesize jump.
My question is this: if we enable this option, will our IPA size be 17MB in the store? Or does Apple do something with the bundle to make it roughly the same size as before (6MB).
There's not much info about Bitcode out there right now, and I'd like to be informed before submitting to the store. 6MB and 17MB is enough of a difference to be concerned.
Bitcode is an intermediate representation of a compiled program. Enabling it will increase the build (ipa) size on the developer front.
iOS can run on different CPUs (i386, x86_64, arm, arm64, etc.), if you want to run a program on any iOS setup, then the program should contain object code for each platform. When you run a program, OS reads the ‘Table Of Contents’ and looks for a slice corresponding to the OS CPU. For instance, if you run on x86_64, then OS will load object code for x86_64 into memory and run the program.
Currently, all the apps on the AppStore contain object code for arm and arm64 CPUs. Moreover, third-party proprietary libraries or frameworks contain object code for i386, x86_64, arm, and arm64, so you can use them to test the app on device and/or simulator.
How does the Bitcode works?
When you submit an app (including Bitcode) Apple’s ‘BlackBox’ recompiles it for each supported platform and drops any ‘useless’ object code, so AppStore has a copy of the app for each CPU. When an end-user wants to install the app - she installs only the version for a particular processor, without any unused stuff.
Bitcode might save up to 50% of disk space per program.
Reference: http://lowlevelbits.org/bitcode-demystified/
Since Xcode 4.5, we are unable to build for armv6 and thus unable to support devices like iPhone 3G anymore.
Would it be possible to use, say, Xcode 4.3 to generate a properly signed armv6 binary and then use lipo to combine that binary and the Xcode-4.5-generated armv7 binary into a fat one?
How would I go about this? Does anyone know a good tutorial?
Would the resulting fat binary be allowed for submission to the App Store?
The code signature would no longer match after modifying a binary using lipo. So the bundle would need to be re-codesigned afterwards.
Apps built with Xcode 4.4 and even earlier will still run just fine on iOS 6 devices; and there are reports that Apple is still accepting apps built with the iOS 5.1 SDK.
Objective C will allow you to use some of the newer APIs not in the older linked frameworks via calling them thru the Objective C runtime by name. (Of course, the app should check for their availability on the current device first!)
You can even support the new iPhone 5 display from an earlier Xcode and pre-iOS-6 SDK by simply including a 568#2x tall Default image in the app bundle, and setting all your app's window and view sizes and resizing properties properly. UPDATE: Apple is no longer accepting apps built this way when submitted to the iTunes App store.
ADDED:
Another potential solution is to split your development into two similar apps. One for iOS 4.3 and up. And one for iOS 4.2.x and lower with not iOS 6 and iPhone 5 support. Two different apps in the app store. However it is unknown whether Apple will allow this.
It appears that someone else figured out how to do it, see this SO question.
I haven't tested it yet myself, though.