Q42 / Q42/Template.ComposeMultiplatform
Add forced-update feature to template
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 1
- Forks
- 0
- Avg merge
- 7d 15h
- Merged PRs (30d)
- 15
Description
What
Forced-update is a feature that allows developers to enforce old versions of the app to be blocked from usage with a screen that forces the user to update to a new version, this means the developer now has an effective way to deprecate old versions of the app that can or should not be supported anymore
Why
We need an effective way to deprecate old versions of the app that can or should not be supported anymore. For example, due to security bugs on old versions or features that can't be supported anymore by the backend.
How
The main requirements for the implementation are:
- the feature must be an app's flow agnostic in the template (before or after auth/onboarding/consent flow is not a template decision)
- the feature must be an app's design agnostic in the template, a default UI implementation is still provided
- the Policy engine should be pure Kotlin (commonMain). Takes the running build number plus a fetched policy and emits a status. No I/O, no Compose, trivially testable.
- the Policy source should be an interface with a default implementation (for example Firebase Remote Config)
- Fail open. If the fetch fails or times out, use the cached policy; if there's no cache, let the user in. A config outage must never brick the install base. Set a short timeout and don't block the splash on it.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the commonMain code and the template flow integration points. Read how the template currently handles app startup, then define the policy engine and policy-source boundaries described in the issue. Done means the feature is flow- and design-agnostic, uses a default UI, is pure and testable in commonMain, and fails open with cached or absent policy.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100