[POS as a tab i1] Show POS tab for eligible stores behind a feature flag

[jaclync]

Closes WOOMOB-584

Just one review is required.

Apology for the larger diffs, ~400 diffs are about unit test changes on MainTabBarController. A few cases in MainTabBarControllerTests were flaky from CI (example in the Tests tab even though CI passed) and locally when running the test class repeatedly for 10+ times. When a test case has waitUntil, if the main thread is occupied by other operations like from leftover previous test cases, waitUntil can become unresponsive and not be able to check the condition as expected. From debugging for a few hours, I noticed that instances of MainTabBarController from previous test cases were not deallocated. And because of a combination of ServiceLocator usage and the shared SessionManager database in tests, the site ID from previous and current test cases could trigger site ID changes observed in MainTabBarController in the unintended instance (e.g. the current MainTabBarController instance is receiving site ID from a previous test case, or previous instances are receiving site IDs from the current test case). I ended up separating a few test cases on the tabs behavior to a new test class, and with a few changes I was able to run both test classes repeatedly successfully. Please feel free to share any tips on any alternatives of waitUntil or the test setup.

Description

This pull request introduces a new feature to display the Point of Sale (POS) as a tab in the tab bar, contingent on a feature flag and user eligibility. It includes updates to feature flag handling, POS tab integration, and adjustments to existing tab bar functionality. Below is a summary of the most significant changes grouped by theme.

Feature Flag Updates

• Added a new feature flag, pointOfSaleAsATabi1, to control the release of the POS tab. (Modules/Sources/Experiments/FeatureFlag.swift - [1] Modules/Sources/Experiments/DefaultFeatureFlagService.swift - [2]

POS Tab Integration

• Implemented POSTabCoordinator and POSTabViewController to manage the behavior and presentation of the POS tab and the full-screen POS UI. (WooCommerce/Classes/POS/TabBar/POSTabCoordinator.swift - WooCommerce/Classes/POS/TabBar/POSTabCoordinator.swiftR1-R152)
• Updated WooTab enum to include the pointOfSale case and added logic to manage its visibility dynamically based on eligibility. (WooCommerce/Classes/ViewRelated/MainTabBarController.swift - [1] [2]

Tab Bar Functionality Adjustments

• Modified MainTabBarController to observe POS eligibility and dynamically update the tab bar to show or hide the POS tab. (WooCommerce/Classes/ViewRelated/MainTabBarController.swift - WooCommerce/Classes/ViewRelated/MainTabBarController.swiftL602-R684)
• Added delegate handling to prevent direct selection of the POS tab and instead trigger the associated coordinator's behavior. (WooCommerce/Classes/ViewRelated/MainTabBarController.swift - WooCommerce/Classes/ViewRelated/MainTabBarController.swiftR295-R305)

Hub Menu Updates

• Adjusted HubMenuCoordinator and HubMenuViewModel to account for the new POS tab feature flag and ensure compatibility with the updated tab bar logic. (WooCommerce/Classes/ViewRelated/Hub Menu/HubMenuCoordinator.swift - [1] WooCommerce/Classes/ViewRelated/Hub Menu/HubMenuViewModel.swift - [2]

Steps to reproduce

Prerequisite: a WPCOM account that has at least two connected stores, one eligible for POS and the other one not eligible.

• Log out if needed
• Log in to the account in the prerequisite with the store that is eligible for POS --> after logging in, the POS tab should appear shortly
• Go to the Menu tab --> there should be no POS entry point even after some wait
• Tap on the POS tab --> it should launch POS in full-screen
• Feel free to add item(s) to cart and complete a cash/card payment
• Exit POS
• Go to Menu tab and switch to a store ineligible for POS --> after switching stores, the POS tab should not appear even after a while
• Go to the Menu tab --> there should be no POS entry point even after some wait
• Switch to a store eligible for POS again --> after switching stores, the POS tab should appear shortly
• Tap on the POS tab --> it should launch POS in full-screen
• Exit POS
• Relaunch the app --> the POS tab should be hidden first, then appears shortly

Screenshots

Only the "Sweet Maple Store" is not eligible for POS.

Simulator.Screen.Recording.-.iPad.A16.-.2025-06-13.at.13.38.00.mp4

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[dangermattic]

	1 Warning
⚠️	This PR is larger than 300 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	30415
	Version	PR #15726
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	214e1e3
	Installation URL	3ujl4uhrjh6qg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[joshheald]

Works as described. I tested on an iPad running iOS 17.7.2, and an iPhone running 18.5, and an iPad simulator running iOS 16.

I tested with various combinations of currency, country, device type, and OS – the tab shows when it should and doesn't when it shouldn't.

I checked the analytics events were still correctly annotated, and that card payments are still correctly cancelled/order state reset when leaving POS.

I'm just wondering whether/when we plan to make the tab bar stable again?

I do think it's worth delaying the load until we can determine eligibility – a jumpy UI doesn't give a good impression of the app.

If we really can't do that now, it might be a bit better if we could animate the insertion of the tab.

[joshheald]

Have you investigated whether we can avoid this? Is it planned for a later iteration?

It would really be preferable to avoid the tab bar jumping around like this... if we release it this way it's kind of annoying and doesn't seem like the best impression for POS!

[jaclync]

In i2 from the delivery plan pdfdoF-7po-p2, the POS tab visibility check is reduced to two API requests:

• Remote feature flag: as we discussed in the team meeting, we're keeping this check in case of critical POS issues for certain app versions
• General WC site settings for store country: ideally we can reuse the site settings fetched from other API requests made during site initialization

For i1 / initial implementation, we're hiding the POS tab by default just so that it isn't shown for ineligible stores pdfdoF-7mo-p2#ui. But as you and Povilas mentioned during PR testing, plus my own testing, I'm not liking this UX. In my next task WOOMOB-599, I'm exploring caching the POS eligibility per site and using the cached value while checking eligibility async. For most of the sites, this value is hopefully rarely changed.

[jaclync]

Thank you for the thorough testing Josh!

I'm just wondering whether/when we plan to make the tab bar stable again?

I do think it's worth delaying the load until we can determine eligibility – a jumpy UI doesn't give a good impression of the app.

I personally don't think it's worth delaying the tab bar initial state just for POS eligibility checks, at least for i1 with eligibility dependence on several API requests. Most of the merchants aren't using POS at this point. The current eligibility delay is noticeable and will make the app feel slower with potential feedback in reviews and support tickets. For i2 maybe, or we can consider always showing the POS tab for all stores and inform them about the ineligibility reason. In this case, a setting to hide the POS tab in the app might help with the UX like for stores in ineligible countries. WDYT?

If we really can't do that now, it might be a bit better if we could animate the insertion of the tab.

Great suggestion, I haven't thought about animating the tab changes and will look into it this week.