Hello all, Yesterday I was discussing with Sebi about @objc and how you make a Swift class available in Objective-C Sebi has one issue, in its Swift protocol he wants to declare longitude/latitude Double and make them optional [1]. Because his protocol is swift only (not inheriting a Obj-c one) he uses @objc and this is when, compiler complains with “Property cannot be marked @objc because its type cannot be represented in Objective-C”. This issue is well-explain in this stack overflow thread [2] One work-around (the one used by Sebi) is to use NSNumber and make then optional. To echo that issue, yesterday Christos on this thread [3] gave the example of QueryKit which uses pod subspec coupled with some Objective-C re-write classes (seen as temporary) to bridge the gap Swift to Objective-C fro a Swift first library. As we’re talking about iOS7 support for our Swift libs there are 2 aspect of it: - support from obj-c code is one aspect - dynamic fwk support as expained in this thread [4] is another one… All in one, it makes me wonder if it’s worth it… all those hacks in Swift code. Maybe the option we used for ios-push lib i.e.: having obj-c and swift version of the lib would be a better approach. ++ Corinne [1] https://github.com/sebastienblanc/helloworld-geo-ios/blob/master/UnifiedG... [2] http://stackoverflow.com/questions/26366082/cannot-access-property-of-swi... [3] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Parallel-support-f... [4] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Swift-Frameworks-S...