Repository navigation
Linker warnings: "not safe for use in application extension" #292
Description
Once #281 is resolved, we will have the following linker warnings:
ld: warning: linking against a dylib which is not safe for use in application extensions: /Users/bharat/local/Loop/Carthage/Build/iOS/LoopKit.framework/LoopKit
ld: warning: linking against a dylib which is not safe for use in application extensions: /Users/bharat/local/Loop/Carthage/Build/iOS/GlucoseKit.framework/GlucoseKit
ld: warning: linking against a dylib which is not safe for use in application extensions: /Users/bharat/local/Loop/Carthage/Build/iOS/MinimedKit.framework/MinimedKit
ld: warning: linking against a dylib which is not safe for use in application extensions: /Users/bharat/local/Loop/Carthage/Build/iOS/InsulinKit.framework/InsulinKit
They don't seem to cause actual problems (I've been running this code live on my device for the past 5+ days with no issue). We will likely have to go upstream and make some changes to the frameworks to make them safe to use in extensions.
Since those frameworks are in 2 places, I'm creating this as a tracking issue. Once this change is accepted we can fork this into an issue in both LoopKit/LoopKit and ps2/rileylink_ios to resolve the upstream issues.
Activity
loudnate commentedon Dec 2, 2016
While you don't see problems in your Debug build, there might be issues for individuals who install from Release/TestFlight builds. I would strongly caution against those warnings making it to the master branch.
The issue is that the frameworks you're linking against aren't restricted to Extension-only API. I think it's best that the extension doesn't know about the existence of those frameworks, and that a View-Model abstraction layer be created instead.
loudnate commentedon Dec 2, 2016
To be clear, I don't think the right solution is to make each of those existing frameworks extension-safe.
Remove unnecessary imports and frameworks to minimize exposure to
bharat commentedon Dec 2, 2016
Thanks for the feedback, Nate.
I've removed some unncessary imports in f40050 that should reduce our exposure, but the StatusExtensionContext class still needs to know about ReservoirValue from InsulinKit, and GlucoseValue from LoopKit.
Nate, I'm happy to follow your lead here, but it's unclear to me what you're suggesting. Can you go into a little more detail about what you mean by a View-Model abstraction layer? Some things I've considered:
Can you explain in more detail what you think is the right approach here? thanks!
loudnate commentedon Dec 2, 2016
My suggestion is to remove the view's understanding of those framework types altogether by creating a new set of protocols/structs that define only what's needed for presentation in the views.
Therefore the framework has no need to understand a ReservoirValue.
bharat commentedon Dec 2, 2016
ok. that's my option 4 above.
To make sure we're both on the same page: I'm currently using GlucoseHUDView, and its set() method takes a GlucoseValue protocol object which is defined in LoopKit. So assuming I stop using that protocol object, it means that I'll also have to change GlucoseHUDView to take the components of the GlucoseValue instead of the protocol itself, which will no longer be defined in this context. I think that's fine since the plan is to refactor those views into their own separate framework anyway...
bharat commentedon Dec 2, 2016
Ok - I've refactored the extension such that it no longer includes the problematic frameworks. That resolves this issue. Thanks for the guidance!
Create a lock screen widget (aka Today Extension) (#281)
Remove glucose prediction when Closed Loop is OFF (#292)