On Fri, Jan 23, 2015 at 9:30 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
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.
+1 , better having 2 clean and robust libs , rather than 1 lib full of
hacks.