[Epic] Tablet Build Support & App Store Readiness for status-desktop

[alexjba]

📱 Epic: Tablet Build Support & App Store Readiness for status-desktop

Target Release: v2.35
Goal: Enable status-desktop to run on Android and iOS tablets with a native-like experience, and prepare builds for publication to both the iOS App Store and Google Play Store.
Note: Not all the work here is a must for release. The general agreement is to release with minor tweaks to improve the UX even if we don't have full feature parity with status-desktop
Dependencies: Qt6 migration

This epic is the central place to track all engineering, QA, CI/CD, and product work required to bring status-desktop tablet builds to production and submit them to mobile app stores.

✅ What We Already Have

• ✅ A dedicated build system for Android/iOS, currently hosted at: Tablet-build
• ✅ Core modules (Chat, Communities, Wallet, Onboarding) are working on tablets
• ✅ Tablet builds run on real iOS and Android devices and on emulators

❌ What We Don't Have

• ❌ CI that's producing a signed app bundle
• ❌ Beta testing in stores (test flight et. al.)
• ❌ App Store readiness
• ❌ A polished UX
• ❌ Feature parity with desktop

---

🧩 Tasks

1. Build System Integration - Dev

• [Must have] Move tablet build system into status-desktop (e.g., under platforms/tablet)
• [Must have] Ensure compatibility with Qt6 migration - depends on Qt6 migration
• [Must have] Update README with tablet-specific build instructions (Android, iOS)
• [Nice to have] Nim-first build system

2. CI/CD & Signing

• [Must have] Create CI jobs for Android and iOS tablet builds
• [Must have] Add support for:
  • Android keystore signing
  • iOS provisioning profile & certificate signing
• [Nice to have] Include debug/test builds for internal tracks (TestFlight, Google Play Internal) @sunleos
• [Must have] Disable dev logging in release builds - we're logging on syslog on Android discouraged by google

3. QA & Bug Aggregation @sunleos

Note: One option would be to run a bug bash in the team

• Define and verify critical flows on tablets:
  • Chat
  • Communities
  • Wallet
  • Settings
  • Onboarding
• Prioritize and fix based on severity
• Prioritize testing on real devices - not emulators
• [Must have] Try squish automation on android @sunleos

4. Feature Readiness

• [Must have] Permissions flow for camera, file access, networking (pairing accounts)
• [Nice to have] Push notifications implementation (platform-specific) #18403
• [Nice to have] Biometrics (FaceID / fingerprint)
• [Nice to have] Keycard integration
• [Nice to have] WalletConnect (migrate to native webviews)

5. Input & UX Adjustments

• Investigate and resolve soft keyboard issues:
  • [Very nice to have] Input focus bugs - note: fix if it's small to medium effort
  • [Must have] Chat input: Enter vs New Line behavior
  • [Nice to have] Numeric keyboard support for amount input
• [Nice to have] UX/design review for tablet usability @benjthayer

6. App Store Compliance

Notes:
Try submitting a test build - depends on signing @sunleos
Ask legal what do we need to release in App Store in terms of legal compliance

• Collaborate with Infra team on:
  • App Store and Play Store account access
  • App privacy policies and permission declarations
  • Store metadata: screenshots, descriptions, etc.
• Confirm crash reporting behavior per store guidelines

7. Community & Contribution [Nice to have]

• Open tablet-specific tasks for contributing
• Document dev setup for Android/iOS builds
• Add contribution/testing guidelines to README

---

📐 FURPS: Non-Functional Requirements

Functionality

• Partial feature parity with desktop app expected - no keycard, biometrics and dapps. To be added later.
• Use light Waku client instead of full node - TBD
• No tablet-exclusive features planned

Usability

• Reuse current desktop layout; no tablet-specific design system
• UX is a secondary goal (strategic priority is Nim ecosystem reach)
• Virtual keyboard support
• No onboarding enhancements required

Reliability

• Target crash-free rate: 90%
• Crash logging behavior: use default platform handling (to be clarified)

Performance

• Performance targets:
  • App startup: < 3s
  • Community screen: < 2s
  • Chat screen: < 1s
• Device target: Mid/high-end tablets only
• Resource use: < 2.5 GB memory with a heavy account
• Battery: Medium consumption (TBD exact metric)

Supportability

• OS version targets (based on Qt6 defaults):
  • iOS: 16+
  • Android: 9+
• Test builds (TestFlight, Google Play)
• Development can be done on both emulators and real device
• The build system supports Qt6+

[alexjba]

CC @anastasiyaig @noeliaSD @micieslak @caybro @Khushboo-dev-cpp

[86doteth]

this seems like a lot of work for marginal adoption tbh. is there anywhere where its documented what the strategy and evidence is for the decision to prioritize this over other possible more promising features (like chatbots, status sdk, custom tokenlists etc)

[anastasiyaig]

hey @86doteth 👋
as far as i am aware, it is not prioritized over chatSDK and other features you mentioned at all

[86doteth]

hey @86doteth 👋 as far as i am aware, it is not prioritized over chatSDK and other features you mentioned at all

ah great any place where i can follow progress on those?

[jrainville]

this seems like a lot of work for marginal adoption tbh. is there anywhere where its documented what the strategy and evidence is for the decision to prioritize this over other possible more promising features (like chatbots, status sdk, custom tokenlists etc)

@86doteth Like @anastasiyaig this is a parallel project, we are still focusing on those things you pointed out.

For chatbots, we have this initiative called Cicadian
The ChatSDK is gonna be handled by the Waku team. @jazzz might be able to link you the right places to keep track.
Custom token list I'm not sure, @alaibe can answer

[86doteth]

this seems like a lot of work for marginal adoption tbh. is there anywhere where its documented what the strategy and evidence is for the decision to prioritize this over other possible more promising features (like chatbots, status sdk, custom tokenlists etc)

@86doteth Like @anastasiyaig this is a parallel project, we are still focusing on those things you pointed out.

For chatbots, we have this initiative called Cicadian The ChatSDK is gonna be handled by the Waku team. @jazzz might be able to link you the right places to keep track. Custom token list I'm not sure, @alaibe can answer

i would have rather seen waku team all-in focus on just shipping sds in status to make chat actually usable instead of the dozens of other things theyre juggling.

and status team all-in focus on making status the prime developer platform rather than waku. thats why samuel linked to my github rant in the second post in that discuss post. but ill try to make it more explicit in another status forum rant soon but kind of rant-tired for now

btw is chat import planned for any time soon? still conserving my broken account until the day i can finally export its message history into a new instance and hence not posting in the app til then. basically missing messages+losing all my historical data once/few times a year makes the app completely unusable :(

[jrainville]

btw is chat import planned for any time soon? still conserving my #17039 (comment) until the day i can finally export its message history into a new instance and hence not posting in the app til then. basically missing messages+losing all my historical data once/few times a year makes the app completely unusable :(

We are discussing working on the export and export of the user backups to local files in the next milestone.
We'll see if we want to include the messages export too.

BTW, I'm working on opening more stuff, so hopefully we can put all those discussions, roadmaps, briefs and specs in Github so that you can follow along

[jazzz]

@86doteth

ah great any place where i can follow progress on those?

You can follow along on the ChatTeam’s deliverables here

i would have rather seen waku team all-in focus on … make chat actually usable

Me too! For clarity; Waku CoreTeam is focused on waku. ChatProtocol team is focused on making a private and usable chat protocol (including SDS), and Status teams are focused on delivering chat( and more) to users.