Remove `.xcodeproj`, drop carthage support, Use `swift build` in Github workflow

[ben-xD]

Background

As part of adding SPM support, a Package.swift was added to Ably cocoa, allowing Xcode projects and other swift packages to easily add Ably as a dependency. Swift packages are separate entities to Xcode projects, and do not co-exist with Xcode projects very well:

• Xcode can already open a Swift Package, but you won't use project tabs (e.g. Build phases, build settings, Summary/ build configuration, etc). This is better, because configuration does not live in XML/ Xcode files anymore.
• Changes to the Xcode project will not be reflected in the Package.swift, and so we have to sources of configuration which can diverge in the future.
• Finally, the swift package generate-xcodeproj has been deprecated, which was previously used to generate an ephemeral Xcode project based on the Package.swift so that you can still open the Swift Package as a Xcode project. It no longer has the updates.

Tasks:

In @lukasz-szyszkowski's PR, we are keeping the Ably.xcodeproj temporarily to avoid making too many changes. But these changes should happen soon to avoid developer confusion:

• Delete Ably.xcodeproj, relying solely on Package.swift for configuration (and other automatically generated files .swiftpm). Xcode schemes are autogenerated based on the Package.swift.
  • This will actually drop support for Carthage, because Carthage uses the shared schemes within .xcodeproj to build the output framework. Therefore, we can delete a lot of carthage related files (Cartfile/ .resolved), lines related to updating carthage dependencies in the .github yaml. We can remove references from Carthage.
  • We would need to update the CI (Github Workflow) to use swift build instead of xcodebuild, or modify existing xcodebuild code to automatically use the autogenerated schemes from Package.swift.
  • This will not drop support for Cocoapods
• Update documentation (README, contributing.md, github releases to say “this is the last carthage release) to remove all references to Carthage.

[lawrence-forooghian]

@QuintinWillison @AndyNicks I'm here after looking at #1070. Do we know whether we'd like to proceed with removing Carthage? Do we have a sense of how disruptive this would be to users of the library?

[QuintinWillison]

I've had a quick look through all issues mentioning 'carthage', where most of those only mention it because we were using an issue template that pretty much every issue creator said 'No' to the question 'Are you using Carthage?'.

There is no way, that I'm aware of, for us to get any metrics around use of this SDK via Carthage as it uses GitHub as the natural distribution platform innately.

Ideally I would have us drop Carthage support in a minor, perhaps major, version bump - however, the work to progress us towards enabling that versioning freedom for all SDKs has not yet been completed. I also know that keeping Carthage in the mix is holding this codebase back from a maintainability standpoint.

I think we should proceed with removing Carthage from this codebase now and accept the risk that we'll be doing this as part of a patch version bump, which may well attract complaint from developers who are bringing this SDK in via that route.

What will put us in a good place to handle those complaints will be for any work that is done to remove Carthage under this issue to also include some documentation describing any hints or steps they can go thru in order to put our preferred replacement in place (presumably, SPM).

[lawrence-forooghian]

Just happened to be passing by here - one thing to mention is that we should probably do this as a few separate pieces of work (for ease of review):

1. Come up with another process for building a binary version of ably-cocoa for people who don't want to use a package manager to install it
2. remove Carthage support
3. add ability to run the tests using swift test(this might actually need to come first, since Nimble, which is a dependency of our test suite, is currently brought in using Carthage)
4. remove the .xcodeproj