Wikimedia Apps/Team/Future of Editing on the Mobile Apps

The apps attract new users every year, and there are plans to market them to new audiences. Reading features are the primary motivation for users to download the apps, and the majority of user feedback the team receives is about improving reader features. As those readers become more engaged with Wikipedia, some develop an interest in contributing. Of those who do attempt to edit, many find that the app's editing experience (while functional for basic edits) does not yet include the Visual Editor, and other features available on mobile web. New users also find it difficult to find community spaces like the Teahouse and Help Desk from the apps.

This creates a risk for editor recruitment. Many editors make their first contributions by correcting small errors while casually reading. If those moments of impulse happen inside the app and a newcomer encounters wikitext without the option of VisualEditor, it may discourage them before they establish a foothold.

An April 2025 study on reading and editing in the iOS app surfaced consistent patterns across both new and experienced editors: without VisualEditor, wikitext becomes the barrier. Because the app lacks VisualEditor, anyone who opens an article to edit is immediately confronted with raw wikitext, which resembles code and leads many newcomers to assume editing requires technical knowledge. This perception actively discourages contribution before it begins. Experienced editors are not immune: even those comfortable with wikitext find source editing on mobile slow and error-prone. VisualEditor was consistently described by study participants as faster and more intuitive. Its absence in the app is, for many, the primary reason they do not edit there.

Some direct participant quotes from the study:

On PC, you can choose between source and visual editing, which makes it much more intuitive. On the app, visual editing seems unavailable, which is unfortunate. If added, it would make editing more accessible to beginners.

There should be the feature to edit without looking at wiki code like on desktop. Visual Editor — there should be something like that for the app. I think that will make things a lot more convenient.

I wouldn't add a reference at all because I feel intimidated by all these symbols here." It's really cumbersome to do substantive research-driven editing on here.

These findings are consistent with what experienced editors have raised independently. These concerns are taken seriously. The goal of this page is to work through them openly.

These findings are consistent with what editors have raised independently. The quotes below were gathered from the app store reviews, support email and a recent discussion on English Wikipedia's village pump.

I often switch to mobile web to edit because the tools are easier to use there.

If the app restricts editing or has missing features compared to mobile web, it should make it clear that mobile web is better for that task.

No VisualEditor, no access to Help Desk or Teahouse... Not suitable for new editors. Not suitable for experienced editors. If the WMF intends to make the app equivalent to mobile web, I am on board. If it is going to remain dreadful, then push editors away from the app as soon as possible. The reading experience is superior on the app. But people read Wikipedia because those before them have edited to create that content.

Could the 'edit' button on the app redirect to the web? A lot of people make their first edits by correcting spelling errors while reading. If the app is cumbersome for editing, it'll drive away would-be editors.

Editing on the app requires wikitext, which makes it difficult for beginners.

The app works well for reading, but it is not very practical for editing.

If editing works better on mobile web, the app should make it easy to continue editing there.

The Wikipedia mobile apps (iOS and Android) were originally built as reading tools, and over time a native editing experience and suggested edit features were added that many users actively utilize. The apps and mobile web have never aimed for feature parity; they have deliberately focused on continuity while experimenting with different features and serving different segments of users. For example, the apps first introduced Suggested Edits as a mobile-first contribution method, which were later invested in and optimized on mobile web.

The Wikimedia Foundation has made a deliberate organizational decision to invest in readership alongside editing, creating dedicated Reader teams to address declining readership and build a new generation of Wikipedia users. As part of the resulting strategy, the apps will be positioned as the flagship reading experience for active readers, focusing on personalized discovery, daily engagement, and deeper connections to Wikipedia's content. Editing investment, meanwhile, is being concentrated on web by the Contributor teams, who have brought tools like Edit Check within Visual Editor, Suggested edits, and the Newcomer homepage to the editing experience. The mobile web will also be home to investments that come from ongoing mobile editing research.

The Reader and Contributor teams are working together on this, and introducing editing is particularly important on the apps, where a large share of users visit daily, and daily users are most likely to try editing. When an app user indicates interest in editing, what should happen next? That is what this page aims to discuss.

• Providing access to mobile web’s Visual Editor from within the App: The app could provide ways for users to continue editing in mobile web, where VisualEditor and other more fully-featured tools are available. What is less settled is how to do this effectively. Some questions being explored:
  • Should the app offer a direct handoff, opening the article in the mobile web editor when a user taps 'Edit', preserving their place in the app so they can return after?
  • Should the mobile web editor be surfaced as the default editing pathway at the point where a user shows editing intent, or as a deliberate choice?
  • How should the transition feel? Presented within an in-app webview, a redirect to the browser, a clear prompt, a persistent banner.

• Removing editing entry points from the app entirely: Highly engaged readers are strong candidates for first-time editing, and the app's growing reader base represents an opportunity to grow this share. For reader-focused features that require an account, such as the Activity tab, a share of new accounts consistently activate within the apps. The share of newer editors on the apps (18–22% of edits from those with one year or less of experience) is currently lower than on Web, and growing this cohort is part of what this discussion is about. At the same time, 33–37% of app edits come from editors with five or more years of experience, who rely on existing entry points. Any changes must account for both cohorts.
• Building a fully native visual editor for the apps: This would be a significant undertaking for the mobile apps team, and would hinder their ability to invest in reader retaining features. A native visual editor on the apps would not immediately benefit from improvements and additions to the web visual editor, so maintaining feature parity would require continued investment where apps are already years behind in development.

The Discussion page is open for discussion. There are broader questions about the future of editing on the apps, including the role of Suggested Edits, how to support experienced editors, and what signals identify a potential editor where we can then surface the right call to action and handoff proactively. Feedback on these larger questions is welcome. The current focus, however, is more specific: when an app user taps "Edit" on an article, how should the app ensure they can reach the most capable editing tools available — including VisualEditor on mobile web?

Some specific questions that would be particularly useful to hear responses to:

• What are the most critical editing workflows or community spaces that need to be accessible (even via redirect) from within the app?
• If the mobile web editor was accessible from the app, should the Mobile Apps eliminate the native source editor altogether?
• For editors who have tried editing on the app: at what point did the experience fall short, and would access to VisualEditor / mobile web have changed that?
• Are there aspects of the handoff from app to mobile web editor that would be most important to get right?
• What should that transition feel like? A prompt, a redirect, a clear explanation of where the user is going and why?
• For editors who guide newcomers: how often does the app come up as a first editing environment, and what problems follow from that?