Is there any iOS app size inspection tool? - ios

I am working with an iOS app which uses both objective-c and swift code. Currently app IPA size became large. Some resources are included but may not be used in Release IPA. I want to find out which resource should be removed and which resource are making my app size increased unnecessarily. I wonder if there is any such tool or xcode profiler to analyze.

So far the best tool I found is https://github.com/tinymind/LSUnusedResources
LSUnusedResources
A Mac App to find unused images and resources in an XCode project. It is heavily influenced by jeffhodnett‘s Unused, but Unused is very slow, and the results are not entirely correct. So It made some performance optimization, the search speed is more faster than Unused.
Export unused resource list
Use this tool and export unused/unreferenced resource list into unused.txt
Remove references from Xcode .pbxproj file
Use the below python script to delete references from project.pbxproj file:
file = open("unused.txt","r")
data = [line.rstrip('\n') for line in open("project.pbxproj", 'r')]
newFile = open("project2.pbxproj","w")
def removeLine(imageName):
temp = data
for line_s in temp:
if line_s.find(imageName) != -1:
data.remove(line_s)
else:
continue
for line in file:
if (len(line) > 5):
tokens = line.split("/")
len_a = len(tokens)
imageName = tokens[len_a-1]
removeLine(imageName.rstrip('\n'))
for line in data:
newFile.write(line)
newFile.write('\n')
And an alternative script, in bash:
#!/bin/bash
UNUSED_ASSETS_FILENAME="unused-images.txt"
XCODEPROJ_PATH="zilly.xcodeproj/project.pbxproj"
while read LINE; do
FILENAME="$(basename "$LINE")"
if [[ $FILENAME =~ (png|jpeg|jpg|gif)$ ]]; then
echo "Removing '$FILENAME' references from $XCODEPROJ_PATH"
sed -i '' "/$FILENAME/d" $XCODEPROJ_PATH
fi
done < $UNUSED_ASSETS_FILENAME

First of all, are you using the latest Xcode version? Xcode 8.3 produces binaries 2-3 times larger than Xcode 8.2, and Apple fixed this bug in 8.3.1.
Also, you can check out On Demand Resources, which will let you upload your heavy assets to App Store, but not bundled within the app - and when the user will download your app, iOS will automatically download necessary assets for properly running the app.
You can change the .ipa file to have the .zip extension and unpack it. You later on can use simple inspection (Disk Inventory X for instance) of the unarchived .zip file and
see what's going on there.
Also, it is probable that you're looking at a App Store Submission .ipa, which will contain necessary dSYM files and other miscellaneous data.
You can check what App Store .ipa sizes for different devices the app will have by following steps in this answer.
And last but not least, check out this Q&A by Apple on reducing the size of your app.

Recommend an effective tool to analysis App Size:
WBBlades
Advantages:
Directly measure the size of .a or .framework after linking, no need to compile again and again.
Clearly show the differences between two versions,helping you to control the increasing size.
Effectively detect unused Code (ObjC & Swift)
Widely used in apps of Wuba inc.

Related

For current Xcode version (higher than 12), when I archive an app for release, does the unused code in pods removed?

Today, iOS developers use lots of third-party to faster development. I have a question for Xcode archive process.
When Xcode archive an app for release, when I choose optimizing for smallest and fastest, the useless code will not in ipa file? or the useless code also archived in ipa?
For Android Studio, this procedure maybe called minimize?
Does Xcode automatically do this for release ipa?
Thanks
There is no build settings in Xcode which removes unused/useless code for ipa
Moreover the compiler setting you used
Fastest, Smallest [-Os] solves this: The compiler performs all optimizations that do not typically increase code size. This is the preferred option for shipping code because it gives your executable a smaller memory footprint.
This will help only to reduce the memory footprint of your app, it will not remove unused code
To have a closer look and if you are using dynamic frameworks you can check the contents of your .ipa you will see a folder named Framework inside that you will find all the pods as .framework and you can even see the files and resources inside them.
So answer you're question Does Xcode automatically do this for release ipa? -> NO
I'm not sure if "minimize" is the term used in Android, isn't it code shrinking or tree shaking? Other terms include dead code elimination, and code stripping.
To answer the question, neither seem to be done: I added a dependency (Swift Package, specifically SQLite.swift) to a target in an Xcode project, and the size of the application (when archiving/ with release build configuration) increased from 4.3MB to 6.6MB.
It's something I unfortunately haven't cared about much, and your question is good. I hope someone else answers with a better answer.

Why is our app size increasing drastically with little change of function?

We have an app currently in the App Store, and its size is as follows according to iTunes connect:
iPhone 6: Download size 21.8MB, install size 28.5MB
Now this is not too bad. But with a newer version we have uploaded to iTunes connect, the sizes are like this:
iPhone 6: Download size 35.5MB, install size 73.1MB
And the original package compressed size is 114MB.
Now this is too large, even unacceptable. I have checked the .app file within the archive(which is 178MB), and surprisingly discovered that my code alone takes 55MB(which in debug mode is only 11MB), and swift standard libraries around 40MB.
The function of code of this version does not differ much with the previous: we added iPad support, added a few images(the asset is 7.8MB on both debug and release archive, which is not a problem), and updated our project to swift 3.
All the release sizes above are with whole module optimization turned on. Might there ba a configuration in my build settings that may leads to this huge size? If not, what else could I do to reduce the app's size as much as possible?(especially the 50MB codes)
Besides, WHAT is the cause of this? Is it swift 3 since we didn't change our code much?
We also face such kind of issue in our previous app. At that time we make below steps to check which part of application is taking more space.
1) Copy Final IPA file which was generated by Archive.
2) Rename "application.ipa" to "application.zip"
3) Unzip application.zip file.
4) Open unzip folder and find "application.app" file in "Payload" folder.
5) Right click on "application.app" file and select "Show Package Contents".
6) After click on that you will see the list of all the files added in your final application bundle.
From that file listing you can see which file is taking lager space and act accordingly.
Assets.car : it's for image assets added in your application.
Frameworks : all frameworks list which are added by you in your code.
file_name.nib : This file is for your xibs added in your project.
file_name.storyboardc : This file is for your Storyborad added in
your project.
Apart from that their will list of font, images, videos, bundles,
etc. files.
From these step you can get an idea that is the cause of build size.

How to decompile iOS apps?

I want to see the code of an iOS app.
The app I downloaded is .deb.
First question: Is it possible to install .deb file on iOS or I downloaded a wrong file?
After unpacking the .deb file, I got some files, including .nib, .storyboard and some other files.
My main question is, How to decompile these .nib files?
I tried to decompile these files using NibToXibConverter, but I didn't succeed.
Answer to your first question:
I think you downloaded the wrong file. .deb files for iOS are common for jailbreak community and not for apps, I think all of the Cydia stuffs are packed into .deb's. If your app is especially made for the jailbreak scene then you may try to install it using Cydia's auto install feature on a jailbroken device.
Answer to your main question:
This is general info about decompiling and modifying iOS apps (not specific for nibs, but you may still find it useful).
iOS apps are distibuted in .ipa archives, which are ordinary zip archives. They contain, usually one executable in the form of Mach-O file, and resources like .plist, sounds, images - every resource you include in your xcode project. Decompiling the executable file is only possible on jailbroken iDevice, because it is encrypted especially for the current device and the magic key to decrypt the binary is burned inside the device CPU and as far as I know there is no software way to read that key. The encryption system here is called FairPlay.
Briefly described, one way to decrypt that binary is to have the app installed on a jailbroken device, and launch it from command line using a debugger (gdb) which you can download from Cydia. You have to set a breakpoint somewhere, and when your code execution pauses at the breakpoint, you are doing a memory dump of the device ram - and that is your decrypted bin.
So when you have the decrypted binary, you can run one tool called "class-dump", and get the information for declared classes and their methods if the app is written in Objective C. Once you know this information you can alter the implementation of given method from some class used in your app using "Cydia Subtstrate" a.k.a "Mobile Substrate". In fact that is the way all of the jailbroken iOS tweaks are made. Basically you are hooking a method call, and when that method get invoked, it uses your implementation. Furthermore your implementation can call the original implementation, and that is really useful if you want to make some small code addition.
I am not sure whether those things possible in Swift, but if you are dealing with a Hybrid app like the ones done with cordova, phonegap, etc., then you can see all of its javascript source because it is persisted as a resource inside the "ipa" file. In addition you can alter that javascript code directly if you have a jailbroken device and find where the app is installed on file system (usually /var/containers/Bundle/Application/uuid_for_your_app/). However, I think there is no way to get that patched version and redistribute it (correct me if I'm wrong).

Xcode Archive Is Too Large

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.

Decrease iOS Application size to App Store

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.

Resources