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

Xcode13-beta3 Fix #713

Merged
merged 3 commits into from
Jul 20, 2021
Merged

Xcode13-beta3 Fix #713

merged 3 commits into from
Jul 20, 2021

Conversation

scannillo
Copy link
Contributor

Background

GitHub Issue

XCode 13-beta3 release notes call out the following change:

Linking Swift packages from application extension targets or watchOS applications no longer emits unresolvable warnings about linking to libraries not safe for use in application extensions. This means that code referencing APIs annotated as unavailable for use in app extensions must now themselves be annotated as unavailable for use in application extensions, in order to allow that code to be used in both apps and app extensions. (66928265)

Changes

In places that we use Apple APIs which aren't usable in App Extensions (UIApplication.sharedApplication) we need to explicitly mark these methods as not usable for App Extensions.

Resources

Checklist

  • Added a changelog entry

Authors

@scannillo

@scannillo scannillo requested a review from a team as a code owner July 19, 2021 19:48
@scannillo scannillo merged commit 89912f4 into master Jul 20, 2021
@sarahkoop
Copy link
Contributor

I'm not super familiar with App Extensions... do we think this is something an iOS developer / merchant would assume is supported in an iOS SDK unless explicitly stated that we don't support? I'd lean towards the workaround to prevent breaking anything if any merchants are using those modules in App Extensions. And maybe next major version stating explicitly whether we support them or not going forward. But if you think App Extension support is not assumed I could see the case for this simpler annotation fix.

@scannillo
Copy link
Contributor Author

I'm not super familiar with App Extensions... do we think this is something an iOS developer / merchant would assume is supported in an iOS SDK unless explicitly stated that we don't support? I'd lean towards the workaround to prevent breaking anything if any merchants are using those modules in App Extensions. And maybe next major version stating explicitly whether we support them or not going forward. But if you think App Extension support is not assumed I could see the case for this simpler annotation fix.

Sorry, I deleted my prior comment since I realized I had misspoke. So, even before adding these annotations, these methods wouldn't compile for an App Extension, since they're using APIs unavailable to App Extensions. So in that case - I think adding these annotations would make no difference to a merchant trying to use these modules in an App Extension. Given that - these changes feel OK to me.

I like your idea of taking a more formal stance on our support for App Extensions in future versions.

Let me know if that makes sense @sarahkoop.

@ghost
Copy link

ghost commented Jul 20, 2021

@scannillo What's the next step with this? Are you releasing the fix anytime now from the foregoing?

@scannillo
Copy link
Contributor Author

Hey @gobera - yup, we should be able to get this released by the end of the week.

@scannillo
Copy link
Contributor Author

@gobera - I am curious, are you blocked on this by braintree_ios or braintree-ios-drop-in?

@scannillo scannillo deleted the fix-xcode-13-beta3 branch November 4, 2022 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants