Can I extract a library .a into a iOS project from .ipa? - ios

I have an app installed, I have the .ipa and I have this question: is possible extract a static library file added to this application?
This application contains a static library in format .a, images and the files. I know how to extract the images from the .ipa and I know that is possible get the functions with reverse engineering, but I don't know if is possible extract the library added, because I only see binary files and images then extract .ipa, but I don't see the .a files.

No. The app binary is all of your code and static libraries all combined (linked) into a single binary. There is no way to extract any specific library from the resulting binary.

Related

What is .symbol files in IPA

I've IPA which is uploaded on AppStore. On unzipping IPA I see two folders
Payload and Symbols.
Symbols folder contains many files with extension .symbol
Any idea what would be these symbol files? Can we use them for symbolication?
Yes, it is debug symbols. They contain a mapping between encoded names and locations in your compiled code and the original function names among other debug information. Each <UUID>.symbols file represents either the main binary of you app or a framework that your app is using. You can find out which is which using mdfind (see example).
See this about symbolication

Linking the correct variant of an iOS static library using Xcode

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.

How can one extract a list of supported languages from an iOS .ipa file?

I have a bunch of .ipa files (compiled iOS apps).
I want to extract the list of languages supported by each of them.
I >think< I can do this by finding directories with names like:
Payload/<app_name>.app/<locale>.lproj/
in each .ipa file.
Is that correct?
Is there a better way?

Adding and including LAME static libraries to xcode 5

I need convert M4A files to MP3 and i guess this link is the answer : ios - convert .m4a to .mp3 file programmatically.
I was searching , how use LAME on iOS? and i find this :
https://gist.github.com/Superbil/7689556.
Once i execute, "build_ios.sh" 4 files are generated:
libmp3lame-armv7.a
libmp3lame-armv7s.a
libmp3lame-i686.a
libmp3lame.a
I understand the first two, are the libs that i need , for use this code :
ios - convert .m4a to .mp3 file programmatically.
How i can add this statics libraries to XCode and import for use the code?
I'm using the version 5.1.
Thanks in advance.
When using a static library, you need 2 things:
The static library itself (.a)
Header files to access its public interface
In the list of libraries you've posted, it would seem libmp3lame.a is the one you require. The three listed above it are for individual architectures, whereas the last one is a 'fat library', which is a collection of the individual architecture libraries. You can confirm this by running lipo on the fat library:
lipo -info libmp3lame.a
In order to incorporate it within your application, you need to:
Add the .a and header files to your project (with the application
being the intended target)
Add the library to the "Link binary with libraries" build phase,
found under 'Build Phases' for your target, within the Project
settings
Import/include the header files where you wish to use LAME
Ideally, it's worth having 2 sets of fat libraries; one for the simulator, and the other for the device. You can then include the appropriate one for the respective build target. This ensures the size of the application is the lowest it can be, but it's fairly harmless to include the simulator library within an App Store binary (it doesn't cause side effects).
Your question doesn't mention header files, and I don't see any reference within the build script as part of the build artefacts. You may need to copy the ones you require from the source itself into the project.

Why is a static library 10Mb, but an .ipa using it is only 4Mb?

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).

Resources