[swift-users] Generic type metadata pattern not found?

Jeff Kelley slaunchaman at gmail.com
Sat Jun 11 21:36:43 CDT 2016


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

SlaunchaMan at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160611/adb5af2f/attachment.html>


More information about the swift-users mailing list