I want to understand which of the third libraries I'm using affect my app size the most (Mixpanel, Crashlytics, etc...).
How can I do that?
If your 3rd-party library are all dynamic ones, it's in folder of the bundle as Harshal Valanda shows.
If you have some static libraries linked, it may be hard for you to find which one contributes the most in your final binary.
Find a .app file in project and file show in finder.
Show package contents of .app
In package Contents you get information about framework, icon and file size.
Related
I have an iOS static library.
As a matter of fact, I have four variants of it:
Debug-iphoneos/libopende.a
Debug-iphonesimulator/libopende.a
Release-iphoneos/libopende.a
Release-iphonesimulator/libopende.a
I want to link my iOS app against this static library using Xcode.
To do so, I go to Build Phases, and in Link Binary With Libraries, I click the '+' to add one, using Add Other.
Now I have the problem of which variant I should be adding. So I just pick one of the .a files, and hope Xcode is smart enough to find the others?
Anyways, if I do this, the linking fails saying it can't find libopende.a file.
So, is it even possible to do what I want, without first building a 'Framework' instead of a set of static libraries?
Ok, so when linking against a static iOS library, you need to know that:
It does not matter which .a file you add in the Build Phases - Link Binary With Libraries panel. Any of the four .a files will do, it only takes the file name, not its path.
To actually differentiate between library variants for Debug/Release Device/Simulator, you need to specify the correct library paths in the Build Settings - Library Search Paths.
What are the different ways available so that We avoid code tempring in ios. Please suggest any good way that we can check at server level to avoid code tempring not in source code. And how we can check that server call from app is from authorize app.
iOS apps are most secured itself. It can not be tempered easily. While building your app no code file and XIB's kept as it is.
You can check it in these steps:
Right click on .ipa file and select Open With and then Archive Utility
Then it will create folder named Payload with .app file in it.
Now Right Click on .app file and select Show Package Contents
This will show you one folder with multiple files in it. Now try to open each file and read it. It will be in encrypted way.
For reference read this link
I was just wondering if app extension (f.e. stickers) affects containing app size in the App Store?
As far as I can see in the build package, there are resources, main executable file and executable file for the extension. So it probably won't affect final app size, but I'm not sure and cannot find any information in the internet.
Can anybody help me with this question?
Yes, the app extensions will affect the final ipa file size.
Build out your two .ipa files. One for the project without the app extension and one with the app extension. Compare those two file sizes to see the size difference.
To see the size of the .appex, rename your .ipa to .zip and double click the zip file to extract it. Open the extracted folder and control+click the .ios file. You can now look inside that folder and see what is changing.
Until xcode6, we had:
library target "appshared" builds a static lib and embeds multiple other static libs
Multiple apps embed static lib appshared, and automatically get the embedded static libs too
Now, with Xcode6, and a new 3rd party static lib (from MixPanel, who never quite seem to know what they're doing with packaging iOS binaries), score refuses to embed the new static lib, saying:
"can't locate file for -l[library name]
file: -l[library name] is not an object file (not allowed in a library)"
What's wrong with this new library, and ... any ideas what I have to ask the provider to fix in their build setup? (they don't share the source, sadly)
facepalm
It's a bug in Xcode 6 - nothing to do with the particular library.
Xcode no longer supports spaces in folder names, even though this has been a core requirement from Apple Corp for all Mac software for > 15 years; apparently, they don't test this for Xcode any more, and someone wrote some very bad code (probably: used the wrong (20 years old) method calls for manipulating file paths; if they'd used the correct ones, space-handling is automatic and implemented by the OS, IME!)
Solution: when you drag/drop libraries into Xcode 6, if there is a space in the folder name, Xcode will corrupt the build settings, and add a library-import-path for each word in the folder name.
You have to edit your Build Settings, find your library search paths, and you'll see it has lots of stupid values. Delete those, put the real path, and surround it in double-quotes.
All will then work fine.
I have a workspace that contains a static library and a project using the library, I'm then building the project (using Jenkins) to create an archive for ad-hoc distribution.
The resulting file size for the built library is reported as being 10.4Mb, yet .ipa is reported as being 4.2Mb.
How can the .ipa be so much smaller than the library, and yet the app runs when installed so it must be containing the library.
This have multiple reasons:
Static libraries contains additional information required for linking (like methods names and so on).
IPAs are compressed archives. Similar to ZIP just with another file ending.
The most likely explanation is that the library contains symbols necessary to linking (as well as debugging symbols, possibly), while the ipa file has been already linked (thus it does not contains information for the linker) and stripped of debugging symbols.
On another account, the ipa file is just a zip file, so its content is also compressed.
The algorithm that apple uses to compress into .ipa is very good .
If your bundle doesn't contain too many images the percentage can be as low as 15% (from the uncompressed size on disk).