Variable products in a mobile app, done properly

By Abdalla Kamesh · Updated September 25, 2026 · Published September 13, 2026 · 5 min read

If you sell clothing, anything in multiple colors, or anything sized, variable products are most of your catalog — and the variation picker is the single screen where an app either feels professional or feels like a form.

This is what “handles variable products” should actually mean, so you can check it rather than take it on trust.

What WooCommerce gives the app to work with

A variable product in WooCommerce is a parent product plus a set of variations. The parent carries the title, description, images and the attributes (Color, Size). Each variation is a real combination — Blue / Medium — with its own price, its own stock, sometimes its own image, and its own SKU.

Which means the app has four things to get right: showing the available options, showing the correct price as options are chosen, showing what is actually in stock, and swapping the image when a color is picked.

The seven things a good variation picker does

1. Shows a price range before anything is selected. If your variations run $39–$59, the product page should say so rather than showing the lowest price and surprising people. WooCommerce exposes the range; an app should use it.

2. Updates the price the moment a combination resolves. Pick Blue, pick Medium, price becomes $49. Not on add-to-cart. Not after a spinner.

3. Uses swatches for color and buttons for size. A dropdown for color is a web form pattern that works badly on a phone. Colors should be visual — an actual color chip or a thumbnail — and sizes should be tappable buttons in a row.

4. Disables impossible combinations rather than failing on them. If Blue exists only in Small and Medium, choosing Blue should visibly gray out Large. A picker that lets you pick Blue/Large and then errors is the most common variation bug in store apps.

5. Shows per-variation stock. “Only 2 left” on the specific variation, and out-of-stock sizes marked as such before the tap. Per-variation stock is where a bad implementation loses orders it will never know about.

6. Swaps the gallery image with the selection. Pick the green one, see the green one. WooCommerce supports per-variation images; not using them makes a catalog feel generic.

7. Preselects nothing — unless there is exactly one option. Preselecting a size the customer did not choose produces returns.

Test all seven on any app builder’s demo. It takes two minutes on a single product and it is the most informative two minutes in an evaluation.

The WooCommerce side: get your attributes right

Most variation problems in apps trace back to how the store is set up, not to the app:

Use global attributes, not custom per-product ones. WooCommerce lets you define attributes on a single product ad hoc. It works on the web and it produces a mess anywhere else, because “Colour” on one product and “Color” on another cannot be filtered together. Define Color and Size once under Products → Attributes and reuse them.

Give color terms a consistent vocabulary. “Navy,” “Navy Blue” and “Dark Blue” as three terms means three filter entries for one color. Filters are only as good as your terms.

Generate all the variations you actually sell, and only those. A parent with 60 auto-generated variations of which 12 exist gives the picker 48 dead ends to disable.

Set prices on every variation you sell. A variation with no price cannot be bought and shows up as a mystery in the picker.

Mark variations out of stock rather than deleting them when they are temporarily gone. Deleting loses the URL, the SKU and the “notify me” opportunity.

A tidy attribute setup improves your website’s filters at the same time, so this is not app-only work.

Where the other product types go

WooCommerce has four product types and only two of them buy natively in a phone app without compromise:

Simple products — straightforward.
Variable products — the picker above.
Grouped products — a container for other products. The app should route the customer into the child products rather than pretending the group is buyable.
External / affiliate products — the “buy” button belongs on someone else’s site, so the app should send the customer there.

In StoreToNative, simple and variable products buy natively with the full picker, and grouped and external products route to the right place automatically. Anything the app genuinely cannot render natively falls back to your store’s own page rather than breaking — which is the correct behavior for the long tail of plugin-driven product types.

Subscriptions, bookings and configurators

Be realistic here, because this is where “we support WooCommerce” gets stretched.

Product types added by plugins — subscriptions, bookings, deposits, product add-ons, custom configurators — are not part of core WooCommerce’s data model. An app can render some of them natively, and for the rest the honest behavior is a safe hand-off to your store’s own product page, where the plugin’s own interface works.

Ask any vendor what happens to your specific plugin, and ask for the answer as a screenshot. “Falls back to the web page” is a perfectly good answer. “It works” without a screenshot is not.

The QA pass before you launch

Pick five products that represent your catalog’s shapes and check each one on a real device:

A variable product with 3+ options per attribute — every combination resolves or is disabled.
A product with per-variation images — the gallery swaps.
A product with one out-of-stock variation — it is marked before the tap.
A product with a price range — the range shows before selection.
Your weirdest product — whatever plugin drives it, confirm the fallback behaves.

Then buy one of them, on a phone, with a real card.

Related reading

Swatches, the full variation picker, price ranges and per-variation stock are part of the native storefront on every plan — see the features.