I'm trying to run an IOS app created by another dev that is using a cocoapod from a private repository I have no access to. I managed to extract the .framework bundle from the IPA and add it to the xcode project but it is not being recognized (I get "No such module").
Is it possible to do what I'm trying to achieve?
So far, what I've tried:
build it in release as I guess the framework in the IPA is in release
add the .framework as embedded binary
add the .framework as Linked Framework and Libraries
copy the .framework to ~/System/Library/Framework
update the Frameworks Search Path including $(SRCROOT), recursive, hardcoded paths, etc.
change the .framework location to "Relative to Build Products"
Thanks!
It wasn't that much easy to get the frameworks used in project from ipa file.
Whenver the application runs for first time, also when you archive your application, all the linked .frameworks will get converted to .dylib that is dynamic libraries.
What is static library - a unit of code linked at compile time, which does not change.
What is dynamic library - a unit of code and/or assets linked at runtime that may change.
Framework - A framework is a hierarchical directory that encapsulates a dynamic library, header files, and resources, such as storyboards, image files, and localized strings, into a single package. Apps using frameworks need to embed the framework in the app's bundle.
Dynamic Library
A dynamic lib file is just resides inside the framework folder.
Following is a description from apple documentation
Dynamic libraries outside
of a framework bundle, which typically have the file extension .dylib,
are not supported on iOS, watchOS, or tvOS, except for the system
Swift libraries provided by Xcode.
Ref: Documentation
So you cannot simply copy a .dylib to xcode bundle and just use it. There is some sort of security too.
Another approch
It is possible to decompile the source code from .ipa files. You will get idea from below links.
SO Question regarding decompiling of ipa file
Decompilation Possibility
It seems that when an app is archived for distribution, the Headers and Modules folders are removed from the .framework bundle.
The Header folder contains the .h headers for Objective-C and the Modules folder contains the .swiftmodule equivalent files for Swift.
Without these files you have no public API to consume for the framework binary, so unfortunately this renders the frameworks unusable without reverse engineering.
Related
I've been developing a Cocoa app that uses both the libav* and ImageMagick C libraries but am having issues actually distributing the app. I have linked to the various static libraries in Xcode like so:
The app builds and runs perfectly fine on my machine. Now I am trying to run it on a different computer. I archived the build, and exported it as a macOS app in Xcode, which leaves me with the .app archive. Now, when I try to run it on a different mac, I get the following error:
If I run otool -L binary_name on the built binary, I get a .dylib for every single one of the included .a files. I thought the whole point of a static library was that it gets built into main binary, and that there is then no need to do any dynamic linking. Why is it still trying to load the dylib?
I managed to resolve this issue, and believe it was due to the technical note listed here: Using static versions of existing dynamic libraries. Since the dependencies I am using were installed via homebrew, the lib folders of each dependency had both the .a and .dylib files, and Xcode was linking using the dylibs. To fix it, I copied all the .a files that I needed to a separate folder and adjusted my Library Search Paths in Xcode to point to the new folder. The app now builds and links to the static libraries as it should.
I'm using Alamofire in a Swift project, and part of their manual installation instructions are to add Alamofire under Embedded Binaries in the General tab for my application target.
What are Embedded Binaries?
Embedded binaries are binary files that are copied to your application bundle when you build the project. Use embedded binaries when your application relies on third-party frameworks so people can use your application without needing those frameworks installed on their machine. Embedded binaries keep users from having to manually install third-party frameworks. Your application uses the framework you embedded.
In your Alamofire example your application relies on Alamofire. If you didn't embed the Alamofire framework, nobody would be able to use your application unless they installed Alamofire manually. By embedding Alamofire with your application everyone can run your application.
"Binary" means: compiled code — as opposed to "source code", which is what you are working with when you write code as text.
They could have given you source code and let you compile it, but they didn't; they are keeping the source code secret, so they've given it all to you after compilation, so that you can't read it.
"Embedded" means: to be included inside your app bundle, by copying them into it at build time.
So, they are handing you some compiled code (frameworks) and telling you how to include them inside your app bundle. These frameworks, unlike Cocoa's frameworks, do not already exist on the device, so if you don't include them inside the app, they won't be present and your app would be unable to call into them.
Contrast this to Cocoa's frameworks. They, too, are compiled code. But they do already exist on the device. Therefore they are not embedded inside your app; they are merely linked (and, if they appeared, would appear in the next group, Linked Frameworks and Libraries).
Embedding binaries copies the entire framework to the target.
A framework is a hierarchical directory that encapsulates a dynamic
library, header files, and resources, such as storyboards, image
files, and localized strings, into a single package. Apps using
frameworks need to embed the framework in the app's bundle.
So, when you embed a framework in your app, it increases the size of your app because it is copied to you app bundle. In most of the scenarios we will be using this sections when we are using third party framework.
When we add a framework to Embedded Binaries it automatically adds that framework to Linked Frameworks and Libraries also.
Refer to apple documentation for more details: https://developer.apple.com/library/archive/technotes/tn2435/_index.html
I'm developing a plugin for mac. I'm trying to use afnetworking and other frameworks which needs arc. I'm trying to create a .a(library) for the framework and access it in firebreath. I tried adding the directory which contains .a using include_directories in projectdef.cmake then linking it in target_link_libraries. Please lemme know how to add this and whether the framework can be used in firebreath without any pitfalls
I have used external libraries in firebreath. Though I have used editors to link the libraries. You need to specify .h files for the function prototypes, along with .a files which will dynamically link to .dylib
Try adding these via Xcode and see if that works.
I am realtivly new to the concept of dynamic loading and shared libraries. While I fully understand how dlopen() could be used to reference symbols in a shared library I have yet to fullt grasp what MacOS does behind the scenes when I don't statically link against something. When adding a framework to Xcode I have the option to load it into my project or I can just provide some form of symlink to it(the actual implementation is obfuscated be the easy to use interface).
There after all I seem to need to do is import the header files that porvide and API to these frameworks and I can just invoke their symbols free of hassle. Can someone explain to me what I am actually doing, because it make no sense to me.
The sheet you're referring to has nothing to do with the actual linking of the framework. The copy vs. link choice refers to how you want to include the framework in your Xcode project, not your app binary.
For system frameworks there really isn't anything you need to do but import the headers.
For custom frameworks (your own or third-party) the framework must reside at the load path directory when your app launches. Typically the load path will point to your app bundle's Frameworks (sub)directory, so you must add a Copy Files build phase that copies the framework to your app bundle's Frameworks directory.
Remember to check out Apple's Framework Programming Guide, especially the section on frameworks embedded in your app bundle.
I want to share my Xcode project as a static library for other people to use in the xcode emulator (giving them as little raw source code as possible). How do you use an AppDelegate from a .a library file in Xcode or UIBuilder?
I copied the main Window.xib file to a new project and included all of the other source files in a static .a library that I thought I would be able to invoke somehow. What do I have to do to launch my main product that is compiled into the .a library from a brand new Xcode project that is including that library?
You'll have to link to the static library. Include it in your new Xcode project, and then in the target for the application, go to the General tab and set the library as linked. You'll probably want to copy it into your new project's bundle (in the Frameworks directory), using a Copy Files build phase. You'll also need to reference the header files for the static library for avoid warnings.
This is a much better solution found in someone else's question:
iOS Question. Can I distribute the Xcode simulator versions of my app?