AnyObject, Any, any: any.

any looks similar to Any and AnyObject but has a different purpose since you use it to indicate the use of an existential. The following example code demonstrates an image configurator using the sample code from previous examples in this article:

struct ImageConfigurator {
    var imageContainer: any ImageContainer

func configureImage(using url: URL) {
        // Note: This is not the way to efficiently download images
        // and is just used as a quick example.
        let image = UIImage(data: try! Data(contentsOf: url))!
        imageContainer.configureImage(image)
    }
}

let iconImageView = UIImageView()
var configurator = ImageConfigurator(imageContainer: iconImageView)
configurator.configureImage(using: URL(string: "https://picsum.photos/200/300")!)
let image = iconImageView.image

As you can see, we indicated the use of an existential ImageContainer by marking our imageContainer property with the any keyword. Marking a protocol will indicate the performance impact of using a protocol in this way.

Existential types have significant limitations and performance implications and are more expensive than using concrete types since you can change them dynamically. The following code is an example of such change:

let button = UIButton()
configurator.imageContainer = button

Our imageContainer property can represent any value conforming to our ImageContainer protocol and allows us to change it from an image view to a button. Dynamic memory is required to make this possible, taking away the possibility for the compiler to optimize this piece of code. Up until the introduction of the any keyword, there was no explicit indication to developers indicating this performance cost.

Moving away from any
In a way, you could argue any, Any, and AnyObject have something in common: use them with caution.
You could rewrite the above code example by using generics and take away the need for dynamic memory:

struct ImageConfigurator<Destination: ImageContainer> {
    var imageContainer: Destination
}

Being aware of the performance implications and knowing how to rewrite the code instead is an essential skill to own as a Swift developer.

Next Article: AnyObject

Contacts
I have a clear focus on time-to-market and don't prioritize technical debt. And I took part in the Pre-Sale/RFX activity as a System Architect, assessment efforts for Mobile (iOS-Swift, Android-Kotlin), Frontend (React-TypeScript) and Backend (NodeJS-.NET-PHP-Kafka-SQL-NoSQL). And I also formed the work of Pre-Sale as a CTO from Opportunity to Proposal via knowledge transfer to Successful Delivery.

🛩️ #startups #management #cto #swift #typescript #database
📧 Email: sergey.leschev@gmail.com
👋 LinkedIn: https://linkedin.com/in/sergeyleschev/
👋 LeetCode: https://leetcode.com/sergeyleschev/
👋 Twitter: https://twitter.com/sergeyleschev
👋 Github: https://github.com/sergeyleschev
🌎 Website: https://sergeyleschev.github.io
🌎 Reddit: https://reddit.com/user/sergeyleschev
🌎 Quora: https://quora.com/sergey-leschev
🌎 Medium: https://medium.com/@sergeyleschev
🖨️ PDF Design Patterns: Download