-
Notifications
You must be signed in to change notification settings - Fork 732
Use runtime check for app extensions instead of PURELAYOUT_APP_EXTENSIONS macro #252
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
Use runtime check for app extensions instead of PURELAYOUT_APP_EXTENSIONS macro #252
Conversation
2ebf640 to
3ae7347
Compare
94b5d1b to
32510f9
Compare
|
While you're at it, you should enable "Allow app extension only API" so projects using this fwk in extensions won't display an extra warning. |
|
@pallzoltan allowing the app extension only API makes sense to my understanding but I don't quite believe the check to With this I would say it is safe in its usage unless you feel there is a need that the call to |
|
I think you're reading the AppKit documentation. This block of code you've changed is wrapped in |
Can you elaborate please? I am not sure I understand what part of code you refer to, or maybe to external configuration, please point me where. I am using CocoaPods so maybe we can add that flag to pod spec?
App extensions can't access |
It's just a flag (in Xcode UI it's under General). Checking this box makes the framework safe to use in an extension. Basically you're saying that you're not calling unsafe API from the extension (such as
It's more of a safety net after the "appex" extension check. If that ever changes (maybe a new target type which isn't an extension per se), it would catch any calls to a method that might not exist. |
|
@pronebird Any luck updating this PR? |
|
@pallzoltan I don't know how to implement what you suggest. Feel free to open a follow up PR. |
|
If you merge my PR, we're ready to rumble .) |
|
@pallzoltan nice! I have merged your commit into the PR's branch. |
|
@mickeyreiss Would you be so kind and re-trigger Travis and have a look at this PR? |
|
@pallzoltan the Travis build is failing due to Slather's argument option changes. I'm going to update it separately via the .yml file and get this merged in once the build is passing again. Edit: Once PR #254 is merged in, I'll get this one taken care of. |
|
@pallzoltan you can choose to rebase on top of the master branch now and it should resolve the CI build test. |
|
cc @pronebird, thanks @toohotz |
57687f9 to
53dd24c
Compare
|
@toohotz @pallzoltan I have rebased the PR & it should be ready to go. |
|
Great, I'd merge this but don't have write access, maybe @toohotz can. |
|
Merged it for you. |
@lwdupont Could you do a v3.1.8 release? I'd send a PR but can't create the tag. |
|
@pallzoltan no worries, just released it. |
|
@toohotz seems like you forgot to release on CocoaPods. |
|
@pronebird Just released it a few minutes ago, sorry about that. @toohotz if you want me to add you to the cocoapods.org group who can release, let me know? (or are you in the list?) |
|
@lwdupont feel free to add me on, don't believe I currently have access. 👍🏾 |
|
@toohotz I added you with the email github lists on your last checking (g----x@gmail.com) . That the correct one? You should have access now according to cocoapods. |


Should solve #245 and remove the requirement to have
PURELAYOUT_APP_EXTENSIONSdefined to use PureLayout in app extensions.The reason why I resort to runtime check boils down to the fact that
@available(iOSApplicationExtension 8.0, *))didn't work as expected:sharedApplicationis unavailable.if (@available(iOSApplicationExtension 8.0, *)) {even though it looks like they run as normal apps.Based on my tests, application extensions have
appexextension. Masking the call tosharedApplicationhelps to avoid the compilation error.Further thoughts:
I think that leveraging
UIViewto determine the effective layout direction is probably a better way to solve that, we have a common superview which can be used for that.