Tabbed Browsing introduces multi-article navigation to the Wikipedia iOS app, enabling readers to open and switch between several pages seamlessly, enhancing discoverability, supporting deeper exploration, and aligning with the Foundation’s goal of improving on-platform reading experiences.

We have over 150 specific user requests to introduce tabbed browsing similar to the Safari web browser and the Android Wikipedia app.Data from the Android app indicates that tabs are the most frequently engaged-with feature after Search and the Explore feed (which appears upon app launch).

Currently, Android users use tabs to navigate Wikipedia efficiently and often share their tabs as representations of their reading habits and exploratory journeys.With the upcoming work on iOS app navigation, we can introduce tabs here as well.

This initiative aligns with Objective 3.1 of the Wikimedia Foundation’s Reader and Donor Experiences annual plan, which focuses on developing on-platform browsing experiences that make content easier to discover, reduce reliance on external search platforms, and enhance reader retention.

Adding tabbed browsing aligns with Objective 3.1 to make Wikipedia a preferred destination for engaging with encyclopedic content and to develop on-platform browsing experiences that enhance content discovery, reduce reliance on external search platforms, and retain new consumers.

WE 3 Objective: A new generation of consumers arrives at Wikipedia to discover a preferred destination for engaging with encyclopedic content.

WE 3.1 Key Result: Release two curated, accessible, and community-driven browsing and learning experiences to representative wikis, aiming to increase logged-out reader retention by 5%.

1. If we develop and test design prototypes for tabbed browsing in the Wikipedia iOS app, we will gain actionable usability insights, allowing engineers to assess the technical feasibility of different approaches and laying a solid foundation for implementing tabs in Q4.

2. If we introduce Tabs into the iOS app to improve the browsing experience, users will engage with the feature over multiple days, and we’ll see a comparable or higher 2-day feature retention rate to the Android Tabs feature.

Validation

• [Primary metric] KR 1.1 Tabs users have a 1% higher app retention rate
• [Adoption] KR 1.2 5% of unique users who have tabs available to them have opened an article from the Tabs overview, or have opened the Tabs overview

Guardrails

• 60% of users rate the feature as neutral or satisfactory (as measured by in-app survey)
• No more than 5 user complaints about performance declines or increase in cellular data to support Tabs (as measured by engineering, and user feedback)

Curiosities

• How much higher were the pageviews/unique users for unique users who engaged with Tabs compared to non-Tab users in target audiences?
• Did we see any decrease in uninstalls for target audiences?
• How does iOS’s adoption/engagement rate for Tabs compare with Android?
• What other functionality are users looking for from Tabs? (survey responses)

• Users can navigate back to the main views (Explore) from Tabs
• Access to tabs from all main views (consistent header as part of Navigation refresh)
• Most recent tabs are visible on screen when opening Tabs
• Show preview of content for each tab (Article title, first few lines of article, image if available)
• Indicate open tabs in global search and allow users to switch to already open tabs
• Tab should remember a user’s last position in the page and display it again on subsequent views of the tab
• Allow opening an article in a new tab after long-press on any article link (in article view, explore, saved, history, search)
• “New tab” option
• Show number of open tabs
• Users can close individual tabs
• Users should be able to have up to 100 tabs (nice-to-have: no upper bound)
• Allow users to have Tabs open in multiple languages
• Filter out non-article detours (talk pages, article history, files)
• In-app survey to measure satisfaction and receive feedback
• New feature announcement or tooltip (iOS + iPadOS)
• Onboarding to Tabs - highlight the “long press”
• Using tabs should not significantly increase the local storage or cellular data used by the App, or slow down the performance of the app

T229502 - iPadOS - handling multiple windows.

• While reading an article on Apple, I want to open links to Steve Jobs, Cupertino, and iPhone into separate tabs so I can read them later.
• As a reader, I want the Wikipedia App to have tabs like Safari or Chrome, so I can keep all my Wikipedia reading organized and private.
• As a student, I want to switch between multiple articles while keeping my place, so I can gather notes and sources for research.

• Japanese and English readers in the ESEAP region.
• Arabic and English readers in the Middle East and North Africa.
• German readers in Germany

• Diverse in:
  • Age.
  • Education.
  • Gender identities.
  • Accessibility needs (e.g., screen reader users).
  • Language orientation (Right-to-Left vs. Left-to-Right users).

For further details and to follow the work, see the related Phabricator Epic Ticket:T384758.

• KR 1.1 Logged-out users who have access to Tabs have a 1% higher cumulative app retention rate compared to users who did not have access to Tabs (control)
  • Actual: We saw an increase of 0.14% for test group users app retention rate compared to control, this difference was not statistically significant
• KR 1.2 At least 30% of users who engage with Tabs return to use the feature on more than one day
  • Actual: We saw 24% of Tab Overview Uniques feature return rate overall. Logged-in users had a higher return rate of 32%, comprared to logged-out users who had a 24% feature return rate
• KR 1.3 1 At least 20% of active/exposed users with access to tabs, engage with the feature
  • Actual: 9.6% of test group users saw the Tabs Tooltips engaged with Tabbed Browsing features. Logged-in users had a higher engagement rate of 23%, compared to logged-out users at 9%.

• 60% of users rate the feature as neutral or satisfactory (as measured by in-app survey)
  • Actual: The satisfaction rate was 93%.
• No more than 5 user complaints about performance declines or increase in cellular data to support Tabs (as measured by user feedback)
  • Actual: We had no user complaints about performance declines or increase in cellular data

• Did we have a higher % of internal referral clicks from the variant group compared to control?
  • Yes, the group with access to tabs had a 1.3% higher average Internal Referral clicks per unique user compared to Control
• Were there any differences in logged-in vs logged-out users?
  • In both control and variant groups, logged-in users have a higher return rate compared to logged-out users. Logged-in users had a much higher engagement rate with tabs (23%) compared to logged-out users (9%).
• How does iOS's usage and adoption of Tabs compare with Android?
  • Tabs is a mature feature that has been availalbe for more than 5 years on the Android App, so we can expect rates to be higher. Adoption of Tabs on iOS is lower than on Android. iOS Tab Engagement Rate is 10% compared to Android Engagement Rate of 19%. The Android Tabs feature also has a higher return rate, at 56% for logged-out users, compared to iOS's 23%.
• Did we see any decrease in uninstalls for target audiences?
  • According to AppStore Data, we did see a 12% decrease in uninstalls during the experiment duration for users in the same experiment target countries.
• What other functionality are users looking for from Tabs? (survey responses)
  • User feedback included requests to
    • Make it more simlar to Chrome tabs
    • Anchor open tabs to the topic from which they were opened
    • Allow users to toggle the Tabs feature on and off
    • Let users set up reminders, and receive prompts to read open tabs they haven't gotten to yet

• We released the experiment into beta and production! The experiment is live for users with an app primary language of English, Arabic, or German, and with a device country of Germany, or within the ESEAP or MENA regions (T396055).
• In addition to testing recommendations within tabs, the experiment also adds several other improvements to the tabs user experience, including highlighting the active tab (T405537), allowing users to close all tabs (T398881), and allowing users to long-press previews on tabs.
• We are continuing to see requests for “close all tabs” come in through the app store reviews. If the results of the experiment are unclear, we will expedite releasing the close all tabs flow.

• After hearing user feedback about difficulty closing tabs, we increased the touch target to close tabsT404102
• We also solved these tabs-related bugs:
  • Tabs were not all the same size on iPad miniT396644
  • Tabs tooltip was causing issues after initial scrollT403998

• We began working on improvements to the Tabbed browsing feature, our work is coordinated on this Epic:T396055

• Tabbed browsing was released into production as an A/B test. We’re monitoring the test, and will share results soon.T384758
• We began working on iterative improvements to Tabs on this Epic:T396055
• We finalized designs for our new tab improvements, we will test two versions against control.

• We explored the usage the Android tabs feature to check our scoping decisionsT396052
  • We decided to focus on improving that experience, and this still feels like the right choice after seeing that:
    • 38.4% of Android Tab users use "new tab" option in the tabs overview
    • 8.9% of all tab overview events (impressions) to open the tab overview had "new tab" events
  • We decided not to invest time into the “Save all tabs” to a reading list feature, and data from the Android feature validated that decision:
    • Only 0.4% of all tab users have used "Save all tabs" on Android

• We solved the following bugs:
  • Can't open other tabs or new tab after closing the current tab.T396160
  • Crash after deleting a tab.T394682
• Our designer completed usability testing on the updated “new tab” experience options.
  • We found that:
    • Users generally open new tabs several times a day
    • Many users sometimes engage with suggested articles if something catches their eye or if it’s what they were already looking for
    • Many users want to see information related to previous searches or subjects of interest, trending pages, or recommended pages
    • Most users liked the personalization and variety offered by the feed option
    • Most users wanted the ability to customize the modules on display and their arrangement
    • Most users prefer the content in the feed to refresh every time the app is opened
    • DYK was also highly popular, with users finding it fun and engaging, a good way to learn new facts daily
    • DYK and the feed were seen as fitting with Wikipedia’s purpose of learning and information
    • Many users believed it would make them open the app more often
    • Other suggestions for improvement: incorporating an AI chat widget, breaking news
  • Our recommendations from this testing that we’re taking into developing our designs:
    • 1. 1 — Move forward with DYK and Feed variants
      2. 2 — Maintain the inclusion of the "Based on your reading," "Continue reading," and "Reading report" modules within the Feed variant
      3. 3 — Ensure ability to customize modules within the Feed variant, allowing users to rearrange and turn on/off modules to suit their preferences
      4. 4 — Refresh content upon every new tab open

• We released tabbed browsing into Beta! We plan to run an A/B test in select regions and languages before making it widely available.

• Here are the final designs for iOS tabs that will be implemented in May/June 2025.

• 
  Discovery tooltip 1/2
• 
  Discovery tooltip 2/2
• 
  Tabs entry point in the article
• 
  Tabs entry point in Places
• 
  Tabs entry point on Explore
• 
  Tabs entry point in History
• 
  Tabs entry point in Search
• 
  Tabs entry point in Saved
• 
  Long press in the article
• 
  Long press in Places
• 
  Tabs overview
• 
  Overflow menu in overview
• 
  Landscape designs for tab overview
• 
  Long press on tab item
• 
  New tabs open the main page
• 
  Satisfaction survey after using tabs
• 
  iPad design of article view
• 
  iPad design of overview

• Our engineers completed exploration work to ensure that adding tabs does not significantly increase data usage, and how we can track the data usage of the app,T386365
• We explored Android Tabs usage and examined some baseline usage numbers to inform our work on iOS
  • 20% of Android users open tabs overview in a given month. Of those who engage with Tabs, 30% come back to use it again within 2 days.
  • Android Tabs users retain at a higher rate than our baseline. Users who engage with tabs have a higher overall app retention (61%) compared to the overall average for the Android app of 48%. This doesn't show causation however, because Tabs users may already be more engaged users. Our A/B test on iOS will help us validate or disprove if offering Tabbed browsing leads to increased retention to the app.

• Our engineer created a prototype, and this allowed us to work through navigation questions, and performance concerns

T386365

• We completed usability testing for Tabs with the prototype and designs, and results were shared on this phabricator task:T389390. Our recommendations from the user testing were:
  • Keep the current back behavior that takes users back across tabs as a tab-agnostic back behavior has only been mentioned by 1/13
  • Always show the label of the previous destination next to the back button to make navigating articles easier. It has helped users immensely to navigate the prototype and understand what happens. It is recommended that the destination is always displayed on the back label. If the label is too long, apply truncation.
  • Introduce interface feedback (e.g. animation) when a new tab opens on the tabs icon so users realize that a new tab has opened (similar to Wikipedia on Android). Some users didn’t realize the tab opened in the background since the interface didn’t respond.
  • Related: Provide two options after the user’s long press: "Open in new tab" and "Open in new background tab"
    • Change the default tab behavior ("Open in new tab") to open the new tab and navigate to it.
    • Some participants expected to navigate to the tab after tapping the link.
    • Alternative: Introduce foreground/background tab setting (not recommended) as a user’s preference could vary per click.
  • Onboarding: show a tooltip for both the tabs overview and opening new tabs (use two contextual onboarding tooltips, with a "next" button and, e.g. 1/2 and 2/2 indicators)
  • For a future version, this could be considered:
    • Support gestures to move between tabs
    • Auto-close setting for tabs
    • Consider adding a link to reading history in the tabs overview more menu as it’s related
• We also reached out to users who have requested Tabs in the past to share the usability testing opportunity with them.

• We began working on Tabbed browsing (tabs)! Our designer analyzed user feedback from both iOS and Android to understand what users need and want from Tabs, created wireframes, and our lead engineer created a prototype. We began running user testing with our prototype and wireframes.T384758.

• 
  Screenshot that shows how to start using the tabs feature in the Wikipedia iOS app
• 
  Open an article in a new tab
• 
  List of six open tabs
• 
  Showing the options to save or close all tabs
• 
  Tabs Menu
• 
  Showing the open tabs while searching Wikipedia

• Here’s a summary of user feedback we reviewed:
  • From iOS users:
    • Lots of users mentioning tabs in their reviews switched from Android to iOS
    • Many of the lower rated reviews are related to the lack of tabs
    • Tabs are essential for rabbit hole journeys
    • Should work like web browser tabs (mentioned the most: like Safari, or Chrome)
    • Tabs should remember scroll position
    • Switching tabs with as little taps as possible (consider swipe gestures on address bar)
    • Users are asking for link previews (consider introducing setting)
    • Bottom navigation for tabs is expected (consider customization for top or bottom bar or additional tabs button in more menu)
    • Users asking for offline tabs
    • Make searching articles easy (consider adding the global search bar to the tabs view as well or active search on new tab)
    • Make the feature as discoverable as possible (since it hasn’t been present on iOS)

• • From Android users:
    • In general tabs should work like in Google Chrome
    • Handling of opening tabs could be optimized
    • Buggy: apparently it sometimes overrides or closes existing tabs
    • Stacked tabs is preferred over tile tabs design (maybe just bc of change-averse)
    • Manual control over tabs (when to open a new tab should be decided by user)
    • Closing multiple tabs should be possible
    • Settings (e.g. for stacked/grid view or open a new tab)
    • They want more than 100 active tabs
    • Overriding tabs when the limit is 100 could be improved (consider mitigating by informing users or save to reading list feature)
    • Setting to close tabs after x days or after app closed
    • History within a tab is important to users (consider browser back button in addition to the app back button)
    • Users requested tab groups/categories
    • Gesture based navigation, move tabs to the bottom for easier access