NSE/push-sync drags in dioxus iOS lifecycle (UIApplicationMain) — illegal in app extensions

[pvg13]

Summary

When building a Notification Service Extension (NSE) that uses WaveSyncDB's
push-sync FFI, the extension staticlib pulls in WaveSyncDB's dioxus iOS
lifecycle code, which references UIApplicationMain and UIApplication
notifications. These symbols are illegal in an app extension (built with
-application-extension / APPLICATION_EXTENSION_API_ONLY), so the extension
either fails to link or is rejected by App Review.

There is currently no way to enable push-sync (the NSE FFI) without also
dragging in the dioxus UI lifecycle module.

Environment

• WaveSyncDB consumed with features ["derive", "dioxus", "web", "push-sync"]
  (the push-sync feature is what exposes wavesync_nse_handle_push).
• Target: aarch64-apple-ios, linked into an NSE appex via swiftc -application-extension -e _NSExtensionMain -force_load libnse.a.
• Downstream: Mediterranea's packages/nse crate (depends on wavesyncdb +
  db only, deliberately excludes the ui/dioxus-router crate to stay under
  the NSE memory budget — yet the UIKit symbols still arrive via wavesyncdb's
  own dioxus feature).

Symptom

swiftc link of the appex fails with:

Undefined symbols for architecture arm64:
  "_UIApplicationMain", referenced from:
      objc2_ui_kit::...::UIApplication::main::... in libmediterranea_nse.a
  "_UIApplicationDidBecomeActiveNotification", referenced from:
      wavesyncdb::dioxus::lifecycle::ios::start_lifecycle_listener::... in libmediterranea_nse.a
  "_UIApplicationWillResignActiveNotification", referenced from:
      wavesyncdb::dioxus::lifecycle::ios::start_lifecycle_listener::... in libmediterranea_nse.a
  "_kSCDynamicStoreUseSessionKeys" / "_kSCNetworkInterfaceType*", referenced from:
      system_configuration::... in libmediterranea_nse.a   (if_watch / SystemConfiguration)
ld: symbol(s) not found for architecture arm64

The wavesyncdb::dioxus::lifecycle::ios::start_lifecycle_listener reference is
the blocker: it uses UIApplication/UIApplicationMain, which are unavailable
to app extensions regardless of which frameworks are linked. (The
SystemConfiguration symbols — from libp2p's if_watch — are separately
fixable by linking -framework SystemConfiguration, and are noted only for
completeness.)

Root cause

The dioxus feature compiles wavesyncdb::dioxus::lifecycle::ios, which calls
into UIApplication. When a downstream extension enables push-sync, Cargo
feature unification (or a direct dependency edge) also brings in the dioxus
lifecycle module, so the extension-illegal UIKit code lands in the staticlib
even though the extension never runs a UIApplication.

Request

Provide an extension-safe path to the push-sync FFI that does not compile
the dioxus/UIKit iOS lifecycle. Options (any one is fine):

1. Make push-sync fully independent of dioxus — i.e. wavesync_nse_handle_push
   and the SyncNotify registry link without pulling dioxus::lifecycle::ios.
2. Gate the iOS lifecycle listener behind a separate, non-default feature (e.g.
   dioxus-lifecycle) so dioxus (used for the main app UI) can be enabled in
   the app target without forcing UIKit into a sibling extension target.
3. Build the dioxus::lifecycle::ios module with #![cfg(not(app_extension))]
   or gate the UIApplication calls so the symbols aren't emitted in an
   -application-extension build.

Happy to test any of these against the Mediterranea NSE build
(swiftc -application-extension … -force_load).

Workaround in the meantime

Shipping the app without the NSE (WITHOUT_NSE=1) — the app is fully
functional; alert-class pushes just show the operator placeholder banner instead
of rewritten content, and background sync is unaffected.

[pvg13]

Fixed on dev (dff5b6f) via option 2, hardened for the -force_load reality: the problem isn't just the module — a force-loaded archive pulls every compiled object, so the dep family itself must stay out of extension builds.

What changed:

• dioxus no longer enables objc2/objc2-foundation/objc2-ui-kit/block2. They (and dioxus::lifecycle::ios) now compile only under a new additive feature: dioxus-ios-lifecycle.
• An NSE tree that inherits dioxus through unification (your db crate edge) therefore contains zero UIKit objects — nothing for -force_load to drag in.
• iOS builds without the feature get a warn-noop lifecycle listener.

⚠️ Action needed on the Mediterranea APP target: add dioxus-ios-lifecycle to the wavesyncdb features of the app (not the NSE). Without it, use_auto_lifecycle never fires on iOS — which would silently regress the #111/#112 fast-resume path (the ≥60s-background → NetworkTransition recovery rides those observers). The runtime warning says exactly this, but don't rely on spotting it: add the feature in the same PR that bumps the dependency.

Verified here (Linux): cargo tree --target aarch64-apple-ios with your exact NSE feature set (derive,dioxus,web,push-sync) → objc2-ui-kit absent from the graph entirely; present with the new feature. Both arms compile; full crate cross-check on Linux stops at ring's build script (needs an Apple toolchain), so the final swiftc -application-extension link is yours to confirm — the SystemConfiguration symbols will still need -framework SystemConfiguration on the NSE link line (if_watch, as you noted; documented in the feature's comment).

Once your NSE links and the app build carries the new feature, this can close.

[pvg13]

Update — resolved consumer-side without a WaveSyncDB change, but the underlying over-broad coupling is still worth fixing upstream.

Root cause confirmed: push-sync does not require dioxus (push-sync = ["mobile-ffi", "dep:manganis", "dep:android_logger"]). The UIApplicationMain reference comes solely from the dioxus feature (dep:objc2-ui-kit + wavesyncdb::dioxus::lifecycle::ios). It leaked into the NSE only because the consumer used wavesyncdb = { workspace = true } (which force-enabled the workspace's dioxus feature) in both the extension crate and a shared db crate.

Consumer-side fix that works: give the extension crate and the shared db crate standalone, dioxus-free edges (default-features = false, features = ["derive", "push-sync"] / ["derive", "web"]). cargo tree -p <nse> --target aarch64-apple-ios -i wavesyncdb then shows no dioxus and objc2-ui-kit count 0; the appex links and ships in a distribution IPA. Main-app builds are unchanged because the UI crate still enables dioxus (unification).

Still worth an upstream fix so consumers don't need this surgery: gate wavesyncdb::dioxus::lifecycle::ios's UIApplication usage behind #[cfg(not(app_extension))], or split the iOS lifecycle listener into its own feature so dioxus (app UI) doesn't force extension-illegal UIKit symbols. Also, if_watch/system_configuration require the extension to link -framework SystemConfiguration — a note in the NSE/push-sync docs would help.