@NSCopying

I came across the NSCopying attribute when working with URLSession and URLSessionConfiguration.

From first glance I would expect any value that is prefixed with the @NSCopying attribute to return a new copy and any changes would not affect the initial value. Although that does work in theory, there is a scenario where this can be a little confusing.

To start off with, let me explain how @NSCopying works, with URLSessionConfiguration in URLSession.

@available(iOS 7.0, *)
open class URLSession : NSObject {

…
    @NSCopying open var configuration: URLSessionConfiguration { get }

…
}

URLSession has a variable called config, which is of type URLSessionConfiguration. Unlike all other variables within URLSession, configuration is prefixed with @NCopying. This stops you from changing a configuration which is already tied to a session. For example

// Retrieving the configuration from an old session but because configuration is prefixed with @NSCopying we are returned a copy of the original configuration.

let config = session.configurataion

config.httpAdditionalHeaders = ["header": "new"]

// If we then change the value of configuration, we can't just call a function on the session and expect it to use the new configuration settings.
 
session.dataTask(with: )

print(session.configurataion.config.httpAdditionalHeaders) // Prints nil

// We would then have to initialise a new session, and pass the new copy of configuration in.

session = URLSession(configuration: config)

print(session.configurataion.config.httpAdditionalHeaders) // Prints ["header": "new"]

So far this is exactly what we would expect to happen. A new copy of configuration is returned when we retrieve the value.

I thought I would then start to use this for my own classes so I started to write the code.

// A simple person class which has a variable called attributes which is prefixed with @NSCopying.

class Person {
  
  @NSCopying var attributes: Attributes

  init(attributes: Attributes) {
    self.attributes = attributes
  }
}

// The attributes class has to first conform to NSCopying otherwise we will get a type conformability error on our attributes variable inside the person class.

class Attributes: NSCopying {
  
  func copy(with zone: NSZone? = nil) -> Any {
   let attribute = Attributes()
    attribute.height = height
    attribute.weight = weight
    return attribute
  }
  
  var height: CGFloat = 180.0
  var weight: CGFloat = 80.0
}

So if we apply the same logic that we did with URLSessionConfiguration, you will see where the confusion lies.

let person = Person(attributes: Attributes())
print(person.attributes.height) // Prints 180  

// We would expect this to return a new copy of attributes right? Wrong!
let attribute = person.attributes
attribute.height = 30

print(person.attributes.height) //Prints 30

Well that is confusing. In the URLSessionConfiguration example the object was copied, however when creating a custom class which has a variable prefixed with @NSCopying the value is not copied, and we are just returned the original. I found this very confusing, but after some research online and trying to figure out why, I finally found where the issues lies.

When you assign a value in swift through an initialiser, it sets the value directly, and does not go though the setter. Unlike Objective C, where you have the option to go through the setter when initialising. This means that when we set the value, it never goes through the setter, and the value is never copied.

There is currently a swift proposal open with a proposed fix so I recommenced taking a look.

Proposal 153 – Compensate for the inconsistency of @NSCopying‘s behaviour

About Us

Recent Posts

I don't want this Class!

36th Four Villages Half Marathon 2019

Related posts

WWDC 19 – Swift UI, Combine

Running Xcode Tests from CI

Property Wrappers

Method Swizzling

Unit Testing with Viper

I don’t want this Class!