-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require Xcode 16 #21
Labels
enhancement
New feature or improved functionality.
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Aug 22, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21.
lawrence-forooghian
added a commit
that referenced
this issue
Aug 22, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21.
lawrence-forooghian
added a commit
that referenced
this issue
Aug 22, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21.
lawrence-forooghian
added a commit
that referenced
this issue
Aug 24, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21. I’ve also implemented MessageSubscription by wrapping Subscription.
lawrence-forooghian
added a commit
that referenced
this issue
Aug 24, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21. I’ve also implemented MessageSubscription by wrapping Subscription.
lawrence-forooghian
added a commit
that referenced
this issue
Aug 24, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21. I’ve also implemented MessageSubscription by wrapping Subscription.
lawrence-forooghian
added a commit
that referenced
this issue
Aug 24, 2024
Note that XCTAssertEqual doesn’t allow you to write `await` inside its arguments, hence the indirection to get the result of a couple of `async let`s. Hopefully we’ll be able to migrate to Swift Testing at some point, which will resolve this; see #21. I’ve also implemented MessageSubscription by wrapping Subscription.
This was referenced Sep 18, 2024
Closed
lawrence-forooghian
added a commit
that referenced
this issue
Sep 18, 2024
This means: - using it for development (which will allow us to use Swift Testing, which we’ll do in #55) - requiring users of the library to use it (so that we can use Swift 6 features, which we’ll do in #56) — we’ve decided we’re happy to do this since from April 2025 Apple will force users wishing to upload to the App Store to use it anyway Whilst implementing this, I decided to revisit my comment from 646c220: > I haven’t committed the `.swiftpm/configuration/Package.resolved` file > created by Xcode 16. We already have two Package.resolved files (see the > `comparePackageLockfiles` lint task) and so let’s wait for Xcode 16 to > be released to see whether this file is going to stick around (perhaps > it will become part of the .gitignore created by the SPM that ships with > Xcode 16). With the release version of Xcode 16, I am no longer able to get Xcode to generate this file, so either they changed something or it’s going to reappear at some point when we poke Xcode in some very specific way (at which point we can decide what to do with it). Resolves #21.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've decided (internal Slack thread) to require Xcode 16 and above.
Package.swift
files--swift-version
flags in our build tooling.swiftpm/configuration/Package.resolved
(see 646c220)I suggest that we also only build the example app with Swift 6 so that we can use Swift 6’s features in it.
Next, we’ll do #56.
┆Issue is synchronized with this Jira Story by Unito
The text was updated successfully, but these errors were encountered: