Linker warnings: "not safe for use in application extension"

[bharat]

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.

[loudnate]

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]

To be clear, I don't think the right solution is to make each of those existing frameworks extension-safe.

[bharat]

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:

1. I can move the StatusExtensionContext into Loop but I don't think that'll resolve the warnings.
2. I can remove the framework-aware bits from StatusExtensionContext (and then add them into an extension class inside Loop) but then I don't think the extension will work on its own.
3. I can create a sub-framework and move some of the protocol-definitions into them where that sub-framework is as minimal as possible and can be marked extension-only.
4. I can make a duplicate of those protocols and drop the framework reference from the extension, but that doesn't feel very DRY to me and risks the protocols getting desync'd in the future (and frankly I have no idea if it'd even work)

Can you explain in more detail what you think is the right approach here? thanks!

[loudnate]

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]

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]

Ok - I've refactored the extension such that it no longer includes the problematic frameworks. That resolves this issue. Thanks for the guidance!