How to handle artifact variants?

zapstore / zapstore

Permissionless app store powered by your social network

https://zap.store

MIT License

72 stars 6 forks source link

How to handle artifact variants? #72

Open franzaps opened 4 months ago

franzaps commented 4 months ago

Often times there are multiple artifacts targeting a single architecture, how to handle these, as separate apps? Or as another concept as they can interchangeably be updated as they use same app id / cert?

For example Amber has a "free" (NIP-46 support) and "offline" (totally offline)

alltheseas commented 4 months ago

For example Amber has a "free" (NIP-46 support) and "offline" (totally offline)

Is this a one time choice for the user, or is there always a choice to switch between online/offline?

franzaps commented 3 months ago

From app feedback

A lot of apps have different versions (like amethyst has fdroid-version and playstore-version). Could be cool to show what version the user is installing, and even pick different versions and let the user choose what version to install :)

franzaps commented 3 months ago

A few thoughts

Should be indexing all APKs in a release (all variants and architectures)
Except probably those signed by Google Play (unless it's the only one)
If more than one for architecture, prompt the user to select variant upon install
Remember their choice in local storage (after 0.2 in a user-data event)
Local storage can be cleared, if choice is gone ask again

franzaps commented 1 month ago

Depends on https://github.com/zapstore/zapstore-cli/issues/1 for proper f tags, update query to use them