Using socket.IO-objc in a Swift application

[graouts]

I'm trying to rewrite an Obj-C app in Swift on iOS 8 and added a bridging header to import Socket.IO like so:

#import "SocketIO.h"
#import "SocketIOPacket.h"

When I build the app, I get the following error:

/Users/antoine/<ProjectName>/Pods/Headers/socket.IO/SocketIO.h:64: the current deployment target does not support automated __weak references

I'm not very well versed in compiler settings, so it may be a user error in setting up the project, although this project worked just fine before the move to Swift. Could it be an issue with socket.IO-objc itself?

[ndrewh]

I was able to resolve the error by commenting out SocketIO.h:64 Never mind, that breaks things.

[graouts]

Huh :)

Commenting that line for me at least makes SocketIO build, I'm no ARC expert, but I don't understand what the ivar declaration __weak id<SocketIODelegate> _delegate; brings that the property declaration doesn't already stipulate with @property (nonatomic, weak) id<SocketIODelegate> delegate;

[graouts]

Well, commenting out this line works for me, my app behaviour is unchanged, SocketIO behaves as expected.

[ndrewh]

Yeah I got it to work eventually also with that line commented out. I had my own issues that made me think I broke it. (I forgot to retain my SocketIO object, so I was surprised when I wasn't getting the delegate calls 😄)

Yeah the delegate @property should make a _delegate ivar also, which is why I thought commenting out that line would would work (and it does).

On Jun 11, 2014, at 10:17 AM, Antoine Quint [email protected] wrote:

Well, commenting out this line works for me, my app behaviour is unchanged, SocketIO behaves as expected.

—
Reply to this email directly or view it on GitHub.

[graouts]

I don't think that issue should be closed until the source works as-is. I'll send pull request, and hopefully someone who understands the issue will decide to pull it in or not.

[ndrewh]

While you're at it, try removing all of the other ivars that correspond with an @property. They shouldn't be needed, but I do not know what affect (if any) they have.

[ethanhann]

+1

[aleclarson]

+1

[graouts]

@NerdYouDontKnow I'd rather keep this change minimal for now, I don't feel confident enough to propose a larger change.