Chris Almaguer Data visualization design

Note - Desktop

It launched on my Mac and crashed on theirs

FOCUS is a small Pomodoro timer for macOS that pretends to be a DOS terminal. The part worth writing down is that App Review rejected it three times for a crash I could never reproduce, because the bug was not in the app. It was in how the app was signed.

macOS Electron In review

01 - The app

A timer with nothing to configure

Five preset buttons that add together, 5, 10, 30 minutes, one hour, two hours, plus a custom field if you want 7:30. An ASCII hourglass whose sand actually drains as the session runs, a progress bar made of block characters, and a title bar reading C:\FOCUS\TIMER.EXE. No account, no streak, no history.

The app

3 screens
FOCUS at rest. An empty green ASCII hourglass on black, the duration buttons unselected, and the prompt SELECT DURATION TO BEGIN.
FOCUS running a thirty minute session. The upper bulb of the hourglass is full of dithered ASCII sand, 29:42 reads across the middle, and the status line says FOCUS SESSION ACTIVE.
FOCUS at the end of a session. The sand has fallen to the lower bulb and SESSION COMPLETE flashes across the screen in block characters.

02 - Three rejections

The same crash, three times

Apple kept returning the app under Guideline 2.1(a): it did not launch. On my machine it launched every time, from a clean install, on the same macOS version. With no crash to look at there was nothing to fix, so the next build was mostly guesswork, and the next rejection was identical.

Apple's July 27 rejection screenshot. The FOCUS window is open and completely black apart from the three traffic light buttons.
July 27. The whole of what came back with the first rejection.
Apple's August 5 rejection screenshot. The same completely black FOCUS window, indistinguishable from the July one.
August 5. Nine days and two builds later. The same picture.

The build that broke the loop did not add a feature. It added a fatal error surface, so a renderer dying at launch is reported by the main process instead of leaving a black window on screen forever. The next screenshot came back with something written on it, and the crash code in that one line is the whole diagnosis.

Apple's August 7 rejection screenshot. The same black FOCUS window, now with a macOS dialog on it reading: FOCUS could not display its interface. The display process ended unexpectedly, crashed, code 5. Please reopen FOCUS.
August 7. The same window, with one line on it. That line named the process that died and how, which was the first thing in three rejections that could be acted on.

A separate note in the same review asked me to take ".exe" out of the store listing, since Apple would rather a Mac app not advertise a Windows file extension. Fair. The listing is now FOCUS. The ASCII inside the window still says C:\FOCUS\TIMER.EXE.

03 - The cause

Signed one way here, another way there

The part of the app that draws the window runs as its own process, and to draw anything it has to compile code as it goes. Building for the App Store locks every process down, and by Apple's own rule a helper process cannot be handed the exemption that goes with the lockdown. So it was told to do the one thing it had just been forbidden. It quit before the window appeared.

None of that happens here, because the signature I use for testing does not apply the lockdown. The crash lived in the store signature, the one build I could not make myself. The fix was a single setting, in 1.0.4.

What I take from it

On a project this size the useful investment was not another feature. It was making failure visible. The error screen I added out of frustration is the thing that eventually found the bug, and it found it on a machine I will never have access to.

Support page for FOCUS