Question

In non-ARC code retained properties handily take care of memory management for you using the self.property = syntax, so we were taught to use them for practically everything.

But now with ARC this memory management is no longer an issue, so does the reason for using properties evaporate? is there still any good reason (obviously other than providing public access to instance variables) to use properties anymore?

Answer 1

But now with ARC this memory management is no longer an issue, so does
the reason for using properties evaporate? is there still any good
reason (obviously other than providing public access to instance
variables) to use properties anymore?

Yes — by using @property and @synthesized getters/setters, you guarantee that:

• your getter/setter can be subclassed and subclasses can override storage and/or behavior
• everything remains nicely encapsulated
• you can use observation hooks — KVO, etc… — to monitor changes internally and externally
• you have a convenient spot to set a breakpoint on read and/or write to the property
• if that “internal only” instance variable were need to be exposed, it is a matter of copying the @property declaration itself; much less refactoring.
• you can leverage the declarative power of all the various modifier keywords — copy, strong, weak, atomic, etc.. — which the compiler is taking more and more advantage of over thime

Even internally to a class, I generally lean to using properties and dot syntax to maintain state within the object. That isn’t universally true — there will be some instance variables that I directly manipulate (exclusively directly manipulate; no @property at all) if my design is such that exposure would imply a massive refactoring anyway.