One app, four platforms: how we ship to web, iOS, Android and Windows at once
TradeYoke's web app and native apps are the same code. Here's what that buys customers — and the rules we follow to keep it true.
Quick answer: TradeYoke is one shared codebase rendered on the web and packaged as native apps for Windows, Android and iOS, rather than four separate products built to look alike — a feature written once for the web is, by construction, the same feature on every other platform, not a separate rebuild that might drift out of sync.
Key takeaways
- Every screen lives in one shared component library; the web server, the browser and the native apps are thin shells around the same code.
- A fix or a new feature ships to every platform together, because there is only one place it lives.
- The installed native apps work offline, and since November 2026 the web app keeps working with no signal after one visit too.
- Platform-specific things — the camera, GPS, file pickers — go behind one shared interface with a separate implementation per platform, never a special case in the shared screens.
- A missing platform implementation is treated as a bug to fix, not a "coming soon" to ship around.
The rule: one codebase, four faces
Most software that claims to run "everywhere" actually means two or three teams building look-alike apps against the same backend, which is how a mobile app quietly falls a version behind the web version, or gains a feature the web version never gets. TradeYoke doesn't work that way. Everything a user sees — the schedule, the job wizard, the invoice screen — lives in one shared component library. The web server, the browser (running the same code client-side), and the native Windows, Android and iOS apps are thin hosts around those same components. A feature built for the web is therefore, automatically, the same feature everywhere else, because there is no second version of it to fall behind.
What it means day to day
For the person using it, the practical difference is that there's no "that's only on the desktop version" moment. The office, planning the week on a monitor, and the person in the van, checking the same job on a phone, are looking at the same screen doing the same things — not a cut-down mobile view that's missing half the buttons. When something is fixed or improved, it reaches every platform in the same release, not the web this month and the app "eventually". And because the phone and Windows apps are properly installed, native apps rather than a web page wrapped in a shell, they carry TradeYoke's offline support: the day's jobs, customer records and prices are available and editable with no signal, syncing automatically once a connection returns. The browser-based web app is a little different: since November 2026 it keeps working with no signal after one visit, but a browser keeps your work less safely than an installed app does, so the apps remain the better place to carry a round.
The discipline it takes to keep it true
The rule only holds if it's enforced, so platform differences — the camera, GPS, a file picker, push notifications — are never called directly from the shared screens. Each goes behind one shared interface, with a separate implementation supplied by each platform: the web version might use a browser API, the native version the device's own SDK, but the shared component never knows or cares which one is underneath. A platform that hasn't got its own implementation yet is treated as an unfinished bug in that interface, not a reason to write a special-case branch in the shared code — the moment a screen starts asking "which platform am I on", the one-codebase promise starts breaking, so that question is never allowed to appear outside the interface boundary itself.
Why this matters for a trade business, not just for engineers
The instinct is to treat "one codebase" as an implementation detail that only interests developers, but it's the reason a business running TradeYoke never has to plan around a feature gap between "the app" and "the website". A team member who prefers a Windows laptop, one who lives on Android in the van, and an office manager who only ever opens a browser are all working from the same data, the same screens and the same day's plan — there's nothing to keep in sync between them because it was never four things to begin with.
Questions people ask
Does the web app have fewer features than the native apps?
No — the same shared screens render on both; the meaningful difference is how offline support is kept: the installed native apps keep it on the device and send changes in the background, and the web app keeps working with no signal after one visit too, not a stripped-down web experience.
If I use the app on Windows and my colleague uses Android, do we see the same thing?
Yes. You're both running the same shared components against the same data; the only difference is the device drawing them.
Does a new feature ever appear on one platform before another?
The intent of building this way is that it doesn't — a feature is written once in the shared layer and ships wherever that layer runs. Platform-specific plumbing (like a device capability) can take a release longer on a platform that needs its own implementation, which is treated as a gap to close, not an accepted permanent difference.
Does the web app work offline like the phone app does?
A browser tab cannot promise as much as an installed app that data survives being closed, losing signal or being reopened days later. TradeYoke's installed apps on Windows, Android and iOS keep that support on the device, and since November 2026 the web app keeps working with no signal after one visit too, with a weaker copy on the device.
