ably · lawrence-forooghian · Oct 17, 2025
diff --git a/.github/workflows/check.yaml b/.github/workflows/check.yaml
@@ -20,7 +20,7 @@ jobs:
         with:
           submodules: true
 
-      # This step can be removed once the runners’ default version of Xcode is 16.3 or above
+      # This step can be removed once the runners' default version of Xcode is 16.3 or above
       - uses: maxim-lobanov/setup-xcode@v1
         with:
           xcode-version: 16.3
@@ -49,7 +49,7 @@ jobs:
   #        with:
   #          submodules: true
   #
-  #      # This step can be removed once the runners’ default version of Xcode is 16.3 or above
+  #      # This step can be removed once the runners' default version of Xcode is 16.3 or above
   #      - uses: maxim-lobanov/setup-xcode@v1
   #        with:
   #          xcode-version: 16.3
@@ -68,7 +68,7 @@ jobs:
         with:
           submodules: true
 
-      # This step can be removed once the runners’ default version of Xcode is 16.3 or above
+      # This step can be removed once the runners' default version of Xcode is 16.3 or above
       - uses: maxim-lobanov/setup-xcode@v1
         with:
           xcode-version: 16.3
@@ -149,7 +149,7 @@ jobs:
         with:
           submodules: true
 
-      # This step can be removed once the runners’ default version of Xcode is 16.3 or above
+      # This step can be removed once the runners' default version of Xcode is 16.3 or above
       - uses: maxim-lobanov/setup-xcode@v1
         with:
           xcode-version: 16.3
@@ -226,7 +226,7 @@ jobs:
         with:
           submodules: true
 
-      # This step can be removed once the runners’ default version of Xcode is 16.3 or above
+      # This step can be removed once the runners' default version of Xcode is 16.3 or above
       - uses: maxim-lobanov/setup-xcode@v1
         with:
           xcode-version: 16.3

diff --git a/.prettierignore b/.prettierignore
@@ -1,4 +1,4 @@
-# Don’t try and format the asset catalogue JSON files, which are managed by Xcode
+# Don't try and format the asset catalogue JSON files, which are managed by Xcode
 *.xcassets/
 
 # Submodules

diff --git a/.swiftlint.yml b/.swiftlint.yml
@@ -16,7 +16,7 @@ disabled_rules:
   - nesting
   - type_body_length
 
-  # Rules of type "lint" that we’ve decided we don’t want:
+  # Rules of type "lint" that we've decided we don't want:
   - todo # We frequently use TODOs accompanied by a GitHub issue reference
 
 opt_in_rules:
@@ -34,7 +34,7 @@ opt_in_rules:
   - reduce_into
   - sorted_first_last
 
-  # Opt-in rules of type "style" that we’ve decided we want:
+  # Opt-in rules of type "style" that we've decided we want:
   - attributes
   - closure_end_indentation
   - closure_spacing
@@ -64,7 +64,7 @@ opt_in_rules:
   - vertical_whitespace_closing_braces
   - vertical_whitespace_opening_braces
 
-  # Opt-in rules of type "idiomatic" that we’ve decided we want:
+  # Opt-in rules of type "idiomatic" that we've decided we want:
   - anonymous_argument_in_multiline_closure
   - convenience_type
   - fallthrough
@@ -76,7 +76,7 @@ opt_in_rules:
   - toggle_bool
   - xct_specific_matcher
 
-  # Opt-in rules of type "lint" that we’ve decided we want:
+  # Opt-in rules of type "lint" that we've decided we want:
   - array_init
   - empty_xctest_method
   - override_in_extension

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -36,8 +36,8 @@ To check formatting and code quality, run `swift run BuildTool lint`. Run with `
 - The aim of the [example app](README.md#example-app) is that it demonstrate all of the core functionality of the SDK. So if you add a new feature, try to add something to the example app to demonstrate this feature.
 - If you add a new feature, try to extend the `IntegrationTests` tests to perform a smoke test of its core functionality.
 - We should aim to make it easy for consumers of the SDK to be able to mock out the SDK in the tests for their own code. A couple of things that will aid with this:
-  - Describe the SDK’s functionality via protocols (when doing so would still be sufficiently idiomatic to Swift).
-  - When defining a `struct` that is emitted by the public API of the library, make sure to define a public memberwise initializer so that users can create one to be emitted by their mocks. (There is no way to make Swift’s autogenerated memberwise initializer public, so you will need to write one yourself. In Xcode, you can do this by clicking at the start of the type declaration and doing Editor → Refactor → Generate Memberwise Initializer.)
+  - Describe the SDK's functionality via protocols (when doing so would still be sufficiently idiomatic to Swift).
+  - When defining a `struct` that is emitted by the public API of the library, make sure to define a public memberwise initializer so that users can create one to be emitted by their mocks. (There is no way to make Swift's autogenerated memberwise initializer public, so you will need to write one yourself. In Xcode, you can do this by clicking at the start of the type declaration and doing Editor → Refactor → Generate Memberwise Initializer.)
 - When writing code that implements behaviour specified by the LiveObjects features spec, add a comment that references the identifier of the relevant spec item.
 - When writing methods that accept one of the public callback types (e.g. `LiveObjectUpdateCallback`), use the typealias name instead of the resolved type that Xcode fills in autocomplete; that is, write `LiveObjectUpdateCallback<LiveCounterUpdate>` instead of autocomplete's `(any LiveCounterUpdate) -> Void`.
 
@@ -112,11 +112,11 @@ func test3 { … }
 ```
 
 ```swift
-// @specPartial CHA-EX1h4 - Tests that we retry, but not the retry attempt limit because we’ve not implemented it yet
+// @specPartial CHA-EX1h4 - Tests that we retry, but not the retry attempt limit because we've not implemented it yet
 func test4 { … }
 ```
 
-You can run `swift run BuildTool spec-coverage` to generate a report about how many spec points have been implemented and/or tested. This script is also run in CI by the `spec-coverage` job. This script will currently only detect a spec point attribution tag if it’s written exactly as shown above; that is, in a `//` comment with a single space between each component of the tag.
+You can run `swift run BuildTool spec-coverage` to generate a report about how many spec points have been implemented and/or tested. This script is also run in CI by the `spec-coverage` job. This script will currently only detect a spec point attribution tag if it's written exactly as shown above; that is, in a `//` comment with a single space between each component of the tag.
 
 #### Marking a spec point as untested
 

diff --git a/Sources/AblyLiveObjects/.swiftformat b/Sources/AblyLiveObjects/.swiftformat
@@ -1,2 +1,2 @@
-# To avoid clash with SwiftLint’s explicit_acl rule
+# To avoid clash with SwiftLint's explicit_acl rule
 --disable redundantInternal
diff --git a/Sources/AblyLiveObjects/.swiftlint.yml b/Sources/AblyLiveObjects/.swiftlint.yml
@@ -1,3 +1,3 @@
 opt_in_rules:
-  # Opt-in rules of type "idiomatic" that we’ve decided we want:
+  # Opt-in rules of type "idiomatic" that we've decided we want:
   - explicit_acl
diff --git a/Sources/AblyLiveObjects/Utility/Logger.swift b/Sources/AblyLiveObjects/Utility/Logger.swift
@@ -2,7 +2,7 @@ internal import _AblyPluginSupportPrivate
 
 /// A reference to a line within a source code file.
 internal struct CodeLocation: Equatable {
-    /// A file identifier in the format used by Swift’s `#fileID` macro. For example, `"AblyChat/Room.swift"`.
+    /// A file identifier in the format used by Swift's `#fileID` macro. For example, `"AblyChat/Room.swift"`.
     internal var fileID: String
     /// The line number in the source code file referred to by ``fileID``.
     internal var line: Int

diff --git a/Sources/BuildTool/BuildTool.swift b/Sources/BuildTool/BuildTool.swift
@@ -128,7 +128,7 @@ struct GenerateMatrices: ParsableCommand {
     static let configuration = CommandConfiguration(
         abstract: "Generate a build matrix that can be used for specifying which GitHub jobs to run",
         discussion: """
-        Outputs a key=value string which, when appended to $GITHUB_OUTPUT, sets the job’s `matrix` output to a JSON object which can be used for generating builds. This allows us to make sure that our various matrix jobs use consistent parameters.
+        Outputs a key=value string which, when appended to $GITHUB_OUTPUT, sets the job's `matrix` output to a JSON object which can be used for generating builds. This allows us to make sure that our various matrix jobs use consistent parameters.
 
         This object has the following structure:
 
@@ -164,7 +164,7 @@ struct GenerateMatrices: ParsableCommand {
             ],
         ]
 
-        // I’m assuming the JSONSerialization output has no newlines
+        // I'm assuming the JSONSerialization output has no newlines
         let keyValue = try "matrix=\(String(data: JSONSerialization.data(withJSONObject: matrix), encoding: .utf8))"
         fputs("\(keyValue)\n", stderr)
         print(keyValue)
@@ -209,7 +209,7 @@ struct Lint: AsyncParsableCommand {
         try await ProcessRunner.run(executableName: "npm", arguments: ["run", "prettier:fix"])
     }
 
-    /// Checks that the Swift version specified by the `Package.swift`’s `"swift-tools-version"` matches that in the `.swift-version` file (which is used to tell SwiftFormat the minimum version of Swift supported by our code). Per [SwiftFormat#1496](https://github.com/nicklockwood/SwiftFormat/issues/1496) it’s currently our responsibility to make sure they’re kept in sync.///
+    /// Checks that the Swift version specified by the `Package.swift`'s `"swift-tools-version"` matches that in the `.swift-version` file (which is used to tell SwiftFormat the minimum version of Swift supported by our code). Per [SwiftFormat#1496](https://github.com/nicklockwood/SwiftFormat/issues/1496) it's currently our responsibility to make sure they're kept in sync.///
     func checkSwiftVersionFile() async throws {
         async let swiftVersionFileContents = loadUTF8StringFromFile(at: ".swift-version")
         async let packageManifestFileContents = loadUTF8StringFromFile(at: "Package.swift")
@@ -234,9 +234,9 @@ struct Lint: AsyncParsableCommand {
         }
     }
 
-    /// Checks that the SPM-managed Package.resolved matches the Xcode-managed one. (I still don’t fully understand _why_ there are two files).
+    /// Checks that the SPM-managed Package.resolved matches the Xcode-managed one. (I still don't fully understand _why_ there are two files).
     ///
-    /// Ignores the `originHash` property of the Package.resolved file, because this property seems to frequently be different between the SPM version and the Xcode version, and I don’t know enough about SPM to know what this property means or whether there’s a reproducible way to get them to match.
+    /// Ignores the `originHash` property of the Package.resolved file, because this property seems to frequently be different between the SPM version and the Xcode version, and I don't know enough about SPM to know what this property means or whether there's a reproducible way to get them to match.
     func comparePackageLockfiles() async throws {
         let lockfilePaths = ["Package.resolved", "AblyLiveObjects.xcworkspace/xcshareddata/swiftpm/Package.resolved"]
         let lockfileContents = try await withThrowingTaskGroup(of: Data.self) { group in
@@ -313,7 +313,7 @@ struct SpecCoverage: AsyncParsableCommand {
             init?(specLine: String) {
                 // example line that corresponds to a testable spec point:
                 // ** @(CHA-RS4b)@ @[Testable]@ Room status update events must contain the previous room status.
-                // (This `Testable` is a convention that’s being used only in the Chat spec)
+                // (This `Testable` is a convention that's being used only in the Chat spec)
 
                 let specPointLineRegex = /^\*+ @\((.*?)\)@( @\[Testable\]@ )?/
 
@@ -337,7 +337,7 @@ struct SpecCoverage: AsyncParsableCommand {
     }
 
     /**
-     * A tag, extracted from a comment in the SDK’s test code, which indicates conformance to a spec point, as described in the "Attributing tests to a spec point" section of `CONTRIBUTING.md`.
+     * A tag, extracted from a comment in the SDK's test code, which indicates conformance to a spec point, as described in the "Attributing tests to a spec point" section of `CONTRIBUTING.md`.
      */
     private struct ConformanceTag {
         enum `Type` {
@@ -448,7 +448,7 @@ struct SpecCoverage: AsyncParsableCommand {
         var testableSpecPointCoverages: [SpecPointCoverage]
 
         /**
-         * The IDs of spec points that are not marked as Testable but which have a conformance tag. We’ll emit a warning for these, because it might mean that the spec point they refer to has been replaced or deleted; might need to re-think this approach if it turns out there are other good reasons for testing non-testable points).
+         * The IDs of spec points that are not marked as Testable but which have a conformance tag. We'll emit a warning for these, because it might mean that the spec point they refer to has been replaced or deleted; might need to re-think this approach if it turns out there are other good reasons for testing non-testable points).
          */
         var nonTestableSpecPointIDsWithConformanceTags: Set<String>
 
@@ -624,12 +624,12 @@ struct SpecCoverage: AsyncParsableCommand {
             let headers = ["Spec point ID", "Coverage level", "Comments"]
 
             let rows = report.testableSpecPointCoverages.map { coverage in
-                // TODO: https://github.com/ably-labs/ably-chat-swift/issues/94 - Improve the output of comments. The Table library doesn’t:
+                // TODO: https://github.com/ably-labs/ably-chat-swift/issues/94 - Improve the output of comments. The Table library doesn't:
                 //
                 // 1. offer the ability to wrap long lines
                 // 2. handle multi-line strings
                 //
-                // so I’m currently just combining all the comments into a single line and then truncating this line.
+                // so I'm currently just combining all the comments into a single line and then truncating this line.
                 let comments = coverage.comments.joined(separator: ",")
 
                 let truncateCommentsToLength = 80
@@ -689,7 +689,7 @@ struct SpecCoverage: AsyncParsableCommand {
     }
 
     /**
-     * The response from GitHub’s [“get a commit” endpoint](https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#get-a-commit).
+     * The response from GitHub's ["get a commit" endpoint](https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#get-a-commit).
      */
     private struct GitHubCommitResponseDTO: Codable {
         var sha: String
@@ -769,12 +769,12 @@ struct SpecCoverage: AsyncParsableCommand {
             var name: String
 
             /**
-             * The path of this target’s sources, relative to ``PackageDescribeOutput/path``.
+             * The path of this target's sources, relative to ``PackageDescribeOutput/path``.
              */
             var path: String
 
             /**
-             * The paths of each of this target’s sources, relative to ``path``.
+             * The paths of each of this target's sources, relative to ``path``.
              */
             var sources: [String]
         }
@@ -783,7 +783,7 @@ struct SpecCoverage: AsyncParsableCommand {
     }
 
     /**
-     * Fetches the absolute file URLs of all of the source files for the SDK’s tests.
+     * Fetches the absolute file URLs of all of the source files for the SDK's tests.
      */
     private func fetchTestSourceFilePaths() async throws -> [URL] {
         let packageDescribeOutputData = try await ProcessRunner.runAndReturnStdout(
@@ -811,7 +811,7 @@ struct BuildDocumentation: AsyncParsableCommand {
     )
 
     mutating func run() async throws {
-        // For now, this is intended to just perform some validation of the documentation comments. We’ll generate HTML output in https://github.com/ably/ably-chat-swift/issues/2.
+        // For now, this is intended to just perform some validation of the documentation comments. We'll generate HTML output in https://github.com/ably/ably-chat-swift/issues/2.
 
         try await ProcessRunner.run(
             executableName: "swift",
@@ -829,7 +829,7 @@ struct BuildDocumentation: AsyncParsableCommand {
                 // - a table at the end of the CLI output
                 // - as a JSON file in ./.build/plugins/Swift-DocC/outputs/AblyLiveObjects.doccarchive/documentation-coverage.json
                 //
-                // I do not yet know how to make use of these (there’s all sorts of unexpected symbols that we didn’t directly declare there, e.g. `compactMap(_:)`), but maybe it’ll be a bit helpful still.
+                // I do not yet know how to make use of these (there's all sorts of unexpected symbols that we didn't directly declare there, e.g. `compactMap(_:)`), but maybe it'll be a bit helpful still.
                 "--experimental-documentation-coverage",
 
                 // Increases the detail level of the aforementioned coverage table in CLI output.

diff --git a/Sources/BuildTool/DestinationFetcher.swift b/Sources/BuildTool/DestinationFetcher.swift
@@ -11,7 +11,7 @@ enum DestinationFetcher {
         let matchingDevices = (simctlAvailableDevicesOutput.devices[runtimeIdentifier] ?? []).filter { $0.deviceTypeIdentifier == deviceTypeIdentifier }
 
         guard !matchingDevices.isEmpty else {
-            throw Error.simulatorLookupFailed(message: "Couldn’t find a simulator with runtime \(runtimeIdentifier) and device type \(deviceTypeIdentifier); available devices are \(simctlAvailableDevicesOutput.devices)")
+            throw Error.simulatorLookupFailed(message: "Couldn't find a simulator with runtime \(runtimeIdentifier) and device type \(deviceTypeIdentifier); available devices are \(simctlAvailableDevicesOutput.devices)")
         }
 
         guard matchingDevices.count == 1 else {

diff --git a/Sources/BuildTool/ProcessRunner.swift b/Sources/BuildTool/ProcessRunner.swift
@@ -4,7 +4,7 @@ import Foundation
 enum ProcessRunner {
     private static let queue = DispatchQueue(label: "ProcessRunner")
 
-    // There’s probably a better way to implement these, which doesn’t involve having to use a separate dispatch queue. There’s a proposal for a Subprocess API coming up in Foundation which will marry Process with Swift concurrency.
+    // There's probably a better way to implement these, which doesn't involve having to use a separate dispatch queue. There's a proposal for a Subprocess API coming up in Foundation which will marry Process with Swift concurrency.
 
     static func run(executableName: String, arguments: [String]) async throws {
         try await withCheckedThrowingContinuation { (continuation: CheckedContinuation<Void, _>) in