Apple Apps — Lumo & Bokeh

Lumo: learning to cut towards a working core

I entered the Apple Foundation Program at UTS with product-design experience and no prior Swift background. In a team of five, I had three weeks to move from a broad health theme to a working iOS prototype. Only five days were reserved for implementation.

Our question became: how might people recognise and name what they are feeling? We used a valence-and-arousal model to place 196 emotion words on a two-dimensional grid. Instead of turning that model into a long list, we made it spatial. Colour carried emotional tone, nearby bubbles preserved context, and the selected emotion expanded near the centre of the screen.

I contributed UI design in Figma, the grid and visual language, SwiftUI implementation, and day-to-day coordination. The team cut journalling, sharing, and detailed history so we could complete one loop: explore, select, visualise, and release.

The status matters. Lumo was a working team prototype, demonstrated on iPhones at the end of the program. It was not an App Store release and it was not solely my work.

Designing a screen I knew I would later implement made me question every state, transition, and flourish. It also gave me enough SwiftUI confidence to attempt a much more technically demanding product on my own.

Bokeh

Bokeh began with a different accessibility problem: visual clutter can make it hard to decide what to act on, and an object that has been put away can become hard to recall later. I wanted to test whether a camera could narrow the scene to one thing, turn tidying into a bounded action, and leave a useful record of where that object went.

The product promise is deliberately small: clear one thing at a time.

The current build guides a user through a complete loop:

1. Point the camera at a cluttered scene.
2. Tap one object.
3. Isolate that foreground object from its background.
4. Put it away and confirm what was cleared.
5. Optionally record a location such as shelf, bag, or a custom label.
6. Find it later in the Focus Log using text or a question such as Where are my keys?

This is a working build, not a concept. The source is a single-target Xcode project for iPhone and iPad using Swift 6 and SwiftUI. It has not been released to the App Store and it does not yet have formal usability results.

The technical decisions behind the interaction

The most important product decision was to make isolation immediate and local. Bokeh captures a camera frame, uses Apple’s Vision framework to generate a foreground-instance mask, applies that mask to the image, and classifies the isolated result rather than the whole scene. The label is editable because the classifier is an aid, not an authority.

The camera pipeline forced design and engineering decisions to stay connected. A captured pixel buffer cannot simply move between queues without being copied safely. Orientation also has to be resolved before the cut-out is saved, because encoded images do not preserve every display-time orientation hint. These implementation details decide whether the user’s saved object is stable, correctly oriented, and recognisable later.

The Focus Log stores cut-out images and a manifest in the app’s Application Support directory. Natural-language search uses Apple’s language tools to pull useful nouns from a query, then falls back to substring matching. Entries can also appear through Core Spotlight so the user can reopen a specific record from system search.

That search choice introduces a privacy boundary worth naming precisely. Image processing and the app’s own storage stay on device, and the build does not add analytics or a network service. Spotlight indexing does store selected entry metadata and a thumbnail in the system index. It is still local, but it is not the same as saying the journal exists only inside Bokeh.

Accessibility is part of the implementation rather than a separate checklist. The current source uses Dynamic Type, accessibility labels and hints, 44-point minimum touch targets, reduced-motion handling, and layouts that adapt between iPhone and iPad. Camera access still requires a physical device, so simulator-only QA is not enough.

What changed in my judgement

Lumo taught me that a short deadline can improve a product when the team agrees on the one loop that must work. Bokeh taught me the other half: independent ownership means carrying every design decision through permissions, camera queues, error states, persistence, search, privacy copy, and device behaviour.

There are still important limits. The repository has no automated test rig, the core camera flow needs repeatable physical-device evidence, and I have not completed representative usability testing with ADHD or autistic participants. I can demonstrate that the build works. I cannot yet claim that it improves tidying, recall, or wellbeing.

That distinction is the point of this combined story. Lumo gave me the foundation to build. Bokeh is where I learned to treat implementation evidence, accessibility, and unvalidated outcomes as separate things.

View the Bokeh source