[aerogear-dev] Swift to Objective-C interop: one aspect of iOS7 Swift support

[Corinne Krych]

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/UnifiedGeo%2FUnifiedGeo%2FAGClientDeviceInformation.swift#L46
[2] http://stackoverflow.com/questions/26366082/cannot-access-property-of-swift-type-from-objective-c
[3] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Parallel-support-for-a-Cocoapods-Swift-Obj-c-library-td10632.html
[4] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Swift-Frameworks-Static-libs-and-Cocoapods-tc8456.html