App Release Standard V2
Overview
Godsway Sackey Free Apps uses clear technical criteria when evaluating applications. This standard (Version 2.0) defines practical requirements for offline capability, data portability, and accessibility.
1. Application Status Taxonomy
Applications in our ecosystem are classified into three strict tiers:
- Blueprint: An architectural concept outlining the public-good case, data models, and offline boundaries. No usable software exists.
- Preview: Alpha software where at least one core workflow functions end-to-end, but compliance with this standard is incomplete. Data loss may occur.
- Verified Release: Production-ready software that has passed automated and manual certification against all criteria below, accompanied by a dated public test record.
2. The Offline-First Contract
No free application should rely on continuous cloud connectivity when its stated purpose can be served locally. The application should treat the absence of a network as a supported operating condition.
2.1 Storage and State
- IndexedDB as Source of Truth: All operational data (user input, application state) must be written synchronously to a local database (e.g., IndexedDB via Dexie or localForage).
- App Shell Caching: The Service Worker must cache 100% of the UI shell, assets, and logic required to bootstrap the application in a zero-connectivity environment.
- No Volatile Drafts: Users must not lose data upon closing the browser or navigating away while offline.
2.2 Synchronization
- Synchronization logic must operate in the background. It must not block the UI or present loading spinners during data entry.
- Conflicts between nodes must be resolved deterministically using CRDTs (Conflict-free Replicated Data Types) or Last-Write-Wins with an immutable audit log.
3. Data Sovereignty & Minimalism
Applications must not collect unnecessary telemetry, and they must grant the user total control over their local database.
3.1 Minimum Collection
- Only fields strictly required for the core workflow may be collected. Optional demographic or tracking data is explicitly banned.
3.2 Portability
- Universal Export: Every application must provide a one-click bulk export feature. The export must be in an open, parseable format (e.g., standard JSON or CSV) containing the entire local database.
- Universal Import: The application must be able to restore its state entirely from the above export file offline.
3.3 Deletion
- A prominent "Clear Local Data" mechanism must be provided. This action must permanently wipe the IndexedDB instance and unregister the Service Worker.
4. Accessibility Baselines
Accessibility is not an overlay; it is a foundational architectural requirement.
- WCAG 2.2 AA Compliance: Applications must pass automated testing (via Axe or Lighthouse) and manual review for WCAG 2.2 AA.
- Keyboard Navigation: All interactive elements must be fully operable via keyboard alone with highly visible focus states.
- Device Support: The application must function gracefully on low-end hardware (e.g., 2GB RAM devices) and small viewports (320px width minimum).
Applications failing any of these criteria will remain in Preview status indefinitely until rectified.