Making a Film Production App Feel Right on Every Device

The fifth problem: the same production tool, on a laptop, a tablet, and a phone, without any of them feeling like an afterthought.

CineLog started life as a desktop app. That was a deliberate choice — pre-production planning is mostly a “sit down with a keyboard and a coffee” activity, and we didn’t want to compromise the depth of the desktop tool by building it tablet-first.

By October 2025, we’d been getting the same feedback for weeks: the desktop tool was the place planning happened, but the place a production runs is everywhere else. Set visits. Location scouts. Coffee with the DP. The hours before call. None of these are at a desk.

So we spent two months making CineLog actually portable. Not “a small version for mobile.” The same tool, adapted intelligently to the device you happened to have in your hand.

Display settings: the unglamorous backbone

The first thing we discovered, after a few weeks of building responsive layouts, was that we had a state-management problem dressed up as a UI problem.

Every user wanted slightly different defaults — row heights in the shot list, column widths, whether to use grid or linear view in the storyboard, light mode or dark, expanded sidebars or compact. None of this is interesting on its own, but the user expectations were specific:

Settings should persist across app restarts.
Settings should sync across your devices (your phone should remember the row height you set on desktop).
Settings should respond instantly when you change them, in every view that uses them.

We rebuilt how display preferences are stored. The shot list, the storyboard, and the script panel all read from a shared, reactive settings store. Change row height once and every row updates immediately. Change theme and the cursor color, panel backgrounds, and overlay opacity all update together.

This kind of plumbing is easy to underestimate. We rewrote thirteen widget files to participate in the new system. The visible payoff is invisible — “things just remember themselves” — which is the right outcome but a hard one to demo.

Phone layouts: not a smaller desktop

The instinct when adapting a desktop app for phone is to shrink everything. That’s wrong. A phone isn’t a small monitor; it’s a different input device with different muscle memory.

Some of what we changed:

Drawer navigation instead of a navigation rail. The rail eats too much horizontal space, and a thumb wants the menu where a thumb lives.
Bottom sheets instead of dialogs for most forms — adding a role, editing a contact, picking options. They animate up from the bottom, they’re easy to dismiss with a swipe, they don’t feel like a modal interruption.
Swipe actions on shot list rows for edit and delete. Tapping a tiny menu icon is unfair on a moving train.
Expandable cards for shots, so the default view is glanceable and you tap to see detail when you need it.
Long-press to enter multi-select mode, with a selection-aware app bar showing how many items are picked.

We added phone layouts for every major screen — script editor, shot list, projects list, account, help, roadmap, call sheets, cast & crew, home, invoices, media explorer, hotkeys. Each one needed its own design pass, because the constraints are different per screen. The script editor has to surface enough chrome that you can still navigate scenes without a keyboard. The shot list has to be one-handed-operable. The call sheet has to display dense data without making you pinch-zoom.

Storyboard: a feature that started simple and grew

The storyboard module started as a linear timeline — horizontal panels representing each shot, in order. It worked for some directors and felt wrong to others. Visual directors wanted a grid where panels could be sized like a comic book.

We added grid view. On phones, that’s a two-column grid; on desktop, anywhere from 1 to 10 columns, adjustable with Cmd+Scroll. Drag-and-drop reordering. A fullscreen expanded dialog for individual panels with PreVis images and quick fields for shot type, lens, and movement.

The configurable-columns idea is small but it came up over and over in user testing. Different productions want different densities. A music video DP wants a tight grid of references; a feature film director wants larger panels with more annotation. The control is right there in the menu, so each user finds their own setting.

Hotkeys, properly

The desktop power users — script supervisors, ADs reviewing the shot list — wanted keyboard shortcuts. We resisted this for a while because building a good hotkey system is more work than it sounds. Eventually we caved and did it right:

Platform-aware modifiers (⌘ on Mac, Ctrl on Windows/Linux), with the correct symbol shown in tooltips and hint screens.
A dedicated hotkeys help screen that lists every shortcut by feature.
Scoped hotkeys — 1-7 formats the current line in the script editor, but those same keys do nothing in the shot list.

Concrete examples that ended up earning their slot:

Shortcut	Action
`⌘/Ctrl+I`	Import script
`⌘/Ctrl+P`	Export PDF (Shot List, Storyboard)
`Shift+P`	Populate shot list from script
`Shift+S`	Toggle script panel
`⌘+Scroll`	Adjust row height (shot list) / panel size (storyboard)

The Cmd+Scroll density control surprised us with how much users like it. It’s a continuous adjustment instead of a discrete setting, which is the kind of thing keyboard-and-trackpad users find obvious and touch users find mysterious. Both work.

What it looks like today

A production coordinator opens CineLog on a laptop to build the shot list and lay out the production days. The director opens the same project on an iPad in a scout van and reorganizes scenes by drag-and-drop. The first AD pulls up the next day’s call sheet on her phone over morning coffee. All three are looking at the same data, edited in the layout that fits their device, and any change one of them makes reaches the other two in real time.

This is the version of CineLog that started to feel like a real production tool. The earlier versions worked. This was the one that fit.

The struggle, distilled

Cross-platform isn’t free, and it isn’t a checkbox. Every screen needed a phone layout, a tablet layout, a desktop layout, and rules for how they transition. We spent a lot of time on responsive breakpoints (phone under 550px, tablet up to 1000px, desktop above) and on the navigation patterns that work in each.

The cost was real — call it two months of work spread across the codebase. The benefit was that “but does it work on my iPad” became a non-question, and that opened a whole class of users who would never have used a desktop-only tool.

Next: Going Offline-First Was the Hardest Architectural Decision We Made — the architectural decision that consumed a whole quarter.