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...