STO Apps

Native apps for the classroom and the cart.

School Tech Ops is a management platform. These are the apps that sit at the other end of it — on the iPad clamped to a stand at the front of a room, on the Apple TV in a district office, on the phone in a maintenance van. Each one exists because a commercial app either could not be bought, could not be modified, or could not be pushed to managed devices the way a district needs.

Overhead

iPad · document camera and lesson tool · Pilot

Overhead turns an iPad into a document camera. Point it at a worksheet, a textbook page or an object on the desk and the class sees it on the projector or TV. Freeze the page, mark it up, keep it, and use it again next year.

It replaces a free App Store document-camera app that was already on the carts. That app works well enough, but it cannot be modified, cannot be bundled into a managed build, and cannot grow the features teachers kept asking for. Overhead started as feature parity with it and went well past.

The camera

Marking up

Keeping and reusing

Bringing documents in

An honest limitation

Slides arrive as pages, so animations and click-through builds are flattened — a slide that revealed four bullets one at a time shows all four at once. Overhead says so on import and points at its own reveal mechanism instead, where a region of a page is hidden on the class display and visible on the teacher's iPad until they choose to show it.

Saving out

The rest of the family

Same conventions, same distribution route
AppPlatformWhat it doesStatus
OverheadiPad Document camera, markup, lesson pages, slide decks Pilot
Overhead BuilderMac Builds Overhead lesson documents on a laptop, where a keyboard and a big screen make layout far quicker than on an iPad In build
CCTV WallApple TV A camera wall on an office television, driven by a screen configuration served from the platform; grid layouts and rotation, locked to a single app by MDM In build
iPad AdminiPad Field tool for device work — enrolment, checks and reconciliation against the management systems In build
Door ControlleriOS & Mac Access-control operations against the door system from a phone or a desk, rather than a fixed workstation In build
Student CompanionWeb Turns the class's own devices into an interactive whiteboard: students answer on their device, the teacher decides what the class sees Prototype
NutritioniOS Food-service operations for kitchen staff Prototype
MileageiOS Staff mileage capture and submission Prototype
Print AdminiOS Print-fleet visibility and queue management on the move Prototype
TasmanceriOS Controls Tasmota smart devices across district buildings Prototype

How they're built

One set of conventions across every app in the family

Swift and SwiftUI throughout

Native, current-generation Swift with strict concurrency checking on. Observable view models with services injected behind protocols, so behaviour can be tested without a network, a camera, or a signed-in account.

Projects are generated, not committed

A declarative project file is the source of truth and the Xcode project is regenerated from it. Signing configuration is kept out of the repository entirely, beside a committed template.

Shared code lives in packages

Document models, geometry and file formats sit in local Swift packages shared between an app and its companion tools, so an iPad and a Mac cannot drift apart on what a lesson file means.

Tests where they can actually prove something

Model and persistence logic is covered by unit tests; the parts that only fail on real hardware are tested on real hardware, and the difference is documented rather than assumed.

No third-party SDKs

Overhead has no external dependencies at all. Integrations talk to published web APIs directly, which keeps analytics, trackers and someone else's release schedule out of a device a child is sitting in front of.

Privacy by construction

Camera frames, pages and scans stay on the device unless a teacher chooses to save or share them. No analytics, no advertising identifiers, no accounts of the app's own, and no backend of ours in the middle.

How they reach devices

Private distribution, managed configuration

These are not public App Store products. They are distributed as Custom Apps through Apple School Manager — private to the district that commissioned them, never publicly listed — and then scoped in the MDM exactly like any other managed app. Licences are assigned to a location and the app is pushed to a device group.

Anything a district needs to vary is delivered as managed app configuration rather than something a teacher has to type: which identity provider to use, which domains may sign in, where uploads should land. Values pushed by the MDM take precedence over anything set in the app, and the app shows them read-only with a note that the district set them.

Why not the public App Store

A tool built around a district's own identity provider, roster and device fleet has no meaning outside it — a stranger downloading Overhead could point a camera at a page and nothing else. Private distribution keeps the review process without pretending the app is a consumer product.