Reputation: 113
Our swift bridging header imports AFNetworking, compiles and runs fine; but in the debugger,
po explodes complaining about several areas in AFNetworking that declare dispatch_queue_t properties strong, which is fine in ios >= 6 as long as you don't explicitly define OS_OBJECT_HAVE_OBJC_SUPPORT as 0
error: property with 'retain (or strong)' attribute must be of object type
@property (nonatomic, strong) dispatch_queue_t completionQueue;
^
To confirm my worries, I put #define OS_OBJECT_HAVE_OBJC_SUPPORT 1 in the bridging header:
error: Error in auto-import:
failed to get module 'App' from AST context:
/Users/user/oDevelop/App/App-Bridging-Header.h:7:9: warning: 'OS_OBJECT_HAVE_OBJC_SUPPORT' macro redefined
#define OS_OBJECT_HAVE_OBJC_SUPPORT 1
^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.1.sdk/usr/include/os/object.h:58:9: note: previous definition is here
#define OS_OBJECT_HAVE_OBJC_SUPPORT 0
So why would that be the case? I have twice now verified that our Project and deployment Target are 7.0, and the Pod Project, and EVERY Pod target all have deployment target set to 6.0. I tried manually changing the AFNetworking pod target to 7.0, to of course no effect.
I've also tried on both Simulator (8.1) and device (running 8.0.2).
Upvotes: 1
Views: 418
Reputation: 493
I had the exact same issue and I think I have a potential solution: The bridging does not seem to currently play nice with dispatch objects (applicable to Swift 1.1, Xcode 6.1 and earlier).
As of iOS 6.0, dispatch objects are Objective-C Objects, (see Does ARC support dispatch queues?) so you can therefore change each of these objects from
@property (nonatomic, strong) dispatch_queue_t completionQueue;
into:
@property (nonatomic, strong) id completionQueue;
After doing this for all dispatch objects in AFNetworking, and trying a po in the console, it seems to play nice. I do not know of any potential issues this could cause to AFNetworking though.
Upvotes: 2