ci: Remove publishing release assets

[dplewis]

New Pull Request Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am creating this PR in reference to an issue.

Issue Description

Removes publishing release assets from release. Users are still able to compile these assets themselves on Xcode < 14.

Closes: https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1740

Approach

• Remove assets from CI
• Update README instructions
• Remove zipping starter projects as they can be downloaded direcly from github

TODOs before merging

• [x] Add tests
• [x] Add changes to documentation (guides, repository pages, in-code descriptions)

[parse-github-assistant[bot]]

Thanks for opening this pull request!

• 🎉 We are excited about your hands-on contribution!

[codecov[bot]]

Codecov Report

All modified lines are covered by tests :white_check_mark:

Comparison is base (7be78ba) 64.41% compared to head (ba5f404) 64.42%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1745 +/- ## ======================================= Coverage 64.41% 64.42% ======================================= Files 200 200 Lines 23177 23177 ======================================= + Hits 14929 14931 +2 + Misses 8248 8246 -2 ``` [see 1 file with indirect coverage changes](https://app.codecov.io/gh/parse-community/Parse-SDK-iOS-OSX/pull/1745/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=parse-community)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[dplewis]

This is ready for merge

[parseplatformorg]

🎉 This change has been released in version 2.7.2

[JohnCaccavale]

@dplewis @mtrezza after reviewing the conversation within PR #1741 I'm still not sure what exactly the motivation was to remove the assets following the 2.7.1 release of the framework. Issues with the GitHub actions?

I found having the Release assets very convenient. Especially in my current project where it is the only dependency, it's nice and simple to just download say the Parse-macOS.zip file, and just move the Parse.framework where it needs to go. In my case, keeping a copy of Parse.framework in the /Library/Frameworks directory as my app is a Command Line app.

If removing the convenience of including the compiled builds from the asset section of the Release, then let's at least include some documentation as to what the best way would be to create this assets on our own. Seems like relevant documentation for manually compiling the SDK has also been removed from the README.md. Why?

[JohnCaccavale]

At the very least, maybe just publish Parse-iOS, Parse-macOS, Parse-tvOS and Parse-watchOS? Other assets that were being included such as the start projects, I'm not sure how much value it was to include those.

[dplewis]

@JohnCaccavale The main reason is because we only support installing via Swift Package Manager. Also the release assets couldn't compile on XCode 14+.

It's highly recommend using SPM over a static framework.

[JohnCaccavale]

Also the release assets couldn't compile on XCode 14+.

But we're on Xcode 15 now, why do we care about Xcode 14?

It's highly recommend using SPM over a static framework.

But I need to keep a copy of the framework in my /Library/Frameworks directory. SPM does me no good in any case and is more of an inconvenience. I shouldn't have to use a dependency manager, when there's literally just one dependency (Parse) in my project.

[dplewis]

But we're on Xcode 15 now, why do we care about Xcode 14?

Xcode 14+ meaning every version after 14 including 15. Feel free to try to get it to work. Warning this was an issue for years.

I shouldn't have to use a dependency manager

It's standard convention. Just give it a try after all it's just one dependency.

[JohnCaccavale]

Yes I've used Swift Package Manager, as I manage an SDK at my day job which I deploy via SPM. I've also spent my fair share of time in WWDC labs with members of that team working around some of the initial warts.

It's not that I don't want to use a dependency manager, it's the fact that in this case I still need to include the framework in /Library/Frameworks. So what value does setting up SPM serve when I still need to manually compile the framework?

I'm fine with manually building the framework, but at the very least let's include some documentation in the README on doing such, so one easily knows what command to run, etc. What would your recommendation be on that?

[dplewis]

@JohnCaccavale Can you create a new issue for this? I don't want this conversation to get lost.

The reason why this doesn't compile for XCode 14+ is because universal frameworks .xcframework replaced .framework.

I actually started working on this a while ago. You can try this makefile

https://github.com/dplewis/Parse-SDK-iOS-OSX/blob/universal-binary/Makefile

[JohnCaccavale]

@dplewis I'd be glad to take a look, I believe I have some notes regarding this laying around somewhere in my office. At work, I am building an XCFramework, being deployed as a referenced binary via SwiftPM from a private Git repo. I'll check my notes and look through that Makefile.

I'm currently dealing with another issue at the moment, I am seeing similar behavior as reported in this Issue currently, https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1771 which I'm in the process of trying to figure out whats going on.

[JohnCaccavale]

@dplewis my apologies for being a bit slow today. I just realized, if I statically link Parse to my command line utility, then that eliminates the need for having to keep the compiled version of the Parse Framework in the /Library/Frameworks directory. With that said, I cleaned up my project and settings, added Parse via the SPM, built and Archived a Release variant and all works well. I myself no longer have any need for the assets on the release page.

[dplewis]

@JohnCaccavale No problem, I'm glad you got it working.