What are the conventions and limitations associated with the use of weak properties in software systems?

Weak references in iOS are used to prevent strong reference cycles and memory leaks, especially in ARC (Automatic Reference Counting). However, there are some important conditions and limitations when using them:

• An object can be deallocated at any moment if there are no strong references to it. This means a weak property can suddenly become nil, and it should always be checked for nil before use.
• Weak properties are not suitable for storing objects that must have a guaranteed lifecycle. If an object is needed longer than a strong reference, a weak reference will not retain it.
• Not all types can be declared as weak. For example, in Swift, weak references can only be on class (reference) types, not on structures or enumerations.
• Weak references do not work directly with closures. To prevent retain cycles in closures, capture lists with weak or unowned are used.

Example of using a weak reference in Swift:

class ViewController: UIViewController {
    weak var delegate: SomeDelegate? // weak reference to avoid cycle
}

// Always check delegate for nil before calling methods
if let delegate = delegate {
    delegate.doSomething()
}