We are looking for ways to reduce the size of dSYM files from Apple platforms. We need dSYM files just for symbolicating stack traces of crashes and in Crashlytics blog I read this:
These mappings actually hold much more than needed just for
symbolication, presenting some opportunities for optimization. They
have everything required for a generalized symbolic debugger to step
through and inspect your program, which may be a huge amount of
information. On iOS, we have seen dSYMs greater than 1GB in size! This
is a real opportunity for optimization, and we take advantage of this
in two ways. First, we extract just the mapping info we need into a
lightweight, platform-agnostic format. This results in a typical
space-saving of 20x when compared to an iOS dSYM.
Reducing size by 20x sounds very good but I found little information on how this can be done. Do I need to learn details of Mach-O DWARF to achieve this or some of the command line tools can do this? I also wonder if the stripped version can be used direcly afterwards for symbolicating.
Thanks.
Crashlytics converts dSYMs to cSYMs and uses these cSYMs for symbolication. This conversion happens on client's Macs. You might want to look into the final size of this cSYM file that is actually uploaded to crashlytics.
Related
I am looking for a way to symbolicate external app symbols (iOS) inside my own application (macOS), assuming I have the DSYM and system symbols.
Xcode symbolicates both app addresses as well as system framework addresses (UIKit, Foundation, etc.)
atos requires an image file and can symbolicate addresses from that image.
I am looking to symbolicate a large number of addresses in my own app. The addresses represent stack traces at various points in time. I would like to symbolicate the system framework addresses as well.
I found atosl, which uses dwarf.h and libdwarf.h to reimplement atos to varying degrees of success—however this seems like a very low–level approach.
Are there any other ways to symbolicate a large number of addresses at once?
Here is symbolication I use in tests (requires XCTest): https://github.com/avito-tech/Mixbox/blob/db3206c95b71f35ae6032ff9b0baff13026608f4/Frameworks/TestsFoundation/Reporting/FileLineForFailureProvider/StackTrace/ExtendedStackTraceEntryFromStackTraceEntryConverterImpl.swift
I use the code to highlight failures in tests in Xcode without requiring testers to pass file: StaticString = #file, line: UInt = #line everywhere. The code is less readable with this boilerplate, and also there is not much reason for such boilerplate, because ideally Xcode should be able to highlight stacktrace of test failure...
Note that there is an issue. If you do not have sources on the machine that executes the code, it doesn't symbolicate. Maybe it can be fixed quickly, I didn't even tried.
Also there are comments in the code about other options: atos, lldb, CoreSymbolication. I think CoreSymbolication is what you want to use. The solution I gave you is simple, more dependent on XCTest, less configurable, has some other flaws.
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
I just have some problems uploading my app to the appstore.
The problem is the 60MB filesizelimit for armv7! (See Screenshot)
There are almost no embedded images or something like that.
the application-file is only 0,5MB to big, but I'm sure it will increase soon due to next updates
Are there any possibilities to reduce the application size? Or maybe to change some settings for excluding the armv7 and only build for 64bit?
Our App is online since a couple of years and now we got "too big"? I see no possibility to "reduce" the code.
I build with AIR 22 and compiler options "-optimize=true -strict=true"
There's 2 ways.
The first is make your binary under 60MB.
2nd way is setting up project deployment target number.
ths following is I received email from Apple DTS
There are a few approaches to solving this situation:
Look through the suggestions in Q&A 1795, Reducing the size of my app. The section on compiler options is relevant for your scenario. Also, if you have data in your binary, such as long strings, tables, or encoded images, you should move those resources out of your binary and into external files.
https://developer.apple.com/library/ios/qa/qa1795/_index.html
The 60 MB limit is per architecture in your main executable. Identify sections of your app that would make sense as either a single framework, or as a small number of frameworks, so that they are built into a different binary.
If your app’s minimum deployment can be raised to iOS 9, the limit on executable size is higher, up to 400 MB for the entire executable. This is described at the link below.
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/SubmittingTheApp.html
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.
I am uploading my iOS application on iTunes. I am using MonoTouch for compiling my LibGdx Game for iOS. In Android it is hardly 7-8mb. But When I upload on iTunes AppStore then its goes to 78 mb. I dont know why ? Please Let me know.
I have also received this error from Apple.
Dear developer,
We have discovered one or more issues with your recent delivery for "Run Panda Run: Racing". To process your delivery, the following issues must be corrected:
Invalid Executable Size - The executable size of 72037504 bytes exceeds the maximum allowed size of 60 MB.
It's hard to give a definite answer without more details. There's a lot of things that can affect the size of the applications. Let's start with the basic.
What you should check:
First, ensure that your application is not being build with Don't link. That will create very big applications since you'll be AOT'ing nearly the full .NET framework that Xamarin.iOS ships;
Second, make sure you're building for a single architecture (ARMv7). FAT binaries (e.g. ARMv7 and ARMv7s) are build two times and needs twice the space;
Third make sure you have not enabled the Debug build (it's possible to do so in Release build, it's a checkbox). That will create larger binaries to support debugging;
Fourth make sure you're using the LLVM compiler. It takes more time to compile but it generates better (and smaller) code;
Those initial checks are pretty easy to do and are the most common reasons for getting very large binaries.
To understand where the size come from you need to know how the application are built.
The main difference between the Android and iOS version is that JIT'ing (just-in-time compilation) is not allowed on iOS (Apple's rules).
That means the code must be AOT'ed (ahead-of-time compilation) and that process creates much larger executables (because IL is way more compact than native code);
If your code is generic-heavy then the final binary can get quite large since it will need to natively compile every generic possibilities (many cases can be shared, but value-types cannot).
What you can do to reduce size:
First try to reduce your managed code size. The easy way to do this is the enable the linker on every assemblies, i.e. Link all assemblies in your project options.
Many people think it's not worth linking their own code - because they know it will be needed at runtime (so the linker cannot remove it) or else they would not have written that code.
That's half true. The linker might not be able to remove most of your application code but if you're using 3rd party assemblies they are not likely 100% used. The linker can remove that extra code (and also remove, from the SDK, all the code that is kept to support that unneeded code). The more shared code you have the more the linker can help you.
Less IL code means faster AOT time, which translate to faster builds and smaller final binaires (including the executable size).
Note: there's a lot of documents and blog entries on how you can control the linker to skip some assemblies, some types or method from being processed/removed.
Second try to reduce your native size. If you're building native libraries then have a second look at them as they will be statically (not dynamically) linked to your final binary (another rule for iOS applications). Some of them might not be worth (feature wise) their weight in your final binary (and there might be lighter alternatives).
Debugging should not be enabled, as it will make the build unnecessarily large.
For more information refer : https://learn.microsoft.com/en-us/xamarin/ios/deploy-test/app-distribution/app-store-distribution/publishing-to-the-app-store?tabs=windows
I had the same problem but in my case I had minimum os version set to 8 in the info.plist causing a larger .ipa file. I changed this to version 10 and was able to pass the size requirements. Even 10 is a bit generous