I have a simple app which uses whirlyglobe framework (2.2). Otherwise, it is pretty basic program with Apple frameworks.
When I tried to validate the app (and during the distribution, Xcode complains that my app is using private API; specifically it calls "rootElement", and "attributeForFont:". I suspect these functions are part of WhilyGlobe component distribution.
What is the easiest way to remove those files from the framework? Do I need to have the source and compile the framework myself? Or is there a simpler way?
Solved. Here is what I did:
1) Searched in github repository of WhirlyGlobe and found the file that uses the functions which caused issue.
2) I did not need the functionality provided by the file that had the functions.
3) Removed the references (class instantiation) to the file from my project.
That's actually part of the KissXML framework and the implementation is in there. I suspect Apple's test is in error.
In any case, if you're not using the WMS functionality, you can probably drop it out just fine.
Related
I have an application Unity that uses the iOS static library. Then this application Unity is build in XCode. I found several utilities that allow you to obfuscate the library in the application. for example this - PPiOS-Rename.
I carefully read their documentation "Obfuscate Static Libraries", but at the time of building, the iOS static library are already "hidden in the root" of the Unity app, and XCode cannot obfuscate this.
So I need to first obfuscate the library and then add it to the application. or is it not possible?
In my understanding of the documentation PPiOS-Rename stays an external tool, just the files *.plist can be added into the releases, for being able to use the tool on the compiled releases.
I might be completely wrong about it, especially as without iOS I can't test it, but I'd check if my statement is right and if you can omit the step to include the library in your compiled releases.
About handling of *.plist files, follow the instructions on the linked page, I'm not sure if you have one or more in the end. As it doesn't seem relevant to the core of your question, I never verified it deeper.
I'm working on a iOS Framework (using CocoaPods) that, as of today, uses PDFNet.framework as its only dependency.
Everything works as expected when I use the resulting framework in another "top level" project.
Now I'm trying to make this same Framework use the Tools.framework, as I intend to use the annotations from the Tools library.
Is there a common approach in doing so?
I've tried building the Tools source code but it fails as the dependency isn't found.
Everything you need should be in the following guide.
https://blog.pdftron.com/2016/11/14/getting-started-with-pdfnet-for-ios/
If that guide does not help, then please answer my comment above.
I know, there are so many same questions but I didn't get answer for my requirement.
First time I am creating framework. I have created test framework using Raywenderlich example. But my requirement is little bit different. I used so many different frameworks and also used SQLCipher in my project. Now, I want to convert this project into framework. I followed all the steps but the problem is occur when I am trying to build. Getting an error for SQLCypher because I didn’t add to my framework to avoid conflicts. Finally, I have added SQLCypher library to create build without error and it worked but now I am getting linker error when I am using that framework to test in testProject. I didn’t find any example with third parties. Please help me to solve this issue.
I had the same issue.
One solution is to change all method names of other frameworks or libs, but some lib is not open source.
Another solution is work for me which is to use cocoapods. But the user
who wants to use your framework will be forced using cocoapods, depending iOS 8.0 or above, depending the same version of 3rd libs. I have nothing to do with this restriction.
Seems the best way is do not depend 3rd libs in a framework.
Building Modern Frameworks addresses versioning and the importance of getting the API right the first time. Then, it says every app has its own copy of the framework. So then, can't I change my framework carelessly, i.e., without worrying about breaking other apps that are using older versions of my framework?
If we're talking about your own app on iOS, you can do whatever you like. The "framework" is merely a module like any other module; it is included in the app and is simply part of the app's code, so if you revise it, the next update gets the revision and the new code that uses it and there's no problem.
On OS X, however, there's an ability to install a framework into the library where the app will see it. Clearly in that case the code that uses the framework must be careful about versioning. Similarly, even on iOS, if you are using your framework as a way to convey a module to other developers, you must try not to break heedlessly their existing code that uses your framework.
I'm trying to find more information / explanation for the following scenario:
I'm writing a library in Swift and would like to use some open source library in it.
If I just integrate them into my library, is there a chance of namespace collision?
What would happen if the host app will use:
The exact same open source library
The same library but different version
Does using CocoaPods changes something here?
Consider a scenario where I import AFNetworking for example (via CocoaPods) in my library, and the host app will use it too.
Using the same library, you won't have any issues. Using different version will likely cause problems, but that is going to be dependent on the changes made in the different versions.
Namespace collisions in Swift are rare. As #mattt stated, each module acts as a namespace, so naming conflicts with classes or functions from another module won't exist as they do in Objective-C. If you have a naming conflict, the compiler will tell you. In that case, you can just prefix the conflicting signature with the module name.
I would highly recommend you use Cocoapods for dependency management. It handles version control and will make your life much easier.