As in the Appole doc
it states that:
If you are building your own static library and using shell scripts to
package it in a .framework directory, you need to migrate to building
a framework with a dynamic library instead, as this is the correct way
to build a framework. Static frameworks are not a supported way of
sharing static libraries.
Why Apple disallows static library in a framework?
And is it a contraction of this post ?
Or maybe that post confuses static library and static framework?
All frameworks in iOS are dynamic, right?
Apple said:
A framework is a hierarchical directory that encapsulates a dynamic library, header
files, and resources, such as storyboards, image files, and localized
strings, into a single package. Apps using frameworks need to embed
the framework in the app's bundle.
A static library has to be loaded when app launches, without considering wether if its required right away or not. At the other hand a dynamic library is loaded only when it is required, hence improving the launch timings of the app and decreasing the memory pressure of the phone.
As an example consider I am using an e-commerce app which also allows to scan barcode and give details about the products. Now when I launch the app, I won't need the barcode functionality rightaway. I need to land inside the app first and start shopping. When I need to scan some barcode, I am happy to wait and let the framework loaded then but not at the start of the app.
Here is how Apple says this in its documentation:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Documentation link: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
we have implemented one universal application. It's a huge application and 6-8 SDKs are integrated, So the entire app is taking around 40MB size.
After all, we want to reduce the size of the application. So we started the investigation, where exactly it is taking more size. What I know is, I can check for useless view controllers, and I can remove 1x images. And these things we can do in Xcode. But what if we want to know the sizes it is taking in .ipa file itself. Is it possible ?
But is there any better way to know the .ipa size module/ SDK wise. Please let me know. Any optimisation tool are available ?
The following post has good advice on optimizations
https://medium.com/#mandrigin/ios-app-performance-instruments-beyond-48fe7b7cdf2#.btdp7bv5t
Also, you can try to access images in the IPA file using such tools like iBrowse and even better if you have a device with a firmware less than 9.3.3 to perform a jailbreak and investigate.
You can go even deeper by:
reducing image size using tools like imageAlpha & imageOptim which are both free
take a look at webP image format developed by google
https://developers.google.com/speed/webp/#webp_support_stylefont-weight_bold
What would be the best way to include a lot of images in the bundle? I have an index of (game) items thus about 4000-5000 image files (total 27mb so not that big). Just include the whole map in the bundle or maybe first write a script that converts them to NSData? I could imagine there would be a smart way to do this so the app wouldn't have to look through all images individually to find a single one. Would love to hear your thoughts.
27mb isn't a huge amount to download so the easiest option would be to put them in an asset catalog, as Ryan Heitner mentioned in his comment this will allow App Thinning to take place in iOS 9.
I'm not sure what you mean by this:
I could imagine there would be a smart way to do this so the app wouldn't have to look through all images individually to find a single one
Each image will need to have a unique name (this is true regardless of the number of assets you have) and your code references the images by that name so it won't have to "look through all images individually to find a single one".
Alternatively if you really want to reduce the initial download size you could use On Demand Resources (another upcoming iOS 9 feature) to store them on Apple servers and loaded on demand in your code. Presumably you won't be targeting only iOS 9 though so in this case you would need to host the resources yourself and load them using standard techniques (see here, here, here, or use a library.
You should pack them in a texture atlas.
Then, the texture atlas files should be imported in your bundled via a folder reference (blue folder icon) and not a group (yellow folder icon).
Images imported in bundle in folder reference won't be optimized be Xcode on packaging. So you can make your own file optimization using imageOptim. It can compress a lot more than what Xcode can do on JPEG and PNG images.
Question is simple how much space does these frameworks add to an app size?
https://www.aviary.com/
https://creativesdk.adobe.com/
I tested this here are the results:
My app size: 16.5mb
App size with AdobeCreativeSDK: 31.0mb
App size with AdobeCreativeSDK + CreativeSDKImageEditing(Aviary): 37.8
App size with AviarySDK: 23.2mb
So the sizes of
AviarySDK: 6.7mb
CreativeSDKImageEditing: 6.8mb
AdobeCreativeSDK: 14.5mb
So the core image editing framework parts are roughly the same size. However there this little catch:
The Image component is part of the larger Creative SDK and depends on
the Foundation SDK. Please see the Creative SDK Getting Started guide
to learn about setting your project up for the Creative SDK.
https://creativesdk.adobe.com/docs/ios/#/articles/imageediting/index.html
The only way to know for sure is to try it. Measure the size of the .ipa files (these are already compressed) before and after you add the frameworks.
It might be that depending on which part of the frameworks you actually use, the linker might strip away a lot of unused code.
I am trying to submit an application in App Store, and I need to decrease its memory a little bit, if this is possible. I tried a method which I am gonna describe below to make my app lighter, but with not luck.
Details
I followed these steps to see what was causing this large size
Make an archive of the project
Distribute it
Save for Enterprise or Ad-Hoc Deployment
Select the .ipa file and changed the extension to .zip
Extract it, and open Payload
Show the Package Contents
Contents
I had .png files with 680 Kb (when I added those where 32 kb approximately), I deleted them and I reduced the size of application by 2 MB. There are other files that take space but not considerably, except one executable file that is taking about 90 % of the .ipa's size.
Question
Is it possible to decrease executable file's size? If not then can you give me a hint where I should look to make my app lighter in terms of size.
P.S I use third party libraries like Vuforia SDK and libraries on GitHUB
How can I reduce the size of this executable file
You cannot reduce the size of the executable inside your built app bundle. This is your code! The only ways to reduce its size are:
Cut code. Obviously you can't do that because you would exclude functionality that makes your app work.
Remove an architecture slice. You should not do that because you want to build for all possible architectures.
Having said that... I have never generated an executable inside the app bundle anywhere near this large. Maybe you are measuring / building wrong:
Make sure you are archiving. Nothing else except an archive is worth measuring.
Make sure that you are generating a Release build when you Archive.
Make sure that your Release build settings include the full compiler optimization (smallest, fastest).
Suggestion how to reduce binary size from Reducing the size of my App:
Compiler Options
Setting the Optimization Level build setting to Fastest, Smallest [-Os]; and the Strip Debug Symbols During Copy build setting to Yes (COPY_PHASE_STRIP = YES) can dramatically lower the size of your compiled binary. These settings are the default for the "Release" configuration in Xcode projects.
Assets are almost always the main culprit of large apps sizes.
If you archive your app and export the IPA you will be able to convert it so a .zip by changing the extension and then unzip and look at the contents of the package.
If you sort by file size you will see which files are the largest. Keep in mind images with transparency are larger.
Some more insight as well: http://bjango.com/articles/pngcompression/
If you're truly concerned about the internals of the executable, build with a link map. That shows sizes by segment and by symbol.
e.g.
# Sections:
# Address Size Segment Section
0x0000AB90 0x00711D30 __TEXT __text
0x0071C8C0 0x00028D34 __TEXT __symbol_stub4
0x007455F4 0x00001A58 __TEXT __stub_helper
0x0074704C 0x00057452 __TEXT __cstring
[…]
# Symbols:
# Address Size File Name
0x000122A0 0x00000020 [ 6] ___Block_byref_object_copy_
0x000122C0 0x0000001C [ 6] ___Block_byref_object_dispose_
0x00012320 0x00000028 [ 6] ___copy_helper_block_78
0x00012348 0x0000001C [ 6] ___destroy_helper_block_79
[…]
I came across an article in the web which explains the process in the following 9 points:
Ensure that you have reached the maximum level of iOS stripping, for
more info on iOS stripping, see this post.
Enabling bitcode DOES increase the size of your over-the-air download.
In our case, it was the difference between 130 and 70MB. If you wish
to turn bitcode off, you can do so in your xcode project, or using a
post build attribute such as this one.
The Launch image in your xcode project is NOT optimized. While running
something through a compression algorithm doesn’t work because Unity
decompresses and stores images without much compression in order to
decrease startup time, it does work for the launch images that are
generated by Untiy after project generation.Run all your images
through a lossless compression algorithm in order to save a few MBs
(10 in our case).
If this isn’t enough, it’s time to start looking at your asset logs.
Run your build in Unity and open the Editor log, it’s this
ridiculously small icon next to your console preferences. In our case,
they are already optimized. With a 111MB in uncompressed assets, we
were able to achieve an over-the-air size of 70MB. Go over each asset
and change the resolution to the lowest possible quality that your
users won’t notice. The best compression setting is PVRTC for iOS.
While you are at it, check out Resource Checker in order to see large
textures in-memory. Reducing the resolution on these will also
decrease build size, as well as memory consumption. Also, please use
sprite atlases – you will see the wonders this does!
Check for unused libraries in your project, or libraries that are
using far too much space for their functionality. Commands such as df
and ls -lh might come in useful here, run these in your project files
and see which files really stand out and need to be reduced in size.
Keep in mind that these individual libraries do not necessarily have
the same build effect as your textures – generally, these are compiled
for multiple architectures, and if a library is 20MB, it generally
only affects your build size by about 6MB, due to the fact that
libraries often include architecture support for i386, arm64, and arm7
in the same library
Check that the /Plugins/Android is not included in your iOS project.
See this post for more information.
Make sure you don’t have any unused scenes in your build settings.
Build your project, and check out the archive before you submit it to
iTunes Connect. You can do so by clicking “Product -> Archive”,
letting it archive, and when it’s done, “Window -> Organizer” to pop
up this interface and find the build location.
Under “Products/Applications/game.app” Run the mv command to turn your
.app into a browsable directory.In this directory you’ll be able to
see a lot of the stuff we did, and also find inspiration for more
things you can do.
Now, there are a lot more things that could result in a bigger than
expected build size, and I’m sure there are a lot more things you can
to do get below it also.
If you’d like to add to this list, or have further questions (I’m usually happy to answer questions), leave a comment below with your specific use case, and I’ll try to help!
All the best,
Pim
If you have already checked all your assets (images, audio, etc... ) just check if you need all the external libraries (3rd party libraries out of the iOS sdk) that you import in your app.