Are you installing the internal frameworks themselves via CocoaPods? That was my next step on a previous Swift project and I never got around to it, but it also predates CocoaPods 1.0’s release. My idea was to use the Podfile like so:
pod “InternalFramework”, :path=>’.' This gets the dependencies installed properly using the .podspec file in the local directory, and doesn’t force you to split the framework into a separate repo. Jeff Kelley slauncha...@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/> Check out Developing for Apple Watch, Second Edition <https://pragprog.com/titles/jkwatch2/developing-for-apple-watch-second-edition>, now in print! > On Jun 11, 2016, at 8:24 PM, Jon Shier via swift-users > <swift-users@swift.org> wrote: > > Swift Users: > In preparation for an upcoming iOS app project I’m trying out some new > project layout strategies. One of which is putting my network layer and > custom UI elements in frameworks separate from my main app. I’ve done this > with frameworks in my project, and then used CocoaPods to install the > dependencies for these frameworks (just the Networking framework at the > moment). However, I’m getting the following build error when the app tries to > link: > > Undefined symbols for architecture x86_64: > "generic type metadata pattern for Alamofire.Response", referenced from: > type metadata accessor for > Alamofire.Response<Networking.HTTPBinResponse, Networking.APIError> in > ViewController.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > This occurs despite the Response type being visible to autocomplete in Xcode > and there being no compilation errors at build time. Is there anything I can > do to fix this or is this some sort of Xcode / Swift linker bug or > limitation? It seems like my options are to link Alamofire directly against > by app target or wrap the Response type in something of my own in my > Networking framework. I’d prefer not to have to import Alamofire directly, as > part of hiding all of the network stuff in a single framework was to limit > those sorts of dependencies. > > > > Jon
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
