Require only app-extension-safe APIs #267
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rive-engineering
pushed a commit
that referenced
this pull request
Aug 7, 2023
Contribution from downstream: #267 Not really sure what to test here - but ran the example app on a sim and on a local iPhone and seems alright (We'll merge this after testing if we can create a patch to `v4.0.6`) Diffs= 354b04ea7 Require only app-extension-safe APIs (#5747) Co-authored-by: Matt LaRose <larose@duolingo.com> Co-authored-by: Zachary Plata <plata.zach@gmail.com>
|
Thanks for contributing this! We've patched this from an upstream repo and this has landed in |
rive-engineering
pushed a commit
that referenced
this pull request
Sep 13, 2023
Adds event bindings for iOS/macOS **Caveat:** tl;dr We may have to explicitly make app owners open URLs for `OpenUrlEvent`, rather than doing it implicitly Recently, there was a [request for a specific change](#267) to mark `RiveRuntime` package as using application-extension-safe in terms of API usge. This allows RiveRuntime to be used in places other than apps in the Apple ecosystem, which they needed, so that Apple doesn't flag their apps negatively in App Store submissions. Because we mark this setting in build settings for our package, this means we can't use a specific API to access `UIApplication`, which is needed to open URLs from our side (i.e. `UIApplication.shared.open(url)`), thus not allowing us to _directly_ open URLs on `OpenUrlEvent`. Couldn't find a way around this unfortunately, so the onus on opening the URL will be on the consumer when they listen for this event. Diffs= b47ff1523 feature: Add Rive Event bindings to iOS runtime (#5899) Co-authored-by: Zachary Plata <plata.zach@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
tl;dr: Marks Rive library as safe, to prevent potential App Store rejection.
If an app extension (e.g., a widget) depends on Rive, when you build your app you'll be warned that you're
Linking against a dylib which is not safe for use in application extensions. Apple may reject the app for this.A library is safe for application extensions if
APPLICATION_EXTENSION_API_ONLY = YES.Right now,
APPLICATION_EXTENSION_API_ONLYis unspecified in Rive, but Rive is only using APIs that are safe for app extensions. Since Rive is safe, I marked it as safe. If an unsafe API is ever used in the future, Xcode will generate errors. I'd guess that given the usual unsafe APIs, this seems unlikely ever to be a problem for Rive.I didn't see some project file management setup, so I edited the
.pbxprojdirectly.