# Rename "Start" button to "Open" for webxdc apps

**URL:** <https://forum.delta.chat/t/rename-start-button-to-open-for-webxdc-apps/5724>\
**Category:** Feature Proposal\
**Tags:** user-interface, webxdc\
**Created:** [August 30, 2026, 8:05pm UTC](https://forum.delta.chat/t/rename-start-button-to-open-for-webxdc-apps/5724 "2026-08-30T20:05:51Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![maphouse](https://forum.delta.chat/user_avatar/forum.delta.chat/maphouse/32/2853_2.png) [@maphouse](https://forum.delta.chat/u/maphouse)\
**Post date:** [August 30, 2026, 8:05pm UTC](https://forum.delta.chat/t/rename-start-button-to-open-for-webxdc-apps/5724/1 "2026-08-30T20:05:51Z")

</div>

The button label for opening a webxdc app in chat currently says “Start…” (localized as start\_app). This is misleading for apps that already have shared state from other  
participants — tapping “Start” on an in-progress timer or collaborative document implies initiating something new, when the user is actually joining/resuming.

Proposal: Rename to “Open” across all clients.  
“Open” is the standard verb for files and apps across all major OSes

- It’s neutral about whether the app is new or has existing state
- It avoids confusion with app-specific actions (a timer’s own “Start” button, for example)
- “Start” is arguably accurate (the webview doesn’t run in background), but “Open” is equally accurate and less ambiguous

This applies to Android, iOS, and Desktop, and it came up while building a [shared pomodoro timer](https://github.com/maphouse/pomodoros) where the chat preview’s “Start” button conflicted with the app’s own start action.

---

<div class="post-metadata">

**Author:** ![maphouse](https://forum.delta.chat/user_avatar/forum.delta.chat/maphouse/32/2853_2.png) [@maphouse](https://forum.delta.chat/u/maphouse)\
**Post date:** [September 1, 2026, 3:53am UTC](https://forum.delta.chat/t/rename-start-button-to-open-for-webxdc-apps/5724/2 "2026-09-01T03:53:23Z")

</div>

I am realizing I may be wrong about this: the mini app’s code is not functioning for the user when closed, so start is technically correct.

I do admit though, it always looks strange, from a UI perspective, despite it being technically honest.