@chrisvasselli Thank you for reporting this and sorry for getting back to you so late!

I just tried to reproduce this to fix it, but despite creating 3 different kinds of app extensions in a sample project (Action, App Intents, Widget) and adding TelemetryDeck to each of them, I did not run into this build error. Can you tell me what kind of app extension I need to create to reproduce?

Also, even without being able to reproduce, I have tried to fix this by providing a fallback implementation when UIApplication.shared isn't available. But in order for it to build for you, I need to check this at compile time with a directive like #if TARGET_IS_APP_EXTENSION but I'm not sure if there's such a thing that's pre-set in those targets. I could of course introduce a custom one that you would need to add manually to get it building, but I would prefer a way that works out-of-the-box if available. Do you know anything like that? I can only find ways to check for an .appex extension of the bundle at runtime, but that should be too late since it seems to be failing at compile-time.

Huh, I'm surprised you're not seeing the issue. What happens if it actually hits code that uses UIApplication.shared at runtime. I'm seeing it when I have a share extension in my project. I'm using CocoaPods to integrate, so maybe that integrates in a different way.

I looked at the RevenueCat SDK which I also have integrated, and it looks like it's a pretty awkward limitation to get around. Sounds like there aren't any compile-time checks you can do:

SystemInfo.swift

ManageSubscriptionsHelper.swift

@chrisvasselli Thank you for the additional details!

First of all, I want to mention that we do not officially support CocoaPods (anymore). We only still kinda support it because our Flutter SDK wraps the Swift SDK and required it for a long time. But now that CocoaPods itself is officially deprecated and no longer maintained, even the Flutter community is fully switching to SwiftPM, so it's probably only a matter of time before we drop CocoaPods support entirely. So it's probably worth considering switching to SwiftPM if you can. Please do let us know if there's a reason why you can't switch so we can understand your needs and revise our plans if needed.

Having that said, I will try my best to help resolve this issue. Thank you for sharing how RevenueCat deals with the situation. Unlike the RevenueCat SDK, our SDK does not rely on UIApplication.shared for any critical logic. As you can see in the screenshot of your original post, we already have fallback logic for the watchOS and macOS platforms where UIApplication.shared is also not available, and rather than implementing some workaround based on legacy systems that could break sometime in the future like RevenueCat had to do, I would prefer to simply fall back to the non-UIApplication variant of our logic instead. And that's exactly what I did in the feature/app-extensions branch now.

As there's no built-in flag we could check during compile-time, I have added a section to our README documenting how to easily setup one for your app extension targets. Please try that solution with the feature/app-extensions branch and let me know if this resolves the issue for you.