I have a custom, built, private CocoaPod that I wrote. I'm trying to use it in my iOS application, which works fine. But when I add the iMessage App or Share Extension, it fails and gives me an error
"shared" is unavailable: use display management-based solutions where appropriate instead. when I try to use
My first thought on how to fix this was to add a Swift Flag
IN_EXTENSION or something like that. Then pack the code in a block
The problem is the goal of the CocoaPod source, is in some kind of framework. The source is not part of the app or extensions directly. Then you add that flag doesn't really help.
Below is an example of my Podfile.
source & # 39; https: //github.com/CocoaPods/Specs.git' source & gt; email@example.com: CUSTOMORG / Private-CocoaPods-Spec.git & # 39; platform: ios, & # 39; 9.0 & # 39; use_frameworks! inhibit_all_warnings! Goal & # 39; MyApp & # 39; makes pod & # 39; MyCustomSwiftPackage & # 39 ;, & # 39; 1.0.0 & # 39; end goal & # 39; MyApp Share Extension & # 39; makes pod & # 39; MyCustomSwiftPackage & # 39 ;, & # 39; 1.0.0 & # 39; end
If I comment on the line
pod & # 39; MyCustomSwiftPackage & # 39 ;, & # 39; 1.0.0 & # 39; under
MyApp Share Extension works well.
I need this package in my extension tho.
I plan on writing a separate pod that only handles the
UIApplication.shared logic and adds it to
MyApp . But it seems like a real pain. Especially since I'm not aware of a way to distribute 2 CocoaPods in one project that rely on the same source files.
If it's the only solution, it seems almost better to use Git Submodules and get the source directly in the app, so I can get it to some of those goals directly, and
#if should work then . Problems with that are that the addictions to CocoaPod would not be handled if I use Git Submodules. So I really have to use CocoaPods somehow.
I prefer a simple solution that does not feel as lucky as those. So is there a better way to deal with this and fix that error without resorting to writing about a TON code and is not a super hacky solution?
In the comments it was mentioned using
UIApplication.perform . Problem with it is that if Apple ever changes the API, the code will break even for previous versions of the application, as it is called dynamic without the API's future proofing. Although this solution sounds easy, it seems like a very bad decision.