Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Generated properties for IBOutlets should be public, to mimic typical patterns used in Objective-C development.
The best example being UITableViewCells, where UIViewControllers and DataSources are usually responsible for populating UITableViewCells IBOutlet properties, not the cell itself.
The reason for this is explained by http://stackoverflow.com/questions/18147688/what-is-the-reason-for-iboutlets-being-private-in-xamarin-ios/18154631?noredirect=1#comment26592866_18154631
In summary: the fact they're properties is an implementation detail, think of them as private fields. You can opt into exposing them via properties, like you do with private fields in C#. If they were all public, you would have no choice whether to expose them or not, breaking encapuslation.
Admittedly, it would be nice if the "create read-only property" context action would operate on [Outlet] properties like it does on fields. Maybe we could add some context actions like that into the iOS addin.
What I've done is to make it such that if a user modifies the *.designer.cs file by hand and adds public, protected, internal, or protected internal access modifiers on an Outlet property, then they should get preserved in future syncs from Xcode.
However, if the accessibility is ever changed to anything other than private, the setter will be updated to be marked as private in the next sync from Xcode (this is mostly for your own safety).
Hopefully that will suffice for now.