question about errors from implicit transitive dependency on SwiftUI

[jaredh159]

i'm (re)building a macOS app that is a menu-bar background utility that is also a host for a system network extension.

i'm a huge fan of TCA, and am using it for both the menu bar app, and the system extension (which runs as root) which it hosts. i'm also using swift-dependencies to model the communication between the app and the extension, over XPC. furthermore, i'm targeting 4 versions of macOS, going back to 10.15.

i fully realize all of this puts me way out of the mainstream, normal, happy path for TCA.

my question has to do with TCA's implicit dependency on SwiftUI. i have zero SwiftUI usage in my entire app. that's mostly because, as I mentioned, i'm targeting 4 versions of macOS, and anyone who has done SwiftUI in production on macOS can testify to the fact that it has severely lagged behind iOS, and been inconsistent and buggy across major macOS versions. trying to write SwiftUI that works well from Catalina thru Venture is incredibly difficult, and almost impossible to test without having a VM or dual-boot for every version of the OS. what's more, my app is a background utility (LSUIElement) app, so it has very little UI anyway, mostly it stays out of the user's way, and is only intermittently interacted with, while it does it's job in the background.

but beyond the app, the root-user system extension which the app installs is also running TCA. that may seem odd, but TCA is actually an incredibly great fit to tame this use case. the system extension lives forever, has to manage multiple background concerns over time, recover from error states, communicate with user processes, make logic decisions based on a set of rules, etc. having this all testable inside a reducer with actions, publishers, long-lived effects, timers, and being able to control time and dependencies and use all of TCA's test store features has been amazing.

however, i do get os-level errors in my Console.app when the root system extension launches, having to do with SwiftUI. the os (rightly) seems to think it's odd that my extension with zero UI is (transitively) depending on SwiftUI.

so far, it seems like these errors aren't causing any actual problems, but it got me thinking about TCA and whether you guys had ever thought about making the SwiftUI dependency opt-in. it feels weird that SwiftUI is coming along for the ride in my app, when I don't use it at all, and especially so in a context where it can't be used, and there is no possibility of having any UI (in the system extension).

i recognize that you guys have put a ton of work into all of the SwiftUI helpers and integration, and that probably the vast majority of your users are using SwiftUI, and I imagine it's super convenient to just make it a transitive dependency. i don't fault you for it at all. but i'm wondering if the architecture of TCA would ever allow SwiftUI to be not included transitively, and then library consumers could explicitly pull in modules like your SwiftUI Navigation module, if they wanted to use SwiftUI. is that something you've discussed, or are open to? or would it just be too deep of a change for too few users in my situation?

also, i may be misunderstanding the errors, and exactly in what sense SwiftUI is a transitive dependency.

fwiw, i'm working with the 1.0 pre-release branch for now (though i'm a couple months from shipping the re-write to production, so i'm pretty confident i'll be depending on a non-beta version of TCA before this goes into production).

thanks for all the great libraries, every swift project i make has a laundry list of pointfree dependencies. :)

[mbrandonw]

Hi @jaredh159, making SwiftUI an opt-in dependency is definitely a goal of TCA, but it is going to take awhile to get there. However, I'm not entirely sure I understand your problem fully, because SwiftUI and Combine are both supported in macOS 10.15. There may be something much simpler happening in your project.

Can you try creating a macOS 10.15 project from scratch that reproduces the problem so that we can see what the issue is?

[jaredh159]

thanks for getting back to me. yeah, you're right, SwiftUI is supported in 10.15.

the issue is that I have a system extension installed by my app. it's a network extension that filters socket connections as root (the app is an internet safety tool for parents). the system extension runs with special privileges as root, and has no UI at all. the only way you can even tell it's there is if you look in the "Network" section of system preferences, where it is listed alongside WiFi and other network adapters.

the system extension is like its whole own app, it just happens to be installed by the host app. and in that system extension, i'm running TCA. so the error happens when the system extension launches and imports TCA. TCA then imports SwiftUI, and the os emits errors like those shown below (only visible in Console.app)

making a repro is actually super hard, the entitlements required to actually install the system extension are super gnarly and it would take a bunch of work on your end.

like i said, the errors don't actually seem to be hurting the system extension at this point, everything is still working, so i wouldn't necessarily call this a bug, or a deal breaker. it just made me ponder whether you were aiming to make SwiftUI opt-in at some point. to hear you say that it's a goal is definitely encouraging, that's mostly all I wanted to know.

just spit-balling here, but... i wonder if you could have a module like ComposableArchitectureCore which didn't import SwiftUI at all. then, the main ComposableArchitecture module could do a @_export import ComposableArchitectureCore, and then almost everybody could keep depending on the main module, but then weirdos like me working in unusual or constrained environments (or maybe just using App/UiKit) could depend on ComposableArchitectureCore. sort of like how Rust has the no-std concept. i'm sure you've probably already thought all that through and have much more of a handle on the complexities involved.

anyway, glad to hear it's a stated goal you guys are moving towards.