Experiment: Unify PowerSync.Maui and PowerSync.Common

[LucDeCaf]

This PR shows off a potential path for unifying PowerSync.Common and PowerSync.Maui into the same package.

While working on the Uno Platform demo integration, I started wondering why we needed a separate package for MAUI/mobile at all. I decided to ask Claude Code if it could create a POC of what it would look like to remove PowerSync.Maui entirely and to fold everything into Common. The result is this PR.

If we go down this route (either in this PR or in a future one), we would likely make one last release of PowerSync.Maui marking it as deprecated and turning it into a package reference for PowerSync.Common.

Features

• All native libraries are now referenced directly by Common. You no longer need the dedicated Maui package for mobile targets; as a result, the Maui package has been removed.
  • Libraries are not included for builds that they aren't needed in, so the bundle size should be about optimal.
• powersync-sqlite-core.xcframework has been massively stripped down (~135 MB => 3.8 MB uncompressed); this change will probably escape from this PR.
• Removed some duplicate native libraries in runtimes.

Blockers

• The code is currently unreviewed.
• We need to perform testing on a physical iOS and Android device.
• Need to benchmark implementation startup time (probably not that important).
• Provide a nice path for moving off of PowerSync.Maui.
• This would have to be a major version release.

AI Disclaimer

The code in this PR is 100% AI generated and is not intended to be merged.
While I directed and corrected the LLM into producing an output I like, I have only taken a cursory look at the code itself and have not performed thorough review. This is intended as an experiment to see what a unified package would look like and to analyse what problems it could potentially cause.

[Chriztiaan]

I think we could consider merging the packages. My strongest argument for keeping them separate (but potentially rename the MAUI package) is that it keeps the build targets split (keeping mobile builds out of common) and also allows us, for example, to have platform specific testing kept out of common (like mobile specific testings/integrated sim tests).

[LucDeCaf]

My strongest argument for keeping them separate [...] is that it keeps the build targets split (keeping mobile builds out of common)

I don't think it does, actually - we still include the -android/ios/maccatalyst targets in Common as well. If you mean that it keeps the native mobile libraries out of Common, I don't see the benefit of that, since we already bundle native desktop libraries with Common.

We could consider removing the mobile targets from Common entirely, but that doesn't change the fact that it still requires native libraries to run, even on "pure" .NET targets. I think the most "honest" thing to do is to admit that Common requires native libraries to function and to include all the platforms and required libraries it targets with the package itself.

If you're concerned about package bloat, .NET has a way to avoid specific directories being bundled with target platforms they aren't needed in. This would increase the size of the bundle we publish to NuGet, and we are somewhat close to the bundle size limit (~153 MB out of 250 MB IIRC), so this PR also includes a modification to how we download and deduplicate the native PS libraries (strip unused debugging symbols from the .xcframework file and share the same bundle for all Apple targets), which massively undercuts our old bundle size.

[Split packages] also allows us, for example, to have platform specific testing kept out of common (like mobile specific testings/integrated sim tests).

Fair, but there's nothing stopping us from creating a Tests/PowerSync.Common.MobileTests (or similar) project and gating it behind a RUN_MOBILE_TESTS flag like we do with the IntegrationTests and PerformanceTests.

[Chriztiaan]

My strongest argument for keeping them separate [...] is that it keeps the build targets split (keeping mobile builds out of common)

I don't think it does, actually - we still include the -android/ios/maccatalyst targets in Common as well. If you mean that it keeps the native mobile libraries out of Common, I don't see the benefit of that, since we already bundle native desktop libraries with Common.

We could consider removing the mobile targets from Common entirely, but that doesn't change the fact that it still requires native libraries to run, even on "pure" .NET targets. I think the most "honest" thing to do is to admit that Common requires native libraries to function and to include all the platforms and required libraries it targets with the package itself.

If you're concerned about package bloat, .NET has a way to avoid specific directories being bundled with target platforms they aren't needed in. This would increase the size of the bundle we publish to NuGet, and we are somewhat close to the bundle size limit (~153 MB out of 250 MB IIRC), so this PR also includes a modification to how we download and deduplicate the native PS libraries (strip unused debugging symbols from the .xcframework file and share the same bundle for all Apple targets), which massively undercuts our old bundle size.

[Split packages] also allows us, for example, to have platform specific testing kept out of common (like mobile specific testings/integrated sim tests).

Fair, but there's nothing stopping us from creating a Tests/PowerSync.Common.MobileTests (or similar) project and gating it behind a RUN_MOBILE_TESTS flag like we do with the IntegrationTests and PerformanceTests.

I agree on all fronts. I think we can earmark this work as part of the v1.0.0 roadmap.
Do we still need a dedicated MAUI Factory? At the very least I think we should rename it it (since it works for all mobile platforms).