Enbase Mobile

After the rebrand I noticed a small missing-glyph box between the seconds and “AM” in the trend-chart tooltip. The same timestamps looked fine as native text elsewhere in the app, and fine in unit tests.

• Traced it with an AI coding agent. The device's JavaScript engine inserts a narrow no-break space (U+202F) before AM/PM, while the ICU build in the test runner uses a plain space.
• The new brand font has no glyph for that character. Native text hides this with per-glyph font fallback. Canvas text draws with exactly the font it's given, so the character became a box.
• A sweep found three canvas call sites with the same problem. The fix went into one shared helper written with explicit escape sequences, because an invisible character typed into source had already been silently flattened during an edit.
• I insisted on proof. The tests build the device string from code points, and they fail with the helper stubbed out and pass with it in place. When the CI reviewer pointed out the helper runs inside a UI-thread worklet, the fix was marked as one, and the project's own Babel output before and after confirmed it.

One tested, worklet-safe utility replaced three ad-hoc fixes, with three new regression tests and a green suite.

The company moved to a new brand. The app's hand-tuned Material Design 3 theme had drifted from the new design system, and the design references themselves disagreed in places.

• Diffed every MD3 colour role in both themes against the design tokens, in tables, before changing any values. Where token files and reference screenshots disagreed, pixel-sampled screenshots were treated as ground truth.
• Spotted visual problems myself, such as a dark background rendering in two slightly different near-blacks and status styling missing from the light theme. Chasing them uncovered three real bugs: the navigation container received a theme object in the wrong shape, a dropdown referenced a colour role that doesn't exist (masked by a hard-coded override) and status pills read from the wrong colour system.
• Implemented the clean-ups review asked for: separate colours for two states, one status palette instead of two and a token renamed to match domain language. Theme mocks were centralized in the test suite.

The rebrand restyled about 20 components and screens in both themes, with the suite green throughout. It shipped publicly in v1.3.0.

Code review noticed that the theme named the new brand typeface everywhere, but nothing in the native projects had changed. The app was quietly rendering the platform default. The reviewer also asked whether a separate display weight made any visible difference.

• Confirmed the gap in the native manifests first, then linked the fonts on both platforms and did a full native rebuild.
• Verified the new letterforms with zoomed emulator screenshots and logcat, moved the canvas-drawn chart text to the new face and removed the legacy typeface from every native file.
• For the weight question, rendered the same headline in each weight, captured both and compared them with a small pixel-diff script instead of by eye.

0% of pixels differed (maximum channel delta 0). With that evidence the designer and reviewer approved dropping the extra weight, and its font files were removed from both platforms.

Review reported that press-and-drag on a trend chart crashed with a null-reference error on both platforms. Separately, tooltip text was measured with one font and drawn with another, so its box could be the wrong size.

• Registered the loaded typeface with the renderer's font provider so measuring and drawing agree.
• The first crash hypothesis, an async font-loading race, was disproven on a physical device, so the investigation moved into the open-source library's native binding.
• The binding checks how many arguments it received, not whether they hold values, so an explicit “undefined” argument before the font loaded made it throw. The fix calls the one-argument form until the font is ready.
• Scripted emulator gestures showed clean logs, but synthetic touches couldn't reliably trigger the gesture, so I reported the result as inconclusive and asked for confirmation on a device instead of claiming a pass.

Root cause identified in library source and fixed in JavaScript only, with the limits of the verification stated plainly.

Field staff needed to acknowledge an equipment alarm from their phone, not only from the web platform.

• Built it in layers: UI first, then the request through the app's layered API client.
• A confirmation dialog, a double-submit guard, a spinner while the request runs and clear errors. Afterwards it shows who acknowledged and when, in local time.
• Found and fixed a shared date helper that applied the time-zone offset twice, which corrected timestamps on several other screens too.

Mobile users got a direct action on alarms, and a cross-screen timestamp bug went away.