Remove alternative install options

[dplewis]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Additional installation methods are outdated and causes a lot of overhead on development. With the removal of CocoaPod and Carthage the focus should be on SPM only. The current CI takes ~40 minutes. Integration testing doesn't exist. The release build can't compile on XCode 14 without removing arm64 support or converting to release build to xcframework.

Feature / Enhancement Description

• Update iOS Guide get started instructions
• Update README installation instructions
• Update Contributing Guide for running Starter Projects and using SPM for integration testing.
• Remove Release Assets from CI
• Use SPM in Starter Projects
• Remove Xcode 11 and macos-11 from CI

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

Continuing the discussion from #1741 (comment) here.

Above you wrote:

The release build can't compile on XCode 14 without removing arm64 support or converting to release build to xcframework.

What is the motivation to remove the assets? In other words, if we keep the assets, what's the implication? If the implication is more severe, then I'd suggest we remove the assets for now. The majority of developers doesn't need the assets I believe. If we later find a significant demand for assets we can look into how to add them, but this shouldn't stop the further SDK development.

[dplewis]

What is the motivation to remove the assets?

Should the CI ensures the project builds, compiles and test run or build a framework for release? We also build a Bolts-Objc framework for release too.

If we later find a significant demand for assets we can look into how to add them

If this happens we should handle assets properly. Converting the universal FAT framework into a xcframework and release it under SPM as a binaryTarget. I haven't tested the existing assets on Apple Silicon yet.

this shouldn't stop the further SDK development

The main goal is to get the CI down to 5-10 minutes. This project needs a lot of cleanup to get there. A quicker development cycle would be helpful for both review and running the project locally.

[dplewis]

@mtrezza We can close this. I have an idea to reduce CI times without removing the assets. We add building the StarterProjects to the CI. This is the best way to build and ensure the code works. The release build and releasing of assets should be handled in release-automated.yml.

[mtrezza]

But this issue was broader than only assets, right? We'd still want to remove relicts from Cocoapods, Carthage, etc? Also, if we cannot upgrade the CI and Xcode tests to newer Xcode versions, we'll have a problem soon. The CI runs on an old Xcode version and we'll soon loose support; I believe the CI currently runs on the oldest macOS runner that is still provided by GitHub Actions, because of the old Xcode version we need. Once that runner becomes unavailable we are in trouble. So if we can upgrade this, and have to remove the assets, I think it's a worthy tradeoff.

So this issue is about more than only the CI run time. I took the liberty to re-open, so we can decide on how to proceed.

[dplewis]

Also, if we cannot upgrade the CI and Xcode tests to newer Xcode versions, we'll have a problem soon.

Technically there should be a problem now as Swift 5.5 isn't installed on older version of Xcode.

xcodebuild: error: Could not resolve package dependencies:
  package at '/Users/runner/work/Parse-SDK-iOS-OSX/Parse-SDK-iOS-OSX' is using Swift tools version 5.5.0 but the installed version is 5.2.0

[dplewis]

@mtrezza Now that you understand the situation how do you want to proceed?

[mtrezza]

If you confirm that my interpretation is correct, then I'd say let's drop assets and upgrade as much as possible. The argument for this is that if we don't upgrade now, every developer using the SDK will be affected, not just the ones using the assets, which I assume is a minority. So I'd choose the less impactful path going forward. If there are developers who require the assets who cannot switch to SPM, we'd need to look for a solution later on.

[dplewis]

Sounds good, I'll finish my checklist