I have an app (let’s call it MyApp) written in Swift with the following targets :
MyApp: the main target
MyAppKit: a target building a framework for code that is shared between the app and its extension(s), mainly the API backend and database handling
MyAppWidget: a Today View Widget (or whatever it’s called now) which uses the
MyAppKit framework is linked into each target that uses it, namely
MyAppWidget. Enter Cocoapods : I used to have the following Podfile structure :
platform :ios, '8.0' use_frameworks! target 'MyApp' do # Mostly UI or convenience pods pod 'Eureka', '~> 2.0.0-beta' pod 'PKHUD', '~> 4.0' pod '1PasswordExtension', '~> 1.8' end target 'MyAppKit' do # Backend pods for networking, storage, etc. pod 'Alamofire', '~> 4.0' pod 'Fuzi', '~> 1.0' pod 'KeychainAccess', '~> 3.0' pod 'RealmSwift', '~> 2.0' pod 'Result', '~> 3.0' end target 'MyAppWidget' do # Added here event though the target only imports MyAppKit but it worked pod 'RealmSwift', '~> 2.0' end
The aim here was to expose only the
MyAppKit framework to the other parts and not all its pods (e.g. I don’t want to be able to
import Alamofire inside the main app). However, starting with the Cocoapods 1.2.0 RCs,
pod install failed with the following error :
[!] The 'Pods-MyApp' target has frameworks with conflicting names: realm and realmswift.. It used to work because the pods were declared for the extension but only embedded in the host app (see this issue for more info). So I removed the pods from the widget’s target, leaving me with just a blank
target 'MyAppWidget' line.
With this configuration,
pod install runs fine but compiling fails at the linking stage for the
MyAppWidget target :
ld: framework not found Realm for architecture x86_64. This can be fixed by explicitly adding both
RealmSwift.framework to the “Link Binary With Libraries” section and the following build setting in the target’s
FRAMEWORK_SEARCH_PATHS = $(inherited) "$PODS_CONFIGURATION_BUILD_DIR/Realm" "$PODS_CONFIGURATION_BUILD_DIR/RealmSwift"`
However, whenever I run
pod install, the build settings are naturally reverted and I have to add the build settings again.
I see the following solutions :
- Add a
post_installhook adding these settings each time but it does seem “hacky” and after a few misguided tries, I have found no API reference and don’t know how to add these settings to the
MyAppWidgettarget through script.
Change the Podfile to the following structure (or even wrapping it in an abstract target) :
[...] target 'MyAppKit' do # Backend pods for networking, storage, etc. pod 'Alamofire', '~> 4.0' pod 'Fuzi', '~> 1.0' pod 'KeychainAccess', '~> 3.0' pod 'RealmSwift', '~> 2.0' pod 'Result', '~> 3.0' target 'MyAppWidget' do inherit! :search_paths # Because else we get the "conflicting names" error end end
Which seems logical to me in the sense of “the widget should know where to look during linking but doesn’t need the pods per se”
but this doesn’t add the aforementioned build settings (I probably misunderstand the(edit: it actually works, but not with an abstract target). This idea came to me because in older versions of CocoaPods, the solution was apparently to add
link_with, which is now deprecated.
- Expose Realm also in the
MyApptarget, however this conflicts with my goal of not having access to “backend” code in the main code (it might be purely esthetic?).
So, here’s my question : what’s the best way to integrate pods in a framework shared between the main app and the extension while still being able to compile, without tweaking around and manually adding stuff?
Cheers and thanks in advance!
Following Prientus’ comment I’ve explored the possibilities of abstraction and inheritance. The underlying issues I’ve now uncovered are actually manifold :
- It used to work before Cocoapods 1.2.0 because pods declared under the widget’s target were embedded inside the host app yet still linked to the widget. No it simply refuses to have pods with the same name for different targets in a “main vs extension” relationship
- Using abstract targets is insufficient because targets can’t inherit only the search paths (
inherit! :search_paths) from an abstract target.
- Search paths can be inherited from a real target like
MyAppKit, but this exposes all these pods to
MyApp‘s code (which I want to avoid), and there still is the issue of linking the Realm framework (because actually the widget uses the tiniest bit of a getter and therefore needs it).
Using this last option and manually linking Realm.framework works but is suboptimal regarding my intents and what used to work. Some of these issues seem to be a bug according to various issues on Cocoapods’ GitHub. I’ve added my own issue and will update when I have news.
So, what gives :
- My concern of “separating pods between targets” is absurd because you can still import them anywhere.
- The “you have to manually link” issue is fixed by an easy
The fixed and working Podfile therefore is :
platform :ios, '8.0' use_frameworks! target 'MyApp' do pod 'Eureka', '~> 2.0.0-beta' pod 'PKHUD', '~> 4.0' pod '1PasswordExtension', '~> 1.8' end target 'MyAppKit' do pod 'Fuzi', '~> 1.0' pod 'RealmSwift', '~> 2.0' pod 'Alamofire', '~> 4.0' pod 'KeychainAccess', '~> 3.0' pod 'Result', '~> 3.0' target 'MyAppWidget' do inherit! :search_paths end end
And that’s it. I would say that the old behaviour was more obvious and didn’t require reading up on “podfile target inheritance”. I did learn a lot though. Cheers!
I don’t know you. But for me, it’s totally legit and reasonable to have the extension and the host app contain all the pods that a framework defines. And this is what i mean:
def shared_pods pod 'Alamofire' end target 'Framework' do shared_pods end target 'Host' do shared_pods // Some other pods end target 'Extension' do shared_pods end
I know you are worried about but if you think about it, all those 3rd party frameworks you use, they all have dependencies. You don’t have to worries about them because Cocoapods takes care of them for you. If you want to utilise that, then you’ll need to put a local pod entry in the list.
target 'Host' do pod Framework, :path => '../Framework' end
But then you have to maintain the
This is a swift-3.0 project’s profile example.
platform :ios, '8.0' def import_public_pods pod 'SwiftyJSON' end target 'Demo' do use_frameworks! # Pods for Demo import_public_pods pod 'Fabric' pod 'Crashlytics' target 'DemoTests' do inherit! :search_paths # Pods for testing end target 'DemoUITests' do inherit! :search_paths # Pods for testing end end target 'DemoKit' do use_frameworks! # Pods for DemoKit import_public_pods pod 'RealmSwift' target 'DemoKitTests' do inherit! :search_paths # Pods for testing end end