Skip to main content
Howarth Games Logo Overlay

OneFile

Manchester — twelve years of replacing paper with software

OneFile

OneFile builds the software that apprenticeships and vocational training actually run on. A learner keeps a portfolio. They attach evidence to it — a photograph taken on site, a document, an observation written up by somebody who watched them do the thing. An assessor reads it and signs it off. And when an inspection comes, the whole trail has to be there, in order, and has to agree with itself.

All of that used to be paper. A ring binder per learner, carried out to a workplace and carried back again, and a filing cabinet somewhere holding the ones that mattered. Replacing that with something a person can carry in a pocket is the whole point of the company, and it is the sentence I would use if I had to explain the job in one line.

The company is in Manchester and has been for the whole time I have been with it. I joined in June 2014 and I am still there — twelve years, which makes it the second longest stretch on this site and the only one that has not finished yet.

What I do there

Senior Mobile Developer — iOS, cross–platform and API

June 2014 to now · Manchester · hybrid

iOS to begin with, written in Objective‑C. Cross–platform after that — JavaScript, AngularJS and Ionic — and the API work behind it in .NET and C#. Then Xamarin, and now .NET MAUI. The job title has stayed more or less still while almost everything underneath it has been replaced at least once.

One part of a much bigger product

What most people mean by OneFile is the web product, and it is a great deal larger than the app. It runs in a browser, it assumes a connection, and it covers the whole of what an organisation needs to run its training — far more than anybody would sensibly want to carry around on a phone.

The app is deliberately a part of that rather than a copy of it. It carries the things that have to work at the point where the work is actually happening: capturing evidence, and creating assessments and reviews. What it offers in exchange for the smaller surface is the one thing the web product cannot do at all — it works with no signal.

That trade is the whole design. The smaller surface is not a compromise, it is the point, and it is what lets the app promise something the larger product cannot. It is also why the few things it does carry are harder to build than the many it leaves out: everything in it has to survive being made on a phone that is entirely on its own, and be reconciled afterwards without anybody losing anything.

The app as one part of the larger web product A large outer box standing for the web product, which runs in a browser and assumes a connection. Inside it, a smaller shaded box marks out the app: capturing evidence, creating assessments and creating reviews, and working with no signal. The rest of the outer box, drawn as a stack of empty rows, is everything else the product does and the app deliberately leaves out. The web product — in a browser, online, and much larger everything else the product does the app capturing evidence creating assessments creating reviews — and all of it with no signal The app is a part of the product, not a copy of it — the part that has to work where there is no connection
Smaller on purpose. The box inside is the part that has to keep working when the network does not, which is what makes it the harder half to build rather than the easier one.

One product, rebuilt three times

The interesting thing about twelve years on one product is that the product has outlived three of its own implementations. The thing a learner sees has been recognisably the same all the way through — their portfolio, their evidence, the assessor who signs it — while the code underneath has been rebuilt more than once.

It started native, in Objective‑C, on iOS only. That is the fastest a phone app gets and the closest you can sit to the platform, and the price is that everything is written twice the moment somebody wants it on Android. Then it became a web application in a native shell — Ionic and AngularJS — which is one codebase for both platforms and a different set of compromises: you get reach, and you give up some of the directness. Then C#, first with Xamarin and now with MAUI, which is where it lives today and which has the quiet advantage that the app and the API behind it are finally written in the same language.

None of those moves was fashion. Each one was a bet about where the platform was going, made with a product already in people’s hands and real portfolios already inside it — which is the part that makes it hard. A rewrite with no users is an exercise. A rewrite underneath live data is a migration, and the evidence a learner has already gathered has to come through it untouched, because it is their qualification and not your codebase.

The same app rebuilt three times over twelve years Four phones in a row, each standing for one generation of the same app. The first is the original native build, written in Objective-C and running on iOS only. The second is Ionic and AngularJS, web technology inside a native shell, giving one codebase across two platforms. The third is Xamarin, moving the app to C# with a shared core behind a native shell. The fourth is .NET MAUI, where it runs today, with the app and the API behind it finally in the same language. The screen contents stay the same across all four, because what the learner sees did not change. Native Objective‑C iOS only from 2014 Ionic + AngularJS JavaScript one codebase, two platforms Xamarin C# shared core, native shell .NET MAUI C# same language as the API
Four implementations, one product. The screen is deliberately the same in all four: what the learner sees is the thing that was not allowed to change.

A day’s work without a connection

Evidence is captured where the work happens, and the places where the work happens do not have signal. A building site. A commercial kitchen. A salon, a workshop, a ward, a farm. Somebody is standing in front of the thing they need to photograph, and there are no bars.

So the app is built around a working day rather than around a connection. In the morning, while there is still signal, an assessor takes down out of the main ePortfolio web product what the day is going to need — the people they are seeing, the assessments and reviews already in the diary, and the material all of that depends on. Then they go out.

For the rest of the day the phone is on its own, and it is not a lesser version of itself while it is. The items brought down that morning are worked through. Evidence is captured — photographs, video, notes written at the moment somebody actually did the thing. New assessments and reviews are created from nothing. None of it is a request queued up waiting for a network: it is all real, finished work, sitting in the phone’s own database and complete as far as the person who did it is concerned.

Then, whenever they are back in signal — the office, a car park, home that evening — the whole day goes up. What came down in the morning returns with whatever was done to it, and everything created out there is added to the web product as though it had been made there all along.

It is worth being plain about what the phone is talking to. The server is not a separate thing built for the app: it is the main ePortfolio web product itself, the same one an assessor would otherwise be sitting in front of in a browser. The app is that product’s offline subset, which means everything it sends has to land as a first–class part of it rather than as something bolted on beside it.

That last step is where the difficulty lives, and it is the standing problem of any offline–first application rather than anything peculiar to this one. A record has to have an identity before the server has ever heard of it, and another one once the server has. Keeping those two straight, and keeping every reference between records pointing at the right one, is most of what makes offline sync hard wherever it is done — and it is why the interesting work sits in the reconciliation rather than in the screens.

How a working day runs on the app Three stages of a day, left to right. In the morning, still in signal, the phone takes down from the main ePortfolio web product what the day is going to need. During the day there is no connection at all, shown by a crossed-out link to a greyed-out web product box, and the phone works alone: the items brought down are used, and new ones are created and shown in solid black. Later, back in signal, the arrow reverses and everything goes up — what came down in the morning along with whatever was done to it, and everything made during the day. Morning, still in signal the ePortfolio web product take down what the day needs: the visits, and what they rest on The day, no signal at all the ePortfolio web product capture evidence, and create assessments and reviews Later, back in signal the ePortfolio web product all of it goes up, including what only existed on the phone
Down in the morning, alone all day, up in the evening. The solid rows are the work that only ever existed on the phone until the last step.

What the job actually is

People assume mobile work is screens. Some of it is. But the thing that decides whether this particular app is any good is what happens at the edges — the sync that half finished, the phone that ran out of battery mid–upload, the record that was edited in two places before the two places had ever spoken, the migration that has to move a database forward a version without a single learner noticing.

It has more in common with the machines at Barcrest than it looks. Both are things where being approximately right is worthless, and where the correct failure is to stop and say so rather than to carry on and be quietly wrong. A gaming machine must never pay out when it is confused. An e–portfolio must never lose a piece of evidence, or attach it to the wrong person, and it must be able to prove afterwards what happened and when.

Before OneFile

Before this came fourteen years at Barcrest in Ashton–under–Lyne writing gaming machines, and before that Software Creations in Manchester, where the Commodore 64 games on this site were written. The iPhone apps are what I do outside it.

The dates and job titles here are my own record. What the company does is described in my own words rather than its marketing, and nothing on this page is written on its behalf or discloses anything confidential — it describes my own work in general terms, and the engineering problems on it are ones common to the whole industry. If any of it reads wrong, tell me and I will put it right.

Featured posts