Skip to content
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

Closed
lawrence-forooghian opened this issue Aug 22, 2024 · 0 comments · Fixed by #58
Closed

Require Xcode 16 #21

lawrence-forooghian opened this issue Aug 22, 2024 · 0 comments · Fixed by #58
Assignees
Labels
enhancement New feature or improved functionality.

Comments

@lawrence-forooghian
Copy link
Collaborator

lawrence-forooghian commented Aug 22, 2024

We've decided (internal Slack thread) to require Xcode 16 and above.

  • switch CI to use Xcode 16 release version
  • remove the multiple Package.swift files
  • remove the --swift-version flags in our build tooling
  • revisit whether to commit Xcode 16’s .swiftpm/configuration/Package.resolved (see 646c220)
  • switch example app Xcode project to use folders

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 Task by Unito

@lawrence-forooghian lawrence-forooghian added the enhancement New feature or improved functionality. label Aug 22, 2024
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.
@lawrence-forooghian lawrence-forooghian self-assigned this Sep 17, 2024
@lawrence-forooghian lawrence-forooghian changed the title Consider switching to Swift 6 once Xcode 16 is released Require Xcode 16 Sep 18, 2024
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
Labels
enhancement New feature or improved functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant