24.0.0
ReactiveUI 24.0.0
ReactiveUI 24 is a major release. ReactiveUI now runs on the allocation-conscious ReactiveUI.Primitives engine, with System.Reactive becoming optional. This changes public type identities and, for the System.Reactive-compatible distribution, namespaces, so review the migration path before upgrading.
Choose your distribution
Both distributions use the same ReactiveUI.Primitives engine, custom schedulers, and optimized sinks. Choose one package family consistently based on the reactive types you want in your public API.
| You want | Packages | Namespace | Public reactive types |
|---|---|---|---|
| The new lighter default | ReactiveUI, ReactiveUI.WPF, ReactiveUI.WinForms, ReactiveUI.WinUI, ReactiveUI.Maui, ReactiveUI.Blazor, ReactiveUI.AndroidX, etc. |
ReactiveUI |
RxVoid, ISequencer, Signal<T> |
| ReactiveUI APIs using System.Reactive schedulers | ReactiveUI.Reactive, ReactiveUI.WPF.Reactive, ReactiveUI.WinForms.Reactive, ReactiveUI.WinUI.Reactive, ReactiveUI.Maui.Reactive, ReactiveUI.Blazor.Reactive, etc. |
Primarily ReactiveUI.Reactive and ReactiveUI.Reactive.Builder |
Unit, IScheduler, Subject<T> |
New default: ReactiveUI.Primitives types
Keeping the existing package names selects the new default distribution. The normal ReactiveUI namespaces remain, but these public reactive types change:
System.Reactive.Concurrency.ISchedulerbecomesReactiveUI.Primitives.Concurrency.ISequencer.System.Reactive.UnitbecomesReactiveUI.Primitives.RxVoid.Subject<T>,BehaviorSubject<T>, andReplaySubject<T>becomeSignal<T>,BehaviorSignal<T>, andReplaySignal<T>.- System.Reactive is no longer a transitive dependency. ReactiveUI.Primitives provides Rx-style operators over
IObservable<T>, so the default distribution does not require System.Reactive for observable composition. System.Reactive can still coexist with the default packages; choose the.Reactivefamily when you specifically want ReactiveUI APIs to use System.Reactive'sISchedulercompatibility seam (together withUnitand subject interop types).
Use System.Reactive schedulers with ReactiveUI: choose the .Reactive packages
Use the .Reactive packages when you want ReactiveUI itself to accept and expose System.Reactive's IScheduler types. Merely referencing or using System.Reactive elsewhere does not require this distribution. Replace each ReactiveUI package with its matching .Reactive package; for example, use ReactiveUI.Reactive with ReactiveUI.WPF.Reactive instead of ReactiveUI with ReactiveUI.WPF.
The compatibility packages intentionally have distinct type identities. Most ReactiveUI APIs move from ReactiveUI to ReactiveUI.Reactive, builder APIs move to ReactiveUI.Reactive.Builder, and platform XAML/CLR namespace mappings may also need updating. This namespace change is part of why version 24 is a major release.
The .Reactive packages are not the old implementation: they use the same Primitives engine and performance work as the default packages, while exposing System.Reactive 7 types at the interop boundary.
Other changes to know about
- DynamicData integration moved out of core. Core routing types such as
RoutingState,IScreen, andRoutedViewHostremain in the main package. DynamicData-backed routing, change-set, collection, and auto-persist helpers now live inReactiveUI.Routing, orReactiveUI.Routing.Reactivefor the System.Reactive distribution. - Hot MVVM paths are substantially faster. Representative .NET 10 benchmarks showed roughly 3–4× faster
WhenAnyValue/ToPropertysubscription and emission, with 5–13× less allocation. Both distributions benefit because both run on Primitives. - AOT-friendly view activation was added. New
IActivatableView.WhenActivatedoverloads accept anIObservable<object?>ViewModel-change source and avoid reflection and trim warnings. - .NET 11 preview targets were added and aligned. MAUI now targets supported .NET 10+ releases; the end-of-life .NET 9 MAUI targets were removed. Existing .NET 9 Windows/WinUI targets remain.
- Several correctness fixes are included.
WhenAnyValueno longer loses a concurrent first change, WPF main-thread scheduling now dispatches correctly from background threads, suspension state is materialized before shutdown persistence, interaction task handlers resume on the captured UI context, and pureObservableMixinshelpers work before builder initialization. - Platform fixes are included. WinForms design-mode detection works on .NET Core and for nested controls. The WPF
.Reactivepackage now resolves its XAML namespace and ships the default theme required byViewModelViewHost. - Two internal-looking public sink types were removed. Consumers of
ReactiveUI.Internal.SingleValueObservable<T>orSyncExecuteObservable<T>should use the equivalentReactiveUI.Primitives.Advancedsignal types (ReturnSignal<T>andStartSignal<T>).
🗞️ What's Changed
💥 Breaking Changes
- 6433b00 refactor!: drop duplicate sinks for Primitives 5.7.0 concretes (#4387) @glennawatson
✨ Features
- 42b4cce feat: re-platform ReactiveUI onto ReactiveUI.Primitives — leaner, faster, System.Reactive optional (#4382) @glennawatson
- 2f34b56 feat: add AOT-friendly WhenActivated for IActivatableView (#4413) @glennawatson
♻️ Refactoring
- ff88f13 refactor(winui): share routed host setup (#4419) @glennawatson
- 873e9c3 refactor: consolidate duplicated reactive plumbing (#4418) @glennawatson
🐛 Fixes
- fed5931 fix: WaitForDispatcherScheduler marshals to UI thread from non-UI threads (fixes #4354) (#4361) @ChrisPulman @Copilot
- c18940e fix: use ObservableMixins helpers before RxAppBuilder initialization (#4410) @glennawatson
- 5a82114 fix(release): use empty MinVer tag prefix to match unprefixed tags @glennawatson
- 4a4efcf fix(wpf): resolve XAML namespace under REACTIVE_SHIM in AutoDataTemplateBindingHook (#4404) @deeferentleeg
- 9f1b734 fix(wpf): ship a default theme in ReactiveUI.WPF.Reactive so ViewModelViewHost renders (#4412) @glennawatson
- 2eb48f2 fix: resume interaction task handlers on the captured context (#4409) @glennawatson
- e5dbcfe fix: Winforms design mode detection regressed (#4369) @xackus
- d9133b6 fix: support .NET Core in winforms activation design mode check (#4358) @xackus
- 69586a4 Fix: WhenAnyValue subscribes to PropertyChanged before reading the initial value (#4381) @dwcullop