An .xcworkspace with Cocoa-Pods managing dependencies returns this warning: “Auto property synthesis will not synthesize property selection
; it will be implemented by its superclass, use @dynamic to acknowledge intention” in FBFriendPickerViewController.h; and the same for allowsMultipleSelection
in FBPeoplePickerViewController.h.
Commenting out @property (nonatomic, copy, readwrite) NSArray *selection;
& @property (nonatomic) BOOL allowsMultipleSelection;
did not have any effect on the .xcworkspace at all. Targets build without a problem. The warning is annoying though. It pops up for every build no matter what the target:
What do you recommend to deal with these warnings?
Like the warning suggests, one option is to add @dynamic selection;
to the implementation in FBFriendPickerViewController.m
and @dynamic allowsMultipleSelection;
to the implementation in FBPeoplePickerViewController.m
(you could also use a #pragma directive to silence the warning, or as you suggest, comment out the superfluous declaration entirely).
Of course if you're using CocoaPods then the Facebook SDK is likely not under source control, so your fix would be short-lived unless you add it to source control - but in that case you might be better off upgrading to the new 4.2 SDK instead, which has been split into multiple frameworks. In your podfile replace
Facebook-iOS-SDK (~> 3.23.0)
(or whatever version you have) with
FBSDKCoreKit (~> 4.2)
, FBSDKLoginKit (~> 4.2)
and FBSDKShareKit (~> 4.2)
then run pod update
. There are a lot of API changes, though most of it is just importing the right framework of the three, and changing the 'FB' prefix to 'FBSDK' - but some of the stuff, e.g. the login API has been completely changed (mostly simplified, luckily). See more in the upgrade guide here.
* Update *
An easy solution if you don't want to upgrade the Facebook SDK is to modify your podfile with a line like this:
pod 'Facebook-iOS-SDK', '~> 3.23.0', :inhibit_warnings => true
Then run pod update
- this will suppress all warnings from only that framework. I'm generally not a fan of suppressing warnings, but since this is fairly benign, and an upgrade may be non-trivial depending on your usage, this might be the lesser evil compared to becoming "warning blind" because you just get used to always having warnings (e.g. you don't notice when some less benign issue appears).