Extract SpeziConsent from SpeziOnboarding

[pauljohanneskraft]

Extract SpeziConsent from SpeziOnboarding

♻️ Current situation & Problem

SpeziOnboarding contains mostly consent related information, this PR extracts that code into its own target, so that it can be separately linked on demand.

⚙️ Release Notes

• Extract SpeziConsent into its own target

📚 Documentation

Please ensure that you properly document any additions in conformance to Spezi Documentation Guide.
You can use this section to describe your solution, but we encourage contributors to document your reasoning and changes using in-line documentation.

✅ Testing

Please ensure that the PR meets the testing requirements set by CodeCov and that new functionality is appropriately tested.
This section describes important information about the tests and why some elements might not be testable.

📝 Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[PSchmiedmayer]

Thank you for the improvements; I like the separation @pauljohanneskraft!
I had a few comments along the way. The major element would be to explore if the changes could even be structured in a way that they are backward compatible as described in the comments.

Apart from this I am happy to see this merged once the comments are resolved; let me know if you have any follow-up questions.

[philippzagar]

@pauljohanneskraft Just wanted to follow up on this PR: Would be great to get this merged soon (if the PR is not combined with some larger changes, e.g. moving functionality out from Onboarding to Views), looks like a great split-up to me! 🚀

[PSchmiedmayer]

Agree with @philippzagar; wondering what the best order or merges between #52 #58 and this PR is? I would leave it up to you @philippzagar to identify a best order but it seems like all of them are close to be merged and might need a few pushed to get them across the finish line. I suspect that we will need to tag a major release anyways (we should old off on this a bit after the PRs are merged but can tag beta tags) as we might also use them to properly split up the targets as breaking changes & even remove some of the older constraints.

[philippzagar]

Agree with @philippzagar; wondering what the best order or merges between #52 #58 and this PR is?

I would definitely go for #58 first, then probably #52 and this PR last (resolving quite some conflicts within this PR/branch then).
I think that this order should minimize conflict in total. 🚀

[philippzagar]

I suspect that we will need to tag a major release anyways (we should old off on this a bit after the PRs are merged but can tag beta tags) as we might also use them to properly split up the targets as breaking changes & even remove some of the older constraints.

I agree that we'll need a major release version bump when all of these PRs are merged.
@PSchmiedmayer As we'll need a major release version either way, should we directly aim to extract some onboarding functionality (like the 'OnboardingStack') to SpeziViews before tagging the new version? I think we'll perform this extraction at some point or another, so it might make sense to do it right away and combine it with this breaking major release.

[PSchmiedmayer]

Sounds good. #52 should be ready to be merged, all the tests are passing and it resolves some of the visionOS test issues that we see in #58. Wondering if we should reverse that order as #52 is also an external PR & we might not want to drag out additional development in the fork for a longer time?

I think extracting the OnboardingStack would make sense; it could be generalized beyond its onboarding use case and could be useful in a few other places as well 👍

[philippzagar]

Sounds good. #52 should be ready to be merged, all the tests are passing and it resolves some of the visionOS test issues that we see in #58. Wondering if we should reverse that order as #52 is also an external PR & we might not want to drag out additional development in the fork for a longer time?

Sounds good, then I'll do a final review of #52 and merge it soon! After that, I'll go for #58.

[philippzagar]

I think extracting the OnboardingStack would make sense; it could be generalized beyond its onboarding use case and could be useful in a few other places as well 👍

Sounds good, I'll create an issue for that and will tackle it soon!

[PSchmiedmayer]

Sounds amazing; thank you @philippzagar!

[philippzagar]

I think extracting the OnboardingStack would make sense; it could be generalized beyond its onboarding use case and could be useful in a few other places as well 👍

@PSchmiedmayer Created a small issue and assigned it to myself: #61

[PSchmiedmayer]

Thank you 👍

[pauljohanneskraft]

If we are to actually make a major release anyways, should we maybe revert that change that inverts the dependencies of SpeziConsent and SpeziOnboarding? Then, some apps would need to adapt their Package.swift file to include SpeziConsent, as they would otherwise not be able to access that part of the code anymore, but it would further not include the dependency for current users of SpeziOnboarding that don't rely on it. @PSchmiedmayer @philippzagar

[PSchmiedmayer]

Agree, we can split the targets on the Package.swift level with a major release; would be fine with me + would probably also be nice to avoid building the PDF framework if one only wants to use the simple onboarding views.