I was trying to minimize the code size in my iOS 4 game, so I tried enabling all the strip-related commands, and using the -Os flag.
However, strangely I still found that the binary was quite big, and when I manually tried to strip the binary using the console ("using the strip command"), it actually reduced it from 18 mb to 12.3 mb.
Does Xcode actually use a different strip mechanism, or anything like that? The problem with using the console strip command is that it gives a message saying that it invalidates the code sign, so I wonder if it's possible to get the code signing working after this strip command.
Did you choose "Yes" in both "Deployment Postprocessing" and "Strip Linked Product"?
Also, check that you have the right values for the build configuration you try to optimize.
Related
Some iOS 9 devices in the wild seem to crash with the error message that I receive from the very basic crash reporting in Xcode only
dyld: malformed mach-o: load commands size (16464) > 16384
Unfortunately that's all the info I get. I can't even debug or reproduce locally.
Can anyone hint me into the right direction here?
It occurs after updating my Cocoapods, so I guess there's one of them (or their dependency) that misbehaves.
After some investigation of my mach-O binary, I saw that the sizeofcmds is really 16464.
If I understand correctly, there seems to be a load command size limit of 16384, can anyone confirm this?
Does that mean I should remove dylibs and everything should be fine?
At WWDC18 I went to an Apple engineer who is working on dyld. Here’s what he had to say:
The Dyld code is downloadable from https://opensource.apple.com (the one specific to us can be found inside macOS 10.12)
For iOS 9 the maximum size of load commands is indeed 16k aka 1 memory page (There’s no way around it! This is imposed by the OS itself. For customer service telling people to update to iOS 10 (all devices that run iOS 9 can except for iPhone 4S) would be viable.)
Since iOS 10 the maximum size of commands is 32k
Majority of the size of the load commands is determined by strings (paths) of the frameworks (use command otool -L to see them
Possible solutions:
Use less libraries (that was our goto solution thus far, but we will change to umbrella libraries (see below))
Shortening names (might screw up header lookup of cocoa pods, maybe use head maps to fix that inside the Xcode build process → maybe more (high-level) info in WWDC18 session “Behind the scenes of the Xcode Build Process”)
Try to build static archives for libraries (should not have dynamic resources otherwise make copy phases and figure out where resources are)
Build frameworks that re-export other frameworks (umbrella frameworks). Use -reexport-l as a linker flag (not done often) → gonna make some runtime overhead when starting the app, also uses a bit more memory (man ld → for info on re-exports)
The engineer recommended to file a bugreport via bugreport.apple.com, because in the future even hitting the 32k limit is possible.
I found a solution that will (at least temporarily) work for me - but I still encourage everyone to provide a real solution and more detailed insights.
Anyway:
Extract your binary
Xcode Archive
Export as IPA
Rename YourApp.ipa to YourApp.zip and extract
Navigate to the subfolder payload to find your YourApp.app
Right click & Show Package Contents of your YourApp.app file
Copy your binary YourApp (no file extension) to a different location
Investigate your mach-o binary
Run otool -f on your binary
Note the align for both architectures are listed which, for me, says 2^14 (16384). This seems to be the threshold for the size of load commands.
Run otool -l on your binary
You'll see that the different architectures and their load commands are listed - as well as their sizeofcmds (size of commands).
Now the funny thing:
For arm64, the sizeofcmds (16464) was larger than the align (16384), while it wasn't for armv7.
Now I haven't found enough documentation on this, but I assume that align symbolizes a threshold that should not be reached by the load command size. And also that it adjusts automatically (since we are definitely not having that many frameworks in our app, there have to be apps that have more).
So I guess the error came from this unlikely case, that the sizeofcmds was different in between the architectures AND that one of them was actually valid (so that the align was not automatically adjusted).
Please correct me if I'm wrong, I am just assuming here and I really really want to understand why this happens.
Solve the issue
Remove frameworks until you are under the sizeofcmds for both architectures.
I know this is not scalable, we were lucky (and stupid) that we still had one barely used framework in there that we could easily remove.
Fortunately this only seems to be an issue on iOS9 and will therefore loose relevance over the next months, nevertheless, we should find out if I'm right
Investigation ideas
My assumption that the align is automatically adjusted could be investigated by just putting in more and more frameworks to see if it actually does.
If so, adding frameworks would also solve the original issue - not nice, but at least slightly more scalable.
Sidenote
I don't feel like I shed enough light on the origins of this issue and I had a lot of assumptions.
While my solution works, I really hope you feel encouraged to investigate this as well and give a better answer.
So here's the problem:
The Mach-O header size is expected to be 16k (optimized for the platform's pagesize). In the reference by rachit it's basically the same thing but the limit is 32K. Both are correct in that this is hard limit of dyld, the loader.
The total size of load commands exceeds this max size. Removing frameworks and libraries works for you because that removes LC_LOAD_DYLIB commands (And, there is no reason why you'd need so many frameworks anyway). Instead of removing frameworks, build your app from the ground up starting with the core frameworks, and adding so long as you get linker errors.
btw, 'Align' has nothing to do with this - Alignment refers to the fat (universal) architecture slices, and doesn't have anything to do with the Mach-O.
I was able to resolve this for my team after reviewing the result of otool -l. Turns out we had the same directory included in our framework search paths 5x causing our dylibs to be added as rpaths 5x.
I have a Unity3D project that I've already released for iOS via Xcode. Previously the archive size was about 30-40Mb which I'm happy with.
I've now changed a few things within the Unity project, and rebuilt it for Xcode. Now when I archive it, the size is around 110Mb, which is huge compared to the previous file size. I only changed the logo, and splash screen design.
Also, when I rebuild the older version, the size isn't 30-40Mb anymore, it's 110Mb too!
So I'm guessing this is something to do with the new Xcode for iOS8? Not 100% sure, hence why Im asking.
Thanks.
Try to turn off BitCode. Open XCode => Build Settings => search Enable BitCode. Set it to No.
Have you read this?
http://docs.unity3d.com/Manual/iphone-playerSizeOptimization.html
Also it can be fault of stripping level, try to use micro mscorlib.
In addition you can take a look at Decrease Your App’s Code Size from Mac App Programming Guide.
https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/Performance/Performance.html#//apple_ref/doc/uid/TP40010543-CH9-SW2
I believe part of what is happening here is the additional overhead for the arm64 slice (unless you were already including the arm64 slice previously). I would not expect that much of an increase in size for the arm64, but it would still be roughly X2 on the app binary (minus the resources).
As of Feb 1, Apple requires arm64 support as well as the app being built with the iOS 8 SDK. The default Xcode build setting enables arm64.
What you can do is Show Package Contents on the xarchive and work your way to the app executable binary. You can then compare the size difference on the app executable binary from before and now. You can also run lipo -info on it to see all the slices from before and now. Note I am assuming you have an older xarchive to compare with.
I would then probably diff the rest of the resources (use something like Araxis merge) to see the differences in the files. This will let you see what resource files changed or got added. If your diff is only the executable, then you have isolated were the size difference has come from.
The 'Estimated App Store Size' reflects the installed app size, not the download size.
I'm basing this off the following test:
(Unity app build) Estimated App Store Size: 140.8 MB, size listed in store: 33.4 MB. The splash images alone inside the package add up to 30 megs uncompressed (all my jpegs were converted to pngs) so there's no way the installed size is 33.4 MB. After install, if I go to settings -> general -> usage -> Manage Storage I see the app is 141 MB installed.
I'm not sure how to estimate the download size, which is what matters if you have an app you want to be downloaded over cellular network and needs to be under 100 MB downloaded.
I added this as a comment to the question, but I wish I had read this as an answer, so here it is.
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 m using Xcode 4.2 and i have add AviarySDK 2.4.4 in my project.
Application runs fine in Simulator 5.0 and 4.3. I also test it on device having ios 4.1. So i want to generate .ipa file for my client. But by some reason it can not generate Archives.
It gives following error
"/usr/bin/strip -S /Applications/Projects/AppName/AppName/AviarySDK/Resources/AviarySDKResources.bundle/AviarySDKResources -o /Users/User/Library/Developer/Xcode/DerivedData/WDYWT-avjpbcnwjylobvgevipvsqttnopd/ArchiveIntermediates/WDYWT/InstallationBuildProductsLocation/Applications/WDYWT.app/AviarySDKResources.bundle/AviarySDKResources
/usr/bin/strip: for architecture armv7 object: /Applications/Projects/AppName/AppName/AviarySDK/Resources/AviarySDKResources.bundle/AviarySDKResources malformed object (unknown load command 10)
error: strip /Applications/Projects/AppName/AppName/AviarySDK/Resources/AviarySDKResources.bundle/AviarySDKResources: /usr/bin/strip exited with 1
"
Any help will really great. Many thanks in advance.
Strip errors are generally caused if you have duplicate debugging symbols in your project. Just try the following:
First Method:
Go to build settings of your project
Type Strip in the search Bar.
Under Strip Debug Symbols During Copy, you shall find Debug and under that you shall find Any SDK.
Select NO in Any SDK, select YES in Debug and select YES in Strip Debug Symbols during copy.
A little below you shall find Use Separate Strip. Select YES.
Check that Strip Style should remain All Symbols [If not then change it to that].
Second Method:
Since your error also mentions derived data, their might me duplicacy of your derived data as well. Delete Your project file from the derived data folder.
If you don't know where the derived data folder is, Google it.
I am using aviary in my current project. I have a Mac Mini and a MacAir [for work at home].
I was facing the same strip issues with aviary which I resolved using the first method mentioned above.
It took me a week to figure this out cuz i am a relative newbie in development and nothing regarding this issue has been mentioned in aviary forums as well.
PS:
MacMini: Xcode 4.5
MacAir: Xcode 4.2
Hope this helps
I ran into a strange problem today, after renaming a couple of images in my app and making sure they work on a device as well as the simulator, I used Build and Archive as I always do to build my app to distribute to the testers.
However, this time I got strange reports from the testers saying the images were gone, so I installed the build on my phone and to my surprise they were gone as they said. Tried to do a clean and build again but no change.
When I open the .app archive I can clearly see that many, but not all, of the images have turned blank, they appear to be the same physical size on the disk and they also seem to have the correct height and with when I press space to preview them, I can't however open them with photoshop for example (the file-format module cannot parse the file).
This is very confusing and as I have to get the build ready for testing very soon I would very much appreciate some help in this matter.
Your source PNGs seem to be slightly off-standard or at least incompatible with Apple's pngcrush. Make sure you use a commonly well functioning tool for creating the PNGs - when in doubt reconvert/resave them.