I have a iOS library that I created. Quite now I shipped this lib in a .framework file with only some .h files.
Now I would like to use Cocoapods instead of the framework.
Is it possible to hide the .m files and expose only some header files (like with the framework)?
According to this question I don't understand the relation between the podspec settings source_files and public_header_files.
I assumed that public_header_files would be my needed option, but I don't understand what this property is doing.
Edit:
I think I misunderstood the design of Cocoapods. public_header_files seems to make sense when using the use_framework! setting.
Maybe I'm trying Carthage instead.
For the Objective-C static framework, it is possible, you can try cocoapods-packager.
For Swift framework, so far it is impossible to use cocoapods-packager because of no volunteers. You can find the detailed information here:
But there is another way to Hide implementation of Swift framework when distributing it
Related
I converted my entire Objective-C framework to Swift. After building it, when I check the framework's Header files, it is still displaying the old Objective-c functions.
I deleted all the Objective-C files from the framework project. I have tried cleaning and building the project. But with no success.
You deleted the Objective-C files from the Xcode project, but did you also remove them from the file system and any source control you might be using?
Also, your Build Settings in your Xcode project can be searching for library/header files even after you've removed them from explicit inclusion in the Project Navigator in Xcode.
Just make sure the search paths don't look for old Obj-C stuff. Be careful of recursive searches like MyXcodeProject/**. The ** will recursively search all subfolders and their subfolders for things to include.
Better to specify folders directly in the search paths if you can. If you know you don't need search paths, you can just clear them all.
...although, you may want to leave the default exclusions in place:
Remember that you can't subclass a Swift class in Objective-C.
Therefore, the class you migrate can't have any Objective-C
subclasses.
Once you migrate a class to Swift, you must remove the corresponding
.m file from the target before building to avoid a duplicate symbol
error.
To make a Swift class available in Objective-C, make it a descendant
of an Objective-C class.
Command-click a Swift class name to see its generated header.
Option-click a symbol to see implicit information about it, like its
type, attributes, and documentation comments.
from: https://developer.apple.com/documentation/swift/migrating_your_objective-c_code_to_swift
Also, delete your DerivedData, do a clean build and restart the xCode.
How can you see "Header" files in Swift based framework even after removing Obj C files. Definitely there's the build issue. If build is proper, then you are not referring/using to the right framework (in the app) after building it. This is most common mistake that I observed with many developers.
Maybe this can help, try it on your framework's Target Build Settings:
Disable modules (Enable modules (C and Objective-C))
Make sure the Swift version is set (Swift Language Version)
I'm about to create a cocoaPod for a small iOS Framework for our customer. I have 2 questions about it.
1) I'm depending on another framework that is also available via cocoaPod. Could it happen that the original author removes the lib and therefor could kill my framework as well or is this secured?
2) I'm using Swift as the language of choice? Let's say one is importing an Obj-C Pod into a Swift project, he needs a bridging header. With the other way around, using a swift cocoapod with obj-c, does the user need to do anything to make this run?
Thanks
Yes, and hopefully the dependent framework doesn't remove his framework (its very rare they do it)
The bridging header is fine unless you use advanced generics (inheritance of a base generic class) as methods might not be available while converting to Objective-C.
I'm build a Framework for iOS and my framework has AFNetworking as dependency.
So what is the best practice to include AFNetworing? Reading other posts (specially this question here) i came up with three options:
Copy all the .h.m files from AFNetworing in to my project and compile my framework with it. But according to this, it will possible cause a situation where some third part developer using my Framework are already using AFNetworking and will get a compile-time error that some class is declared twice.
Use CocoaPods and link AFNetworking to my Framework. This is causing this error: -lPods is not an object file (not allowed in a library).
Build something like the Aeris SDK where the third part developer using my Framework will be responsibly to add AFNetworking to their project.
I think that option 3 is the best but i don't know how to do that. How can i dev my framework calling AFNetworking classes/methods but do not include on the final framework product?
Thanks!
That's a very bad practice to use third party library in you library.
Ideally you should avoid doing that.
But if you really need it, you can define and add prefixes to class names.
Refer this article Avoiding dependency collisions in iOS static library managed by CocoaPods
Ok. I decided to go with the option 3.
A just added all the header files from any third-party lib to the my framework project (you can also add the .m files but not include them on the static library target).
And a i also documented everything, so developers using my framework will know what are the dependencies and how to include/install them on their own projects (including third-party lib versions, CocoaPods support, etc).
I decided not to go with option 1 because that will cause some situations where a project will have two copies of the same lib compiled on the final app. Even if a change the namespace for the libs on my framework code (to prevent "duplicated symbols" errors) that will still cause some other possible problems like an APP with larger size, possible bugs related to two or more instances of the same lib running together, etc...
Short version of the question:
So basically what I'm looking to do is to take an existing library written in C (https://github.com/lsalzman/enet) and turn it into a static library for iOS.
I am just looking for an easy to understand step by step of how to accomplish this in Xcode.
Long version:
I've gone over some tutorials for making a simple static library that's written in Objective-C (http://www.raywenderlich.com/41377/creating-a-static-library-in-ios-tutorial), and I generally understand what is happening there, but I'm failing to understand how to do this with existing code written in C.
I think I'm getting close, but I'm not so sure.
I start out by making a "Cocoa Touch Static Library" project in xcode.
I add all of the enet .h and .c files
make sure the enet stuff is in my "User Header Search Paths" in build settings.
hit build - it compiles!
The generated .a file is 517kb, so I'm pretty sure it's building the enet stuff in at this point.
My problem right now though is that the header file for the library is basically empty:
#import <Foundation/Foundation.h>
#interface enet_ios : NSObject
#end
I'm thinking I either need to write a wrapper in Objective-C that talks to the enet library, or I need to reconfigure my xcode project somehow so that enet.h is the 'entry point' into this library and not xcode's pre-generated .h/.m files. I'm not really sure how to do that, though. Ideally I'd just like to skip any sort of wrapper and use what the enet library is already providing me.
Thanks for taking a look!
Question, are you trying to call the functions using objective c syntax / object orient notation? Then you do need a wrapper object, no way around that.
But if you are fine calling C functions directly, which is completely acceptable in IOS/Objective C, then it is a matter of making sure your header files from the enet library (the ones in the include directory I see in the github link you shared) are also distributed with the static library. This is a limitation of the static library. You can copy them with the *.a, but they must be copied with the static library. This does differ from a Framework, which has included .H and assets, which developers are not easily able to create with Apple's tools for IOS.
I find that library management with Objective C to be painful on its own and static libraries a challenge for this and many other reasons. One more suggestion, definitely more elegant and portable but slightly overkill for personal use, would be building the project as a cocoapod. You can do this by forking the project and converting it to cocopods. There are lots of examples of how the project structure should look on cocopods and other OSS like AFNetworking. This seems to be the defacto standard way people are creating IOS libraries. See http://cocoapods.org/ for more details. This will include the source code as the pod and compiled against the target application.
This is the only way i deal with my own libraries and third party libraries. It has gotten to the point that if the library doesn't use cocoapods, i don't use the library or fork it and do make it a pod myself....
I have created a static library in iOS where I have certain common functionality for my projects. I used the instructions for the iOS Universal Framework and everything works great.
I have a module in the static library that requires AFNetworking. So I installed the cocoapods, and included it in my static library
However, when I include my static library into another project that also needs AFNetworking, and I run the project, I get a duplicate symbol error for all the common classes.
What is the best approach to avoid a conflict like this?
The best approach is not to include any 3rd-party libraries / frameworks inside your framework.
Here's Apple reference regarding "How to build your own framework". There are a lot of guidelines that will help to build a good framework that will not cause any errors if you'll link it to any project.
AFNetworking is a framework that is application specific, so you should not include it into your framework. You may weakly link your framework to AFNetworking, but you should avoid strongly linking it.
Here's resource regarding weak linking.
For example, if you are using 3rd-party library, you should specify that your framework require user to add dependencies in order to use it.
Here's an example how AFNetworking does it.
Also, check this framework, and it's requirements regarding dependencies in its specification.
The best way to do this (in my opinion) is to underscore the class names to keep them unique.
So let's say your library is called XYLibrary. It will have a bunch of AFNetworking files like AFNetworking.h and AFNetworking.m. Rename those to XY_AFNetworking.h and XY_AFNetworking.m. This should hopefully keep them unique from other instances of that library in another project.
You should do this for any other 3rd party libraries as well.