This repository has been archived by the owner on Feb 27, 2019. It is now read-only.
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.
This is an attempt to fix issue: #194
It is modeled after this solution used by a similar framework: https://github.com/iosphere/ISHPermissionKit/pull/80/files
In short, the problem is that the framework imports all libraries necessary for all permissions it supports (camera, location, bluetooth, etc), and any app using this library will get automatically rejected if they do not provide ALL plist descriptions - even for the permissions they are not requesting within their app.
The solution is to hack around with subspecs to define flags that will signal the pod which libraries to import.
The TODO found in this PR illustrates a potential problem with this solution and also the reason why a project using this pod won't build. Swift does not allow you to put #if #endif around switch cases. This is a documented bug: https://bugs.swift.org/browse/SR-2
A workaround for this, proposed by Ying is:
Another solution is to break each permission into it's own framework. This morning the main repo owner replied to me and said that this would be the right way to go.
Ying supports going the "ThingDetail" struct route. But after hearing from the repo owner, I think trying to break this into separate frameworks should be the route - as this would be the one he would like to merge in the end.