iOS Developer Diary

Actor isolation keywords in Swift 6.2 — nonisolated, isolated, @concurrent, @globalActor, any Actor

Tomasz — Sun, 12 Apr 2026 16:56:05 +0000

Swift Concurrency has a handful of keywords that control where code runs: nonisolated, isolated, @concurrent, @globalActor. They all answer the same question — which executor does this function run on? — just in different ways.

nonisolated — run on the caller's executor

When you mark a function nonisolated inside an actor, it doesn’t hop off to some generic executor. With Approachable Concurrency enabled (default from Swift 6.2, opt-in via SWIFT_UPCOMING_FEATURE_APPROACHABLE_CONCURRENCY = YES in earlier versions), a nonisolated function runs on the caller’s executor instead.

This was the original Swift Concurrency behaviour. SE-0338 changed it so that nonisolated async functions always ran off-actor. That change was later reverted in Swift 6.2 — so we’re back to running on the caller’s executor. nonisolated is now equivalent to nonisolated(nonsending).

				
					actor MyActor {
  var value = "abc"

  func test() async {
    await nonisolatedFuncCalledFromSelfActor()

    Task { @MainActor in
      await nonisolatedFuncCalledFromMainActor()
    }
  }

  nonisolated func nonisolatedFuncCalledFromSelfActor() async {
    self.assertIsolated() // ✓ — runs on MyActor's executor
    // self.value = "x"  ← ✗ compiler still sees this as nonisolated
  }

  nonisolated func nonisolatedFuncCalledFromMainActor() async {
    MainActor.assertIsolated() // ✓ — caller was @MainActor
  }
}

Notice the catch: even though assertIsolated() passes, the compiler still treats the function as nonisolated at the type-system level, so you can’t touch actor-isolated properties. The runtime and the type system are telling you different things — nonisolated describes the static view, not what’s actually happening on the thread.

Why is this useful? Less hopping on and off executors. Every unnecessary hop is overhead — the function suspends, waits for the target executor, and resumes. If the caller is already on the right executor, nonisolated avoids all of that.

@concurrent — force a hop off the actor

Sometimes you want the opposite — explicitly force the function off the actor and onto the global concurrent executor, regardless of who called it. That’s what @concurrent is for.

				
					actor MyActor {
  // Always hops to global concurrent executor
  @concurrent nonisolated func concurrentNonisolatedFuncCalledFromSelfActor() async {
    // self.assertIsolated() ← ✗ not on MyActor's executor
  }

  // @concurrent automatically marks the func as nonisolated too
  @concurrent func concurrentFuncCalledFromSelfActor() async {
    // self.assertIsolated() ← ✗ not on MyActor's executor
  }
}

isolated parameter — borrow another actor's isolation

Putting isolated before a parameter transfers the function’s isolation to that actor. The function is no longer isolated to self — it runs on the actor passed as an argument.

				
					actor ActorA {
  var x = "abc"

  func test() async {
    let b = ActorB()

    // Must await — needs to hop to b's executor
    await changeOtherActorStateWithIsolationToOtherActor(b)

    // No await — already on self's executor
    changeOtherActorStateWithSelfActorIsolation(b)
  }

  // Isolated to b, NOT to self
  func changeOtherActorStateWithIsolationToOtherActor(_ b: isolated ActorB) {
    b.y = "new"        // ✓
    // self.x = "new"  ← ✗ no longer isolated to self
  }

  // Isolated to self, b is just a regular parameter
  func changeOtherActorStateWithSelfActorIsolation(_ b: ActorB) {
    x = "new"          // ✓
  }
}

Only one parameter per function can be marked isolated.

isolated (any Actor) and #isolation

You can take it further and write functions that work with any actor dynamically. And with #isolation, the caller’s actor is captured automatically at the call site — no need to pass it explicitly.

				
					// #isolation captures the caller's actor at the call site
func changeIsolatedActorVariableWithDefaultIsolatedAny(
  isolation: isolated (any Actor) = #isolation
) {
  if let a = isolation as? MyActor {
    // Compiler doesn't know the dynamic type, so we assert it
    a.assumeIsolated { isolated in
      isolated.value = "abc" // ✓
    }
  }
}

actor Caller {
  func go() {
    changeIsolatedActorVariableWithDefaultIsolatedAny() // isolation = self, no await
  }
}

#isolation is a compiler macro — it captures the surrounding isolation at the call site, not at the function definition.

@globalActor — a shared singleton actor

@MainActor is the most familiar example of a global actor, but you can define your own. A global actor is a singleton actor that multiple types can all be isolated to — since they share the same executor, they can access each other’s state directly without awaiting.

				
					// Defining a new global actor
@globalActor
actor DatabaseActor {
  static let shared = DatabaseActor()
}

// Both classes share the same actor — they can access each other freely
@DatabaseActor class Repository {
  var cache: [String] = []
}

@DatabaseActor class QueryService {
  func invalidate(_ repo: Repository) {
    repo.cache = [] // ✓ same actor, no await needed
  }
}

// From outside — must hop in explicitly
Task.detached {
  // repo.cache = []  ← ✗ not isolated to DatabaseActor
  Task { @DatabaseActor in
    repo.cache = [] // ✓
  }
}

Observe interface orientation in SwiftUI

Tomasz — Wed, 06 Mar 2024 13:14:31 +0000

“Apple strongly discourages the use of ‘landscape’ and ‘portrait’ modes in applications and strongly encourages the use of size classes.”

That being said, sometimes we really need to know whether a device is in a landscape or portrait mode or even distinguish between landscape right and landscape left.

The most commonly used method found on the internet involves observing UIDevice.orientationDidChangeNotification. Unfortunately, this method is not entirely accurate. The device’s orientation and the interface orientation are two different things. For instance, the device orientation may include values like .faceUp or .faceDown, which do not translate to interface orientation. Additionally, even if the user enables rotation lock for the device, the device orientation may still change while the interface remains unchanged.

Thus, how can we accurately observe the true interface orientation? Retrieve it from: view.window?.windowScene?.interfaceOrientation

1. UIViewController that notifies about current interface orientation via Combine:

				
					class InterfaceOrientationProviderVC: UIViewController {
    private let interfaceOrientationSubject: CurrentValueSubject<UIInterfaceOrientation, Never>
    
    init(interfaceOrientationSubject: CurrentValueSubject<UIInterfaceOrientation, Never>) {
        self.interfaceOrientationSubject = interfaceOrientationSubject
        super.init(nibName: nil, bundle: nil)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    override func viewWillLayoutSubviews() {
        super.viewWillLayoutSubviews()
        
        // Set initial interfaceOrientation
        interfaceOrientationSubject.send(
            view.window?.windowScene?.interfaceOrientation ?? .unknown
        )
    }
    
    override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {

        // Update interfaceOrientation
        interfaceOrientationSubject.send(
            view.window?.windowScene?.interfaceOrientation ?? .unknown
        )
    }
}

2. Wrap view controller into SwiftUI view:

				
					struct InterfaceOrientationProviderView: UIViewControllerRepresentable {
    let interfaceOrientationSubject: CurrentValueSubject<UIInterfaceOrientation, Never>
    
    func makeUIViewController(context: Context) -> InterfaceOrientationProviderVC {
        InterfaceOrientationProviderVC(interfaceOrientationSubject: interfaceOrientationSubject)
    }
    
    func updateUIViewController(_ uiViewController: InterfaceOrientationProviderVC, context: Context) { }
}

3. Create ViewModifier which will observe interfaceOrientation changes and pass them to SwiftUI via environment value:

				
					private struct InterfaceOrientationKey: EnvironmentKey {
    static let defaultValue: InterfaceOrientation = .portrait
}

extension EnvironmentValues {
    var interfaceOrientation: InterfaceOrientation {
        get { self[InterfaceOrientationKey.self] }
        set { self[InterfaceOrientationKey.self] = newValue }
    }
}

private struct InterfaceOrientationViewModifier: ViewModifier {
    private let interfaceOrientationSubject: CurrentValueSubject<UIInterfaceOrientation, Never> = .init(.portrait)
    @State private var interfaceOrientation: InterfaceOrientation = .portrait

    func body(content: Content) -> some View {
        ZStack {
            InterfaceOrientationProviderView(interfaceOrientationSubject: interfaceOrientationSubject)
            
            content
                .onReceive(interfaceOrientationSubject, perform: { orientation in
                    self.interfaceOrientation = orientation.swiftUI
                })
                .environment(\.interfaceOrientation, interfaceOrientation)
        }
    }
}

extension UIInterfaceOrientation {
    /// Map from UIKit's UIInterfaceOrientation to SwiftUI's InterfaceOrientation
    var swiftUI: InterfaceOrientation {
        switch self {
        case .portrait: return .portrait
        case .landscapeLeft: return .landscapeLeft
        case .landscapeRight: return .landscapeRight
        case .portraitUpsideDown: return .portraitUpsideDown
            
        case .unknown: return .portrait
        @unknown default: return .portrait
        }
    }
}

4. Add convenient method to apply our view modifier:

				
					extension View {
    func observeIntefaceOrientation() -> some View {
        self.modifier(InterfaceOrientationViewModifier())
    }
}

5. Apply this modifier to main application/window view

				
					@main
struct TestApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .observeIntefaceOrientation()
        }
    }
}

And after that we can use it in our views:

				
					struct SomeView: View {
    @Environment(\.interfaceOrientation) private var interfaceOrientation

    var body: some View {
        HStack {
            Text("Current interface orientation:")
            Text(interfaceOrientation.id)
        }
    }
}

AWS Amplify partial model update

Tomasz — Sat, 27 Jan 2024 18:08:37 +0000

Amplify does not allow for the modification of just one field in the model, we always have to send all of its data. This becomes a significant issue when more than one user is editing the same model, resulting in data being overwritten by each other.

Fortunately, GraphQL requests provide such capability, and Amplify offers us many tools for constructing and sending these requests.

Let’s consider such a model:

				
					public struct Item: Model {
  public let id: String
  public var name: String
  public var modelFile: File?
  public var imageFile: File?
}

let myItem = Item(...)

The first thing we need to do is create a mutation GraphQL request:

				
					let request = GraphQLRequest<Item>.updateMutation(of: myItem)

If we were to send the request in this form, our model would be completely modified in the database. Therefore, we need to remove all fields from the request that we don’t want to edit, which are located in the dictionary request.variables?[“input”] – we just need to remove them.

Unfortunately, the fields in the GraphQLRequest structure are constant let, so we need to copy them, edit, and then create our own request instance by referencing everything from the previously generated one:

				
					var input = (request.variables?["input"] as? [String: Any]) ?? [:]

// Do not modify modelFile field
input.removeValue(forKey: Item.CodingKeys.modelFile.stringValue)

let editedRequest = GraphQLRequest<MutationSyncResult>(apiName: request.apiName, document: request.document, variables: ["input": input], responseType: request.responseType, decodePath: request.decodePath, options: request.options)

And then we simply need to send it:

				
					let result = try await Amplify.API.mutate(request: editedRequest)
let updatedItem = try result.get().model.instance as? Item

Summarizing everything up to this point, the method for editing the Item model could look like this:

				
					    private static func updateItem(item: Item, updates: [Item.CodingKeys : Encodable]) async throws -> Item {
        let tmpRequest = GraphQLRequest<Item>.updateMutation(of: item)
        
        var input = (tmpRequest.variables?["input"] as? [String: Any]) ?? [:]
        for key in Item.CodingKeys.allCases {
            
            // Do not remove id from input
            if key.stringValue == AnyModel.CodingKeys.id.stringValue { continue }
            
            if let newValue = updates[key] {
                
                // UPDATE this value
                do {
                    let newValueData = try JSONEncoder().encode(newValue)
                    let newValueJson = try JSONSerialization.jsonObject(with: newValueData)
                    input[key.stringValue] = newValueJson
                    
                } catch {
                    input[key.stringValue] = newValue
                }
                
            } else {
                // DO NOT UPDATE this value
                input.removeValue(forKey: key.stringValue)
            }
        }
        
        let request = GraphQLRequest<MutationSyncResult>(apiName: tmpRequest.apiName, document: tmpRequest.document, variables: ["input": input], responseType: tmpRequest.responseType, decodePath: tmpRequest.decodePath, options: tmpRequest.options)
        let result = try await Amplify.API.mutate(request: request)
        
        guard let newModel = try result.get().model.instance as? Item else {
            throw nilResultError
        }
        
        return newModel
    }

Looks fine, but could it be done more generic? So that we don’t have to write the same code for each model?

Yes! Just mark every model we want to modify as conforming to ‘HasCodingKeys’ protocol and and change our function accordingly:

				
					protocol HasCodindKeys: Model {
    associatedtype Keys: ModelKey
    static var keys: Keys.Type { get }
}

// Item model conforms to HasCodingKeys protocol
extension Item: HasCodindKeys {}

// Our final implementation:
private static func updateModel<T: HasCodindKeys>(model: T, updates: [T.Keys: Encodable]) async throws -> T {

        let tmpRequest = GraphQLRequest<T>.updateMutation(of: model)

        var input = (tmpRequest.variables?["input"] as? [String: Any]) ?? [:]
        for key in T.Keys.allCases {
            
            // Do not remove id from input
            if key.stringValue == AnyModel.CodingKeys.id.stringValue { continue }

            if let newValue = updates[key] {
                
                // UPDATE this value
                do {
                    let newValueData = try JSONEncoder().encode(newValue)
                    let newValueJson = try JSONSerialization.jsonObject(with: newValueData)
                    input[key.stringValue] = newValueJson
                    
                } catch {
                    input[key.stringValue] = newValue
                }
                
            } else {
                // DO NOT UPDATE this value
                input.removeValue(forKey: key.stringValue)
            }
        }

        let request = GraphQLRequest<MutationSyncResult>(apiName: tmpRequest.apiName, document: tmpRequest.document, variables: ["input": input], responseType: tmpRequest.responseType, decodePath: tmpRequest.decodePath, options: tmpRequest.options)
        let result = try await Amplify.API.mutate(request: request)

        guard let newModel = try result.get().model.instance as? T else {
            throw nilResultError
        }

        return newModel
    }

Example updating item’s name and imageFile without changing modelFile:

				
					        try await updateItem(item: myItem, updates: [
                .name: "New item name",
                .imageFile: File(url: url)
            ]
        )

Warning: If you have ‘Conflict resolution’ enabled, you need to provide the current version of the model when creating a request:

				
					let version = try await GraphQL.getModelVersion(model: myItem)
let request = GraphQLRequest<Item>.updateMutation(of: myItem, version: version)

Where the GraphQL.getModelVersion method looks like this:

				
					    private static func getModelVersion<T: Model>(model: T) async throws -> Int {
        let request = GraphQLRequest<T>.query(modelName: model.modelName, byId: model.identifier)
        let result = try await Amplify.API.query(request: request).get()
       
        guard let version = result?.syncMetadata.version else {
            throw nilResultError
        }
        
        return version
    }

Entering async/await Task from synchronous code in serial manner

Tomasz — Sat, 19 Aug 2023 18:21:32 +0000

Imagine you have some code outside of a Swift Concurrency (async/await) producing values that you need to consume inside an async/await Task in the same order that they are created.

Let’s see a simple example where we pass integers in a loop from a synchronous function to an async function:

				
					  func sendValues() {
        for i in 0..<1000 {
            Task {
                await consume(i)
            }
        }
    }
    
    func consume(_ value: Int) async {
        print(value) // values received NOT in order
    }

    /*
    Output:
    1
    4
    0
    8
    10
    9
    3
    12
    13
    14
    8
    ...
    */

You would expect to see values printed in order: 1… 2… 3… etc., but it is not the case here.

The sentence above is no longer true in the official Swift 6 implementation, thanks to: SE-0431

Unstructured tasks created inside the loop are scheduled on the global concurrent executor, which means they can be executed in any order:

				
					            Task {
                await consume(i)
            }

What about @MainActor? Main actor’s work is executed on main queue which is serial:

				
					        Task { @MainActor in
            await consume(value)
        }

It won’t work either because the task will be scheduled on a global executor, then execute its closure, realize it’s MainActor closure, and only then ‘hop’ to MainActor.

Apple engineers are aware of those limitations and said that they are working on them.

Are there any remaining options? Yes – AsyncStream:

				
					func sendValues() {

        // Create async stream
        var continuation: AsyncStream<Int>.Continuation!
        self.stream = AsyncStream<Int>.init {
            continuation = $0
        }
        
        // Send values 'in order' to async stream
        for i in 0..<1000 {
            continuation.yield(i)
        }
        continuation.finish()
        
        // Consume values
        consume(stream: stream)
    }

    func consume(stream: AsyncStream<Int>) {
        Task {
            for await value in stream {
                print(value) // values received in order
            }
        }
    }

The myth about value and reference types

Tomasz — Mon, 24 Oct 2022 15:29:03 +0000

Remember myself trying to learn how iOS memory management works, few articles from the first pages of Google learned me that classes are deallocated by ARC when their reference count equal 0, value types like structs, arrays, or strings are saved on the stack, reference values like classes and closures go into the heap, value types are better because stack allocation is faster, etc. And then thought to myself… ok! I got it! But in reality, is not that simple.

Let’s see Apple’s definition of value and reference type:

Value type – A value type is a type whose value is copied when it’s assigned to a variable or constant, or when it’s passed to a function.

Reference type – Unlike value types, reference types are not copied when they’re assigned to a variable or constant, or when they’re passed to a function. Rather than a copy, a reference to the same existing instance is used.

As we can see those definitions only specify how types are passed around, there is not a single word about the place they will be stored, they can be stored on the stack or the heap or even ‘both’, this is just an implementation detail.

There are some cases when a value type is passed by reference, to accomplish additional functionality for a Swift language or just as an optimization, there are two well known cases:

1. Passing value type into a closure:

				
					 var name: String = "Bob"

DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
    print(name) // prints "Muniek" - name variable is captured be a reference not a copy.
}

name = "Muniek"

Why? This is just how Swift was implemented, be default closure capture value by reference, or better said, capture variable by reference, you can use capture list to change that.

This is one of Swift’s creators explaining why it works that way:

2 . Array is a value type but passed by reference not a copy, an actual copy of an array is made when mutation of this array occurs, this is an optimization to reduce copying large amounts of data as arrays can have thousands of items inside. This optimization is called Copy on write (COW). Underneath it behaves like a reference type violating the definition of value type but when you want to edit it, it will make a copy. Maybe that is the reason why Apple likes to refer to value types as „value type SEMANTICS” – they behave as value type on the surface, but what is underneath is again… implementation detail.

When type is allocated on the heap and when on the stack?

I’m sure you heard that stack allocation and deallocation are fast so the best precise will be to allocate everything on the stack, but it is impossible because of the way the stack works.

Generally, two things imply whether something is allocated on the heap:

1. when something has to outlive the scope it was created in
You can only put and pop from the stack, imagine a variable created inside some function. If this variable (THIS variable instance not a copy) has to be accessible after the function exits, it cannot be stored on the stack, because there will be other function-related stuff saved, so to deallocate function call and save THIS variable, the compiler will need to pop all function data and push THIS variable again on top, which may not seem like a lot of work but image function calling another function and this function calls another and another and every single function want to have some local variables by accessible outside their scope, this will require a lot of stack memory juggling – it is just not practical so better way is to allocate this variable on the heap and pass a reference to it.

2. when something may change its size
Imagine a function that has two local variables: String and Int

				
					func someFunction() {
   var name: String = "Muniek"
   var age: Int = 30
}

Runtime compiler will allocate memory for those variables on the stack like so:

(This is just a simplified demonstration, in reality, the whole name will be allocated in a single line/word)

Then if the function wants to change the name variable for something longer, again, the stack will have to pop all data up to the „name” variable, push a new string and other values again – which is not a quick way.

To be more precise, the compiler allocates some fixed amount of memory for a string variable, whether it is a single letter „A” or a name „Michael” String will take the same amount of memory on the stack, so some mutation is possible on the stack, but when string becomes longer, the whole string is moved into the heap and only reference to this memory is kept o the stack. Similarly, arrays that are value type but values inside an array are kept on the heap.

So if those two cases don’t occur, everything is allocated on the stack, right? What about class? If we create an immutable instance of a simple class, will it be stored on the stack?

				
					class Person {
    let name: String = "Muniek"
}

func someFunction() {
   let person = Person() // heap
}

It will be allocated on the heap. Why not on the stack? It will be really quick and just better, I do not know the answer, maybe Swift will implement this type of optimization in the future or maybe that type of optimization will prevent some other optimizations and they choose not to do it?

Reference type inside value type

Swift likes value types like structs, they are most likely stored on the stack and do not have shared instance which Apple always refer to as a cause of „unintended sharing of state”

So are structs always a better choice? Not really… just look at the example with arrays and COW we discussed earlier or this struct which contains a bunch of classes as members:

				
					struct SomeType {
    var age: Int

    var object: SomeClass
    var object: SomeClass
    var object: SomeClass
    var object: SomeClass
    var object: SomeClass
}

Struct being value type is passed as a copy but what about reference types inside? They will be passed as a reference, or better said copy of a reference increasing the reference count of every single one of them. Every time we pass this struct compiler needs to increase the reference count, which again… doesn’t look like much work, but on a larger scale it may sum up to milliseconds or even seconds!

Let’s change SomeType to be a class – every time you pass this object only one reference count needs to be increased, there is no need to change the reference count of every reference type member.

Value type in a reference type

				
					struct SomeStruct {
    var name: String
}
        
class SomeClass {
    var someStruct: SomeStruct = .init(name: "Muniek")
}

In this situation, the value type struct will be saved where the class is, on the heap. Passing SomeClass to another function will pass a reference to this class and give access to the same struct:

				
					let someClass = SomeClass()
print(someClass.someStruct.name) // Muniek
        
func rename(_ someClass: SomeClass) {
   someClass.someStruct.name = "Bob"
}
        
rename(someClass)
print(someClass.someStruct.name) // Bob

Collecting logs from physical device after UI and Unit tests on CI machine (Fastlane, Jenkins)

Tomasz — Wed, 24 Aug 2022 15:33:27 +0000

UI and Unit automated tests are great when they pass and everything is green, the problem appears when some tests fail and we need to know why. Some tests may fail once per 100 runs, especially UI integration tests and simply running them again may not give us any answers, those flaky tests are the reasons why sometimes we put a blind eye to them just because it is too much of a hassle.

1. Logging messages in the application code
2. Setting up UI/Unit tests observers
3. Categorize logs based on current Unit test
4. Categorize logs based on current UI test
5. Collecting logs after tests with Simulator
6. Collecting logs after tests with physical device
7. Getting logs from CI to Jenkins
8. Browsing through logs

Logging messages in the application code

For logging, we are gonna use Logger from os module which is an Apple unified logging system.

First, we need to import os module and create and Logger structure. The initializer takes two parameters, subsystem, and category which are useful for filtering log messages.

In this article, we will only use category but maybe you would like to set subsystem as Test Suite’s name and Test Case’s name as the category, it is up to you.

				
					import os
internal var logger = Logger(subsystem: "com.company.sampleApplication", category: "category")

The logger must be globally accessible and declared as a variable, in order to be able to change its category accordingly to current test, we will get back to it later.

				
					// Log error message example:
logger.error("Error occurred!")

you can read more about Logger here:
https://developer.apple.com/documentation/os/logger

The logger has typical log levels debug, info, notice, error, and fault.
With default logging system configuration low priority levels (debug and info) aren’t stored in phone’s persistent memory, they are available only during app’s live cycle, so the best way is to only use notice, error, and failure for important messages.

You can use logger alongside other logging engines, I personally like to use SwiftyBeaver as the main application logging system as it has some useful built-in features and a simple way to add new logging methods:

				
					class OsLoggerDestination: BaseDestination {
    override open func send(_ level: SwiftyBeaver.Level, msg: String, thread: String, file: String, function: String, line: Int, context: Any? = nil) -> String? {

        let formattedString = super.send(level, msg: msg, thread: thread, file: file, function: function, line: line, context: context) ?? ""
        
        switch level {
        case .debug, .info, .verbose:
            logger.notice("\(formattedString, privacy: .public)")
            
        case .warning:
            logger.error("\(formattedString, privacy: .public)")
            
        case .error:
            logger.fault("\(formattedString, privacy: .public)")
        }
        
        return formattedString
    }
}

SwiftyBeaver.addDestination(OsLoggerDestination())

Setting up UI/Unit tests observers

XCTest module contains a delegate protocol named XCTestObservation which is called during a test execution cycle, e.g before each test starts or after its failure.

In order for it to work we need to create two classes that implement this protocol, UnitTestDelegate, and UITestDelegate:

				
					import XCTest

class ____TestDelegate: NSObject, XCTestObservation {
    
    func testBundleDidFinish(_ testBundle: Bundle) {
        XCTestObservationCenter.shared.removeTestObserver(self)
    }
    
    override init() {
        super.init()
        XCTestObservationCenter.shared.addTestObserver(self)
    }

    func testCaseWillStart(_ testCase: XCTestCase) {
        // Called before each test
    }
}

and set them as the Principal class of each test targets info.plist:

Categorize logs based on current Unit test

Our goal here is to set the test case name as a logger category. With @testable import inside Unit Test Target we can access application internal variables, in this case from testCaseWillStart function inside UnitTestDelegate we can set up our application logger accordingly:

				
					@testable import SampleApplication
import os

func testCaseWillStart(_ testCase: XCTestCase) {
    logger = Logger(subsystem: "com.sample.sampleApplication", category: testCase.name)
}

Categorize logs based on current UI test

UI Test target doesn’t have access to any of the application properties so we need to send the test case name from the test to an application. We can use launchEnvironments by setting their test name under some key then accessing it inside the application code in didFinishLaunchingWithOptions and setup our logger category:

inside testCaseWillStart function of UITestDelegate class:

				
					    func testCaseWillStart(_ testCase: XCTestCase) {
        app.launchEnvironment["TEST_NAME"] = testCase.name
    }

and then in the application’s AppDelegate:

				
					    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        if let testName = ProcessInfo.processInfo.environment["TEST_NAME"] {
            logger = Logger(subsystem: "com.company.sampleApplication", category: testName)
        }

        return true
    }

Collecting logs after tests with Simulator

It is pretty easy with simulator because in Fastlane we need to set just two parameters in the scan suite run_tests function:

output_directory – The directory in which all reports will be stored
include_simulator_logs – whether the logs generated by the app in the Simulator should be written to the output_directory

Collecting logs after tests with physical device

In order to retrieve logs from a physical device we will use the log tool as recommended by Apple here:

https://developer.apple.com/documentation/os/logging/viewing_log_messages

One downside of this approach is this command requires sudo privileges, which may be problematic on CI environments but not impossible e.g. by responsibly editing sudoers file.

first, in Fastfile we need to save test start time:

				
					start_time = "@#{Time.now.to_i}"

and then collect logs after tests execution:

				
					sh "sudo log collect --device-udid 'xxxxxxxx' --start #{start_time} --output ./mylogs.logarchive"

Getting logs from CI to Jenkins

zip logarchive by:

				
					sh "zip -r mylogs.zip mylogs.logarchive/"

and add a step in the Jenkinsfile pipeline:

				
					archiveArtifacts(artifacts: 'test_output/mylogs.zip')

Browsing through logs

Now we can open logs using the Console app which is preinstalled on every MacBook and filter our logs by category by typing the test suite name and test case name separated by space, e.g. „RequestTests testSendRequest„ in the upper right corner and see all logs from that test:

SSL/TLS for dummies

Tomasz — Fri, 24 Jun 2022 15:34:17 +0000

Why do some people call it SSL (Secure Socket Layer) and others TLS (Transport Layer Security) Nowadays we use those names interchangeably but the truth is SSL is just an older term

TLS is a protocol that ensures:
– only the sender and receiver can read messages,
– sender and receiver can identify each other,
– messages cannot be changed while being transferred.

This article will present a short story of Bob and Alice . This will help us understand why we need TLS and the basics of how it works.

Here are Bob and Alice:

They already know that sending plain text messages over the internet can be dangerous because they can be intercepted by other people. Therefore, they want to find the best way to encrypt their messages.

Now, they have a choice as there are two types of encryption they could use – symmetric and asymmetric.

Symmetric encryption is based on a special word which is used to encrypt and decrypt messages. In other words, there is a secret phrase used to encrypt and decrypt data and this phrase is called a KEY – we will use this term from now on.

When referring to symmetric encryption one most likely means a variant of AES (Advanced Encryption Standard) The newest LTS1.3 supports only 3 encrypting algorithms – 2 variants of AES (e.g AES128, AES256 where number indicates symmetric key size) and ChaCha20 (do not worry, I have never heard of ChaCha either…)

Back to our story… Bob decided to try the symmetric approach first. He made up a key and used it to encrypt his messages making them secure and unreadable to anyone who doesn’t know that key.

As a result, he achieved an acceptable level of security but Alice cannot understand any of it, because she’d also need to to know the key that Bob used to encrypt his messages with.

When Bob realized she couldn’t understand anything, he decided to share the key with Alice as his initial and unencrypted message.
That’s when a new character appeared… Mallory, who managed to capture that message, obtain the key and decrypt all their private messages.

Bob had to find a safer way to exchange the symmetric key. That’s when he decided to try the other approach – asymmetric encryption.

In case of the asymmetric approach, Bob and Alice both have their own pair of keys: public and private. The public key is meant to be shared with anyone, while the private key should remain known only to its owner.
The power of this type of encryption is that messages encrypted with the public key can only be decrypted using the matching private key, while messages encrypted with the private key can only be decrypted with matching public key.

It’s as if you would use one key to open your house’s door, a different one to close it, and the other way around.

Even though it looks like you can use public and private keys interchangeably there is a significant difference between the two. Private key is mathematically a private key and cannot be replaced by a public key. You can recover a public key using a private key but not the other way around.

Bob created his own key pair, kept the private key for himself, and sent the public key to Alice as a plain text message since it’s safe for anyone to see it.
Then, Alice created her own key pair, and shared the public key with Bob.

Bob encrypted message containing the key used in symmetric encryption using Alice’s public key and only Alice can decrypt it because only she has the corresponding private key – we call it a „key exchange”. After that both Alice and Bob knew the secret key and could continue their conversation using symmetric encryption

Why not always use asymmetric encryption?
Asymmetric encryption is slower and requires larger key size to achieve the same level of security.
This method does not include encrypting entire messages or files like movie.mp4. Instead, data is divided into multiple chunks which are encrypted and decrypted individually and later stitched back together. Symmetric encryption is much simpler in this matter.

This approach to key exchange is called “RSA key exchange” because it is using RSA cryptography. Nowadays, TLS 1.3 does not support RSA key exchange anymore. I’m using RSA throughout the article for simplicity as RSA can do everything: encrypt, decrypt, sign, validate signatures, and key exchange.

The current implementation of TLS requires using DH (Diffie Hellman) key exchange. In fact, it is not really an „exchange” – in this algorithm both sides of communication generate some public and private values, exchange public parts and calculate a key on their own side ending up with the same key for symmetric encryption, better called as „key agreement”.

There are other variants of this algorithm using Elliptic Curves as a mathematical method to end up with the same key on both sides. It is called ECDH (Elliptic curve Diffie Hellman).

As we can see in rfc8446 section-2, there is no support for DH or ECDH but a variant of them with letter E at the end – DHE and ECDHE where E stands for „ephemeral”. DHE and ECDHE variants both require to generate new keys for every new connection, e.g. in case of the RSA key exchange a new key pair is generated whenever there’s need to exchange a symmetric key. Why is it important?

Imagine that Mallory records every encrypted data sent between Bob and Alice. He doesn’t understand any of it now but after 5 years could steal Alice’s private key, and then be able to decrypt all of those key exchanges. This way, he could obtain the symmetric keys that were used and decrypt every single message that was sent in those last 5 years. However, in case of the ephemeral approach none of the private keys used for key exchange are stored, so there is nothing to steal. This guarantees what is called in cryptography „perfect forward secrecy”.

Now, it looks like Bob and Alice achieved their goal of secure communication…
… but then Mallory strikes again by intercepting their key exchange communication:

Bob sends his public key to Alice but Mallory captures this message and pretends to be Alice so he sends his own public key back to Bob. They exchanged keys and started their communication. Then, Mallory did the same with Alice. As a result, Bob and Alice both exchanged their keys with Mallory.

Neither Bob nor Alice were aware of Mallory’s interception and started their conversation:

Bob wanted to send a message to Alice saying: „Hey, I have some secrets to tell you”, but it went to Mallory instead, Mallory had the right keys and could decrypt all messages. After that, Malory could do two things:

Read secret messages using keys exchanged with Bob, then encrypt this message using the key exchanged with Alice and forward it to her. In that case, Bob and Alice can talk for hours while being unaware of the fact that someone is reading their messages.
Drop Bob’s message and send his own message to Alice while pretending to be Bob.

These types of attacks are called „Man in the middle attack”. In order to prevent that from happening we need a way to identify the person sending a message, like we identify people using ID cards. An ID card contains personal information and a photo, so someone can compare the photo to an actual person and confirm that this ID belongs to him. We trust that the government institution which issued this ID has done their work well.

In the IT world, those ID cards are called Certificates and include (among other things): owner information, a public key, and a signature – which is really important as it guarantees that the information in this certificate is trustworthy and wasn’t changed.

Before going any further, we need to understand two things:

What is hashing – hashing means calculating a fixed-sized value from other values. For example, we can take a whole 500 pages long book and generate 64 characters long hash value out of the whole text. This hash value looks to us humans like garbage but it’s not. Those 64 characters are unique for those 500 pages of text, changing just one letter will generate a completely different hash value. Hashing algorithms in cryptography are assumed to be one-way which means there is no practical way to recover the original data from the hash value.

In TLS 1.3, the hashing algorithm used is most likely SHA-2 (SHA256, SHA384, or SHA512).
For example, a hash value from text
„Hey, my name is Muniek” = „064d19817d983f5afc7406914e61426c5de79a40a4d6e1ce0f06d87b1d1670eb”

and after changing just one letter to an uppercase:
„Hey, my name is MunieK” = „2ec314aba71492045babd66b57e312b616031ac77b38e5d0cb3f516006bdf9d5”

How basic signing (creating a signature) works – Bob wants to send a message to Alice in a way that makes it possible for Alice to confirm it was really sent by Bob. Be aware that signing does not mean encryption. Signing is for verifying the authenticity and integrity of a message.

Bob can send his message using plain text and attach another version of that same message but encrypted with his private key. Once Alice receives the message, she can use Bob’s public key (assuming that Alice is sure this public key belongs to Bob) to decrypt the encrypted message and compare it with the plain text version. If they’re the same, it means the message was not changed and it must have been sent by Bob because only Bob had the right private key to encrypt it. Encrypting the whole message and attaching it to the original message seems impractical so instead we encrypt just the hash value of that message and some padding (pkcs v1.5 padding). This approach is called “digest”.

We need another character in this story, a character that is known and trusted by Bob and Alice and ideally by everyone else, let’s call him Ted.
Ted’s role is to create certificates for other people.

Bob wanted to have a valid and trusted certificate, so he sent a signed request with his identity information and public key to Ted and asked him to create a certificate, this request is called CSR (certificate signing request).
Ted validated that Bob is really Bob and all informations provided in CSR are correct, then used those informations to create a certificate, and then really important – Ted signed this certificate using his private key.

Alice after receiving certificate form Bob verified whether it was signed by Ted by calculating hash value of this certificate, and comparing to the signature decrypted with Ted’s public key, beacuse of that Alice is sure that she can trust informations in this certificate including Bob’s public key and safely send messages decrypted by this key because only true Bob can decrypt those messages – only Bob has the corresponding private key.

The word „trust” is important here – whole TLS security after all depends on the simple trust that Ted (CA – Certificate Authority) has done his job right.

Let’s imagine that Mallory creates a CSR claiming he owns google.com and globally trusted CA (trusted by all modern operating systems) somehow signed it, now Mallory can do man in the middle attack every time Bob or Alice tries to open gmail.com, google.com, youtube.com, etc.

And… those things happen from time to time in real life and this is one of the few reasons why the internet is not completely secure.

Bob and Alice finally achieved a ‚good enough’ level of security. Now they want more people to use this method to communicate with each other, everyone in the city creates their own key pairs and certificates signed by Ted. Tens of thousands of people communicate securely using TLS

but then Mallory breaked into Ted’s house and stole his private key, created thousand of valid and trusted certificates, pretending to be whoever he wants.

People know that every single certificate issued by Ted must not be trusted. They need a new CA but right now they do it in the right way.

Ted created a new key pair and certificate and signed it using his own private key (that certificate is called self-signed – there are no other CAs, he is the source of truth, there is no certificate above this certificate and that’s why is it also called a root certificate).

Then he created a few other certificates and key pairs and signed those with his first, root certificate, those certificates are called intermediate certificates. Private key from the root certificate is kept in a safe and used e.g. only once every 5 years to generate new intermediate certificates.

Intermediate certificates will be used to sign other people’s certificates, called client certificates. Instead of one private key to sign all of the client’s certificates, Ted uses many private keys from intermediate certificates, and in case one of them will be compromised, only part of certificates from Ted will become unsafe, only those signed by this single certificate.

This pattern of client certificate signed by an intermediate certificate signed by root certificate is called „certificate chain” or „chain of trust” (can be more than one intermediate certificate in between)

Now when Bob sends his certificate to Alice she is unable to verify if this is a valid certificate, because Bob’s certificate was signed by one of the intermediate certificates which Alice doesn’t know. Bob needs to send his certificate and every intermediate in between and only then Alice can see that Bob’s certificate was trusted/signed by intermediate certificate and this certificate was trusted/signed by the root certificate which Alice trusts herself, and that’s it!

This whole process is a simplification of how a TLS handshake looks like, from now you will be able to understand more complex articles

Understanding Sendable protocol in Swift 6

Tomasz — Tue, 19 Apr 2022 17:48:12 +0000

This article refers to Swift’s development version Trunk Development Snapshot (March 22, 2022) and uses -warn-concurrency flag in Xcode Build Settings – Other Swift Flags in order to experience new async/await restrictions as swift 6 has not yet been implemented.

Swift concurrency using Async/Await is not only a way to create a readable and clean concurrency mechanism but also a safe one.
One of the most common pitfalls of concurrency is when two or more threads try to use the same memory address at the same time, for example, when one thread is reading a value and the other is attempting to edit it – this situation is called data race and most likely ends up as an application crash.

In new async/await every Task and Actor is accessed at most by one thread at a time so there is no longer a possibility for data race inside.

Note – Even though Task/Actor is accessed by one thread only, there is no guarantee that it will be always the same thread

someFunction and otherFunction may be executed using different threads, every await is a potential suspension point where task can give up its thread and got different one to continue its job.

The problem often occurs when we decide to pass some data between Tasks or Actors.

Swift is trying to solve it by statically checking if code is safe to be accessed concurrently. Thanks to this mechanism, we will be informed about possible data races already during build time as a compiler error that we need to either solve or ensure the compiler that we know what we are doing.

That’s where Swift comes with a new marker protocol Sendable and function attribute @Sendable

Sendable protocol in Swift 6

Sendable protocol in Swift indicates that type is safe to be used concurrently within new swift concurrency and The main rule is that ONLY Sendable types can escape an Actor or Task to another Actor or Task.

[Update 2025] – The rule stated above is still generally correct but has slightly changed with the implementation of ‘Region-based isolation’– SE-0414

That’s pretty much it! Let’s see an example:

				
					class MyClass {
    var name: String = "Muniek"
}

actor MyActor {
    // Non-Sendable type MyClass
    var myClass: MyClass = .init()
    
    func someFunction() async {
        // Function inside an actor can edit its own variables
        // Actor types has own synchronization mechanism ensuring
        // exclusive access to his own properties
        
        // Every Actor property is isolated to an Actor
        // and can be accessed only from inside that actor
        myClass.name = "Bob"
        
        // Based on our rule we cannot pass actor-isolated
        // non-sendable properties to other Task or Actor
        let otherActor = OtherActor()
        
        // Error: Non-sendable type 'MyClass' passed in implicitly
        // asynchronous call to actor-isolated instance method
        // 'otherFunction(myClass:)' cannot cross actor boundary
        await otherActor.otherFunction(myClass: myClass)
    }
}

Passing non-sendable types outside an actor or Task is restricted because Tasks can execute their code in parallel with other Tasks. Using non-sendable instances in parallel may end up in an application crash caused by a data race.

To solve the problem in our example we need to inform the compiler that the value can be safely passed concurrently, and we can do so by conforming to the Sendable protocol.

Simple types like integers, strings, tuples, structs, and enums implicitly conform to Sendable because there are value types and are safe to be passed between concurrency domains as long as every one of its members conforms to the Sendable protocol.

Actors are internally synchronized protecting their mutable states so also they implicitly conform to Sendable.

Generic types also conform to Sendable when all types inside conform to Sendable.

We can just change the declaration of MyClass to be a struct and everything will be okay, because as a struct it will implicitly conform to Sendable.

The problem appears when dealing with reference types like Classes and Closures.

Sendable in Classes

Classes do not implicitly conform to Sendable, we must explicitly mark them as Sendable and final class, sendable cannot inherit from classes other than NSObject (for Objective-C interoperability).

				
					final class MyModel: Sendable { }

As in the case of other types in class all members must be Sendable, we can easily add some immutable properties like so:

				
					final class MyModel: Sendable {
    let name: String = "Bob"
}

It is safe to be passed concurrently because there cannot be a data race in immutable values, multiple thread reading at the same time cannot create data race. Let’s add a variable:

				
					final class MyModel: Sendable {
    let name: String = "Bob"
    
    // Error: Stored property 'address' of 'Sendable'-conforming
    // class 'MyModel' is mutable
    var address: String = "Krk"
}

How can we make sure that concurrent access to the variable is safe?
We need to add a synchronization mechanism on our own, using locks, queues, etc.
Let’s imagine that we have a type named SuperThreadSafeString which is thread safe String type:

				
					final class MyModel: Sendable {
    let name: String = "Bob"
    
    // Error: Stored property 'address' of 'Sendable'-conforming
    // class 'MyModel' is mutable
    var address: SuperThreadSafeString = .init()
}

Even now we still got error that address variable is non-Sendable because compiler is unable to check if it is really thread safe, in this case there is only one option left – to tell the compiler that we know what we are doing by using @unchecked Sednable:

				
					class MyModel: @unchecked Sendable {
    let name: String = "Bob"
    var address: SuperThreadSafeString = .init()
}

Now the compiler is satisfied, it does not care at all about the Sendability, you can forget any restrictions, but all responsibility is in your hands.

@Sendable attribute for functions

Functions can also be problematic when passing between concurrency domains, because they can capture other values with them:

				
					class MyClass {
    func doSomething() {
        var name: String = "Muniek"
        
        let function = {
            name = UUID().uuidString
            print(name)
        }
        
        for _ in 0...1000 {
            Task {
                function()
            }
        }
    }
}

We passed a function to a 1000 Tasks which can run concurrently to each other causing the application to crash by data race because the function captured String variable name by reference and all of Tasks are referencing the same memory address.

Swift requires closure that is passed between Tasks/Actor to be Sendable, there are few rules to make it to conform to Sendable:

Marking as @Sendable, like in case of @escaping
All values captured by closure must be captured by-value
All captured values must be Sendable

Sendable closures in Actor

The closure created inside an actor can be passed to another actor/task and executed there concurrently to an actor.

				
					actor MyActor {
    var actorIsolatedVariable: String = "Bob"
    
    func doSomething() {
        Task.detached {
           // Error: Expression is 'async' but is not marked with 'await'
           self.change(name: "Michael")
        }
                
        change(name: "Tom")
    }
    
    func change(name: String) {
        actorIsolatedVariable = "Michael"
    }
}

Task.detached Closure will run concurrently to the rest of the code allowing simultaneous mutation of actorIsolatedVariable causing a potential data race.
To avoid this problem, Swift comes with a rule that @Sendable closures are NOT isolated, so actor’s isolated properties cannot be accessed synchronously.

But there is an exception:
Even though closure passed to an Task.init is @Sendable it inherits Actor isolation and can access actor properties synchronously whether there are Sendable or not:

				
					actor MyActor {
    var name = "Muniek"
    
    func myFunction() {
        name = "Michael"
        
        Task {
            name = "Bob"
        }
    }
}

Every actor uses his own instance of SerialExecutor which can execute at most one job at a time, this synchronization protects actor internal mutable states from data race.
Non-Sendable types cannot escape concurrency in which it was created so non-sendable closures created inside an Actor must stay inside an actor and execute on Actor’s executor.
Closures executing on the actor’s executor are safe to use the actor’s properties synchronously and that’s why non-sendable closures created inside an Actor are actor-isolated.

Let’s see an example of both sendable and non-sendable closures inside an actor:

				
					actor MyActor {
    var actorIsolatedVariable: String = "Bob"
    
    func someFunction(nonSendableClosure: () -> Void) {
        nonSendableClosure()
    }
    
    func otherFunction(sendableClosure: @Sendable () -> Void) {
        sendableClosure()
    }
    
    func doSomethingInside() {
        someFunction(nonSendableClosure: {
            actorIsolatedVariable = "Michael" // Ok
        })
        
        otherFunction(sendableClosure: {
            // Error: Actor-isolated property 'actorIsolatedVariable'
            // can not be mutated from a Sendable closure
            actorIsolatedVariable = "Michael"
        })
    }
}

There is a new Swift proposal SE-0338 which is accepted but not yet implemented, so we can only learn this theoretically

SE-0338 Specify that actor-isolated async functions always execute on actor’s executor and non actor-isolated async functions never executes on actor’s executor.

[Update 2025] This change was implemented, but later reverted in Swift 6.2 — use `@concurrency` to hop off the calling actor.

Without those restrictions calling some outside async functions from an actor will run this function on an actor executor until suspends or switch to another actor, let see an example:

				
					class MyClass {
    func longOperation() async {
        // Long async operation that do not need actor isolation
    }
}

actor MyActor {
    func doSomething() async {
        // Calling non-actor isolated async function of MyClass, which will execute on actor’s executor
        await myClass.longOperation()
    }
    
    func doSomethingImportant() async {
        // Something really important here, that need actor isolation
    }
}

If doSomething function would be called first, actor executor will be kept busy during whole longOperation execution time which can take a few seconds, and during that time actor is unavailable for other actor-isolated functions.

But of course, there is an exception:

				
					actor MyActor {
    var data: Data?
    
    func updateData() async {
        return await withCheckedContinuation { continuation in
            Server.fetchData { data in
                self.data = data
                continuation.resume()
            }
        }
    }
}

withCheckedContinuation is an non actor-isolated async function so should not be executed on actor executor but closure inside is non-sendable so should be an actor-isolated.
Swift engineer told me that they gonna make withCheckedContinuation an exception to SE-0338.

Known bugs

There is possible way to pass non-sendable actor-isolated variable outside an actor and mutate it synchronously:

				
					class MyClass {
    var name = "Muniek"
}

actor MyActor {
    // non-sendable actor-isolated variable
    var myClass: MyClass = .init()
    
    func inside_one() async {
        await someFunctionOutside(myclass: myClass)
    }
    
    func changeName() async {
        myClass.name = "Michael"
    }
}

func someFunctionOutside(myclass: MyClass) async {
    // with SE-0338 implemented, this function will switch
    // from actor executor to a generic executor so there wont be any actor isolation
    
    // without SE-0338 function will switch to generic executor after await
    await Task.yield()
    
    // With or without SE-0338 this mutation of actor-isolated variable
    // occurs without any isolation
    myclass.name = "Bob"
}

Special thanks to Przemek Błasiak for help with editing.