Native
mobile
strategy
The marketplace's app was a web wrapper: the website in a costume. I built the case for going native, in Swift, as working software. It helped secure the investment to rebuild the app natively.
Overview
The app was a web wrapper with a structural ceiling. I built the native possibilities in Swift as working software, from in-life ownership features to the buying journey rebuilt with native materials, and it helped secure the investment to rebuild the app natively.
Client
Carwow
Role
Product Designer + Design Engineer
Timeline
2025
Platform
iOS · Swift + SwiftUI
Team
1 designer-builder
A wrapper can only ever be a mirror
The existing app wrapped the website. That ceiling is structural: a wrapper inherits every constraint of the web and none of the powers of the phone. No meaningful widgets, no haptics, no offline, nothing that makes an app feel like it belongs on a home screen. The deeper problem was behavioural. Buying a car is episodic; people do it every few years. An app that only exists for the transaction gets used for three weeks and deleted, and the platform pays to win the same person back next cycle. The strategic question was never "should the app be native". It was "what earns this app a permanent place on someone's home screen between cars".
The answer is the in-life layer: the years of ownership between one purchase and the next. I mapped the full lifecycle and designed for the gaps the web version structurally cannot serve, live valuation of the car you own, running-cost and ownership reminders, and a garage that quietly builds the case for your next change. Each in-life feature has a dual purpose. It is genuinely useful on an ordinary Tuesday, and it keeps the platform present so that when the itch to change car arrives, the journey starts inside the app rather than inside a search engine. Destination first, stickiness by usefulness, never by dark patterns.
Strategy, Native build
2025
Strategy you can hold
Strategy documents ask people to imagine. I decided to remove the imagination step. Using AI-assisted development I built the possibilities natively in Swift and SwiftUI: real screens, real motion, real haptics, running on a real phone. Not one concept but the breadth of them, the in-life garage, ownership tools, and the buying journey rebuilt with native materials, each one demonstrating what the platform gains the moment it stops renting the web view and starts owning the device. When a stakeholder holds a working future in their hand, the conversation changes. Nobody debates whether something is feasible while it is running on their phone.
The prototype did its job. Alongside a strategy deck making the commercial case, the working software made the experiential one, and together they helped secure investment from the business to rebuild the app natively. That is the outcome I care about: not a vision admired and shelved, but a funded engineering commitment with a direction of travel already validated in-hand. It also proved a working model I now use everywhere: one designer with AI-assisted build capability can produce the artefact that used to require a squad and a quarter, in 12 weeks, and de-risk the decision before the first sprint is planned.
In numbers
12+
Native concepts built
7 weeks
Idea to on-device
Funded
Native rebuild secured