Distribution and Current Limitations

This page covers what to expect when moving beyond local experiments.

Distribution direction by platform

Linux

For Linux, the most natural distribution route is usually:

• package the app as Flatpak
• publish through Flathub or distribute the Flatpak yourself

This aligns well with the GNOME and libadwaita ecosystem.

Windows

For Windows, a practical route is to build the app and package it with an installer workflow such as:

• NSIS
• another Windows-native installer approach

macOS

For macOS, packaging generally follows standard macOS app distribution practices. The exact Aparoksha-specific documentation is not as detailed here as it is for Linux and Windows, so expect to rely more on the normal macOS packaging workflow.

The most important reality check

Aparoksha is still an evolving project.

That has several consequences:

• the documentation is incomplete
• some APIs may change
• some views and patterns are still limited
• backend maturity is not perfectly uniform
• older docs and current package structure do not always line up cleanly

Current limitations you should expect

1. Early-stage framework

Do not assume the public API is fully stable.

2. Documentation gaps

In practice, you may need to combine:

• the upstream website
• backend readmes
• the main package definition
• the demo app source

3. Inconsistencies between docs and source

Older instructions may refer to versioned dependencies, while newer umbrella-package usage follows the current main branch setup.

4. Platform maturity differences

The ecosystem appears more naturally aligned with the Adwaita and GNOME side than with the idea of a fully mature universal desktop abstraction.

5. macOS-only projects may not need Aparoksha

If the app is only for macOS, native SwiftUI may still be the more direct and stable route.

Best use cases right now

Aparoksha makes the most sense today if you want to:

• learn the framework
• prototype desktop apps in Swift
• experiment with shared UI architecture
• publish an open starter repo
• explore the ecosystem and maybe contribute back

Use caution if

You need:

• strong long-term API stability
• production-ready guarantees
• mature docs for every platform path
• minimal maintenance overhead

Practical advice

The safest mindset is:

• treat the upstream demo as the living reference
• keep your starter app small
• avoid complex abstractions too early
• test each platform separately
• pin expectations appropriately while the project matures