Copy-on-write is thread-safe for all Swift standard types, like Strings, Arrays, or Dictionaries (and also sets, even not mentioned in the blog post linked below), as these are considered value types in Swift: https://developer.apple.com/swift/blog/?id=10And value types are thread-safe by definition, so when you implement them as copy-on-write, this copy must be thread-safe, too, anything else would break the promisse that they are value types.If you imlepment your own copy-on-write type, it's in your responsebility to ensure that the copy is thread safe:If the instance passed as object is being accessed by multiple threads simultaneously, this function may still return true. Therefore, you must only call this function from mutating methods with appropriate thread synchronization.- Source: isKnownUniquelyReferenced(_:)

Sorry, but this is incorrect. The code found at the documentation of isKnownUniquelyReferenced(_:) is not how copy-on-write is implemented for Swift standard types. And how to do it corretly to become thread-safe is even hinted below the code sample:If the instance passed as object is being accessed by multiple threads simultaneously, this function may still return true. Therefore, you must only call this function from mutating methods with appropriate thread synchronization.And that's how Swift standard types have implemented their copy-on-write. As otherwise the promise that Array, String, and Dictionary are value types in Swift would not hold true. Value types are are always thread-safe. See last paragraph of https://developer.apple.com/swift/blog/?id=10

I have to diagree.In Swift, Array, String, and Dictionary are all value types. They behave much like a simple int value in C, acting as a unique instance of that data. You don’t need to do anything special — such as making an explicit copy — to prevent other code from modifying that data behind your back. Importantly, you can safely pass copies of values across threads without synchronization. In the spirit of improving safety, this model will help you write more predictable code in Swift.- Source: https://developer.apple.com/swift/blog/?id=10The following code is thread-safe:import Foundation class SomeClass { let lock = NSLock() var numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] func getNumbers ( ) -> [Int] { lock.lock() let result = self.numbers lock.unlock() return result } func modifyNumbers ( ) { lock.lock() let first = self.numbers.removeFirst() self.numbers.append(first) lock.unlock() } } let numberContainer = SomeClass() let thread1 = Thread() { while true { var numbers = numberContainer.getNumbers() // Numbers is now copy on write! // Modifying it will copy it. let first = numbers.removeFirst() numbers.append(first) } } thread1.start() let thread2 = Thread() { while true { var numbers = numberContainer.getNumbers() // Numbers is now copy on write! // Modifying it will copy it. let first = numbers.removeFirst() numbers.append(first) } } thread2.start() while true { numberContainer.modifyNumbers() }Three threads are constantly modifying a copy-on-write array and this causes no issues at all. Try it. Copy the code to test.swift:swiftc -sanitize=thread test.swift && ./testIf this wasn't thread-safe, then Swift would not treat arrays as values types and they would not "behave much like a simple int value in C" since for int values in C the code above would also be thread-safe.And in case you may think "Okay, then they must have changed that recently, this was definitely not the case when I wrote my reply", please note that the first blog post I linked is from Aug 15, 2014 and your reply is from Apr 14, 2017

So you are basically saying:Without a NEMachServiceName entry in the Info.plist, a System Network Extension cannot work at all?This is all a bit confusing, as a normal Network Extension didn't require such a key and a System Extension that is not a Network Extension apparently neither. There is no documentation on the differences between a Network Extension and a System Network Extension, so it's currently even unclear which entitlements or capabilities a System Network Extension or its hosting app really require or which Info.plist keys must be set.It turns out our validation problem was related to the App Group missing in the entitlements of the System Extension, despite the fact that Xcode itself manages these entitlements and in the UI everything looked correct. Making Xcode re-create everything solved the problem so far.