Years ago, using ObjC and frameworks (and frameworks inside frameworks), it was common from time to time the “duplicate symbols” error. For example, if you created a framework including RestKit and then the app that wanted to use that framework was using RestKit too, you had that error. One way to fix it was to rename the included source code into your framework using a prefix. Or just avoid using 3rd party dependencies on your framework. Note we used to use static libraries, rather than dynamic libraries.
Is it possible to have the same problem with pure swift apps/frameworks and dynamic libraries today? As far as I understand, swift uses the concept of module for namespaces, something we didn’t have with ObjC.
I mean, is it possible to create a framework that uses Alamofire (let’s say version 5), and then create an app that uses Alamofire (let’s say version 5.0.1) AND your framework that uses Alamofire too?
I am using a similar setup and i did not face any such duplicate symbols in my project.
Let me share my experience.
I have a project setup like the one below.
Main Project -> uses PromiseKit via Cocoapods
My Framework -> uses PromiseKit via Cocoapods
Main Project uses My Framework
I did not face any such issue while running this setup. IMO, hope it is taken care by Swift compiler.
I have 2 frameworks created by me that use (both of them) a library also created by me.
The first framework initialize the library and makes all its workflow. After finishing the first framework, the second one must start.
But when the second one is going to start, after initializing the library, the app using both frameworks crashes with a exc_bad_access error.
Apparently the library is created correctly, but if i comment the line of code to initialize the library in the second framework, the workflow continues (it crashes later because it has no library initialization).
Is there anything I'm doing wrong? Should I use two separate libraries instead?
EDIT:
Imagine the situation:
Framework A has this methods: start, stop. And while it works it delegate to the methods: infoFromA,frameworkAFinished.
Framework B has this methods: start, stop. And while it works it delegate to the methods: infoFromB,frameworkBFinished.
Both start methods initialize the static library mentioned (lets call it problematicLibrary).
Both frameworks present some views to make its functionality. So lets make an example of the app workflow.
At the app view viewWillAppear method, I start the Framework A just using:
[FrameworkA start]; , this will initialize the library and present a view. With this view (using my problematicLibrary) some info will be delegated to the infoFromA delegated method. And after all the info is delegated, it will delegate to frameworkAFinished.
When the FrameworkA has delegated to the frameworkAFinished I start the next Framework: [FrameworkB start]. As the other Framework, it will initialize the library and present a view. While debugging, all the initialization of the library is done (create the instances of the needed objects and a new instance of the library is created) and while its presenting the view it goes through the viewDidLoad method and then it throws an exc_bad_access error at the problematicLibrary initialization line (which has been done before and continued to present the view!!) without going into any other method from the view.
I have checked if the initialization is doing well, and all the variables were at null value before the initialization, and a new memory address is given to the library object.
This sounds strongly like a symbol conflict to me. I'm just surprised the linker didn't catch it, but I assume that's because you're using a static library in both your frameworks instead of simply yet another framework.
Generally speaking, I'd warn that "this is a bad idea™". What you're trying to introduce into your design is basically dependency management. Like a lot of blog articles and specifically this SO answer suggest, you should avoid packaging frameworks (and by extension libraries) into frameworks.
What most likely happens in your scenario is this (I admit I'm guessing a bit here): You linked the library into Framework A. Thus, the library becomes a fixed part of it. Its symbols are in it, even if you did not expose them to the app in any header files or the like. As long as you use only that, everything works smoothly. Then comes Framework B, of which the library is also a fixed part. Even though you can't see it from your app, the very same symbols are inside it. This, however, clashes with the symbols that were already loaded by Framework A, hence a crash (as said, this would usually be caught by the linker, but I guess you "tricked" it by building the frameworks beforehand and packaged the library in them). Maybe somebody else can explain this in more detail, but that quickly becomes besides the point as to how you would go for a solution. From how I see it, it just won't work this way.
So here's a suggestion for how you can solve your problem:
If you really, really need to split like this (two frameworks used in your app using the same dependency), I'd suggest removing the library from the frameworks (i.e. make them depend on it, but not package the actual .a file in them) and documenting that properly. Then add the library to your app project, just like you added the frameworks.
If you want to make this fancy and easily installable into other apps, I'd recommend setting up a private CocoaPods repository and turn your frameworks into private pods. You can then easily define the library (or rather "new Framework C") as a dependency for Framework A and Framework B. When you then pod install in your app, cocoapods figures out the dependency and adds Framework C automatically to your project. This scenario is exactly what cocoapods (or any dependency manager for that matter) was designed for. It automates and helps in the project setup, so that the final build (the app) doesn't have to figure out dynamically what it can and can't use. The end result is the same.
Trying to duplicate that "in code" quickly becomes messy. Frameworks trying to figure out things of the surrounding app/project that uses them (like "is my dependency so-and-so already linked? if not, can I load my own version of the library?") can lead to a lot of pain.
Okay, in response to your comment I'll try my hand at a more detailed How-To for the non-cocoapods setup. As a preface, though, let me say that that's kinda hard to do on top of my head, as I have no ready sample project to toy around with. Since this is one of those "set it up once and then forget aout it for a long time" I have to admit my recollection of these things is a bit fuzzy, so consider this as a sort of "rough direction". There might be things you need to configure differently than how I recall them. Other SO user are thus hereby invited to edit and correct my answer here, too. :)
First, I have to say I am not exactly sure whether you need to convert your static library into a framework or not for this, I think you don't so I'll go from here (I have never used a static library in that way).
That means you can leave the project that builds your library as is. On second thought, you probably have to do this to be able to link against the library without making it a part of the framework that uses it. I will still refer to this code as "library" in the below points, but assume that you're able to turn it into a dynamic framework as well.
The projects building Framework A and Framework B should be changed. I don't know how you have this set up (as one project with various targets, whether you have a "development application" as part of it to test the frameworks on themselves, etc.), but the important thing is that in the target that builds a framework, the library should be linked (i.e. in the "Link Binary With Libraries" build phase), but not copied (i.e. it must not be in the "Copy Bundle Ressources" build phase). It might be tricky to set up any development/test target you use to run, depending on how you did that so far. For example you might have to manually edit Library Search paths in your build settings to be able to properly compile the framework.
Lastly, you need to change your final app's project settings, obviously. The library that was originally part of Framework A and B now needs to be linked to from its project directly, and, obviously, it needs to be copied into the bundle as well. Note that any projects that include either of your frameworks (A or B or both) in the future must do so, otherwise they won't work, because these frameworks expect the library to be present (but no longer "bring it with them").
In spite of this long-ish text wall, it shouldn't be that complicated, I think, but you may still want to check out how cocoapods can support you with something like this, perhaps it's helpful in the future. The linked article expects basic knowledge on how to use a pod and write one, but the other guides on the site explain that pretty well. I am just saying this because in the end, when using cocoapods in a project to add multiple libraries/frameworks that introduce dependencies, it basically sets up your project in the way I described above. It uses some fancy shell scripts that ensure everything is copied to the correct folders and such, but overall speaking that's how it works: A pod's podspec tells cocoapods what additional pods to include in your app for it to work (a dependecy the pod expects to be there, but doesn't "bring in" by itself).
Check if they are both compiling for the same target.
Check if they have access to the same target membership.
Check build phases to see that they are both there.
I think because the first library is not 'well' referencing the second one.
Also i think that you can't import a framework inside another one.
To make things easier, you can merge the two frameworks on a single one.
Also you can add a callback (using protocols or closures) that informs for the end of the first workflow, and you use this callback to initialize the second framework. This way the initialization will not be made automatically.
I have a big library on iOS which is using a lot of other libraries.
It started well, but after a while I realised that sometimes I only need part of it for my project. And since the whole thing is pretty big I would like to make a sub-library that is only the selected classes + selected embeded libraries that I'd chose for a particular project.
For example:
My project has files a.m to z.m, and they all use independently libraries a.a to z.a
And I would like to compile b,c,j and r classes/lib to make my library.
I started reading about cocoa pods which should help, but I thought there would be other solutions. Is that possible and easy to do in another way?
I would like to integrate an existing Xcode project A into another project B so the second one could reuse some features.
Project A :
quite complex, manage authenfication + session, a lot of dependencies betweens classes (notably UIViewController)
relies on a dozen of Cocoapods dependencies
the project lives on its own : it's a sale channel/ticket shop that is already deployed on the store as it
constant evolution
Project B :
Project customer side that would love to integrate some parts of the sale channel
Complexity might be very variable (using Cocoapods or not, etc)
Basically we can either deliver and package the e-commerce shop for one of our customer if he does not already have an iOS application, or we have to integrate it in their existing one.
Expectation :
ideally we could pursue the evolution and iteration on the core Project A without having a lot of work to make it available for integration (it would be more cost efficient for us to work on a single project than on the core one and separate SDK/Library made from scratch)
we want to make it easy to integrate for the customer on its own
The approach we have been thinking to are :
build a .a library file. But it does not seem really practical considering the size of the project
dropping the .xcodeproj from A into B (à la ZXing), but it was a pain because of Cocoapods dependencies
Simply adding all the classes from A into B (with a proper packaging into folders first), manage Cocoapods for B (add dependencies from A if Cocopoads already used or set it up), and make all imports easier by editing .pch accordingly.
What would be your suggestion ?
Since you are already using cocoapods I would try to do a private pod(s) with the shared characteristics. That way you can easily track versions across projects and use the same tool to manage all the dependencies.
This approach also would make easier for the customer to integrate as he will see the shared code from the pod as long he has access to the repository but not the complete main project.
We have a fairly rich e-learning app, built mostly using cocos2d. Currently we are in alpha and want to setup our project structure so we can also build a Mac version to target the Mac App store. It is about 80% cocos2d with some intitial screens in UIKit which will have to be ported to Mac (re-written).
What is the recommended setup for targeting both the Mac and iOS app stores from a single code base? I assume the choices are:
Create 2 xCode projects in the same application source code root folder and use each project to build a single target. This would be: Project.xcodeproj and ProjectMac.xcodeproj
Add a new Mac target to our existing iPad application project and then fiddle with target membership to get the desired results. This would be just: Project.xcodeproj
Further complicating the situation is that we currently use cocos2d as a static library for the iOS app. We also have a library called CoreInfrastructure that has a lot of code we use across all our projects. Recently I have figured out that I can create a project to simultaneously build a framework targeting Mac and a library targeting iOS from the same code base. This is done by starting with a framework project and adding a target to build a static lib for iOS.
So just wanted to get everyone's opinion and insight. Anyone know of any caveats to watch out for in the above choices? Anyone who is building for Mac and iOS app stores simultaneously care to share their structure? Adding a target worked on our library code ... is that the way to go for the application as well?
Are there any issues doing archive and distribution builds for either choice?
Thanks in advance.
WWDC session "Sharing code between iOS and OS X" answers all the basic questions in this topic. iWork team presented how they have got away with creating Pages, Keynote and Numbers with shared code base for both iOS and OS X.
The key for their project was using:
separate Xcode targets for iOS and OS X
separate project for the shared code in a form of a .framework
target dependency on the framework from the point above
I encourage to watch the video or read the transcript from this session:
WWDC 2014 Sharing code between iOS and OS X
ASCIIWWDC transcript
I recently used kstenerud's iOS Universal Framework to build a shared framework codebase that works for both iOS and Mac apps. I just needed to manually add a target for a Cocoa framework after I had created a project for an iOS framework. That way I can develop the sharable code once in the framework and link it in both the iOS and Mac apps. You can even make the framework contain UIKit-specific code for your iOS app and AppKit-specific code for your Mac apps. I wrote about it in my blog if you are interested.
For the applications use two separate projects. Using multiple targets for iOS and Mac in one project is very useful if they are sharing a library or framework. However, in your top level application almost nothing is shared. The UIKit code will need to be totally rewritten to use AppKit, the dependencies will be different, and even most of the project settings will vary.
Of course if you really want to see everything at once you can put both platform specific application projects and all the shared dependent library/framework projects in a single workspace. This is more a question of work style. If you want to switch back and forth between the two frequently this makes the most sense. If you want to simplify what you are looking at you can put them in separate workspaces that share many of the same projects. Separate workspaces has the disadvantage that a project can only be open in one workspace at a time so you effectively can only work on one at a time.
I just use multi-platform static library targets for the shared sources. You will need to expand that to the dependencies, however. If you have platform dependent implementations, you may want to create supplemental export libraries for those symbols.
So your structure might take this form:
CoreInfrastructure - cross platform static library.
PlatShared - cross platform static library.
PlatSpecific-OS X - OS X static library (or framework).
PlatSpecific-iOS - iOS static library.
The OS X app links to CoreInfrastructure, PlatShared, PlatSpecific-OSX, Cocos for OS X, and system libs.
The iOS app links to CoreInfrastructure, PlatShared, PlatSpecific-iOS, Cocos for iOS, and sys libs.
Problem (I've found) is, there are a lot of people who have not had much/any experience developing and maintaining complex project structures in Xcode. It's a pain (IMO) to setup duplicate targets, and properly maintain them as they grow -- even when they all refer to the same source files. That's why i prefer minimal targets and proper dependency structure.