Senior JavaScript / HTML5 Game Developer — iOS (Capacitor)

HTML5 Canvas Game Developer — iOS / Capacitor — live App Store game READ THIS FIRST — do not apply if any of these are true You have not shipped an HTML5 Canvas game to the Apple App Store. You have never debugged touch behaviour on a physical iPhone. You are a full-stack web developer, a MERN developer, a React Native developer, a PHP developer, a Shopify or WordPress developer, or an agency bidding on volume. You would propose rebuilding this in Unity, Phaser, React Native or anything else. This is not a web project. It is a canvas game with a custom physics solver, running in a WKWebView on a phone. Generic web experience is not transferable to it and will waste both our time. THE PRODUCT An iOS merge / suika puzzle game, live on the App Store, shipping through TestFlight now. Plain browser JavaScript, ES5 style. No bundler, no transpile, no framework. HTML5 Canvas 2D for all rendering and physics. Custom solver, twelve iterations per frame, circle colliders. Capacitor 8 wrapping it for iOS. WKWebView. Codemagic CI for builds and TestFlight publishing. Node test suites run from the command line. Measured in the repository on 29 July 2026: the main HTML file is 6,937 lines with 42 inline script blocks. The js folder is another 9,670 lines. There are zero import or export statements — every function is a global. And 16 of 19 test files read the source as text and assert against it with regular expressions rather than executing it. That is the honest state of the code. If it puts you off, do not bid. If it does not, you already understand the job. THE WORK A written register of 28 defects, each with file names and line numbers. It is shared in full with shortlisted candidates. Four real examples: Touch latency. A console log with an eleven-field JSON serialisation runs on every touchstart, before preventDefault and before any game logic. Debug instrumentation shipping in a release build, on the hottest path in the game. Blocked input. A control hit-test is consulted at touchstart, touchmove and touchend. The last two cancel an aim that has already been committed, so lifting a finger over a UI band discards the drop and no gem falls. Touch targets below platform minimum. Interactive elements measure 33px against Apple's documented 44 by 44 point minimum. No CI on pull requests. Checks read 0 on every pull request in this repository. The suites exist and are run by hand. Wiring them as a required gate is part of the job. Also on the register: three gameplay faults found by playing on a device — a power-up with no visible effect, a summon that never appears, a difficulty ramp the player cannot feel. Code has changed for all three. None has been confirmed on hardware. THE ONE REQUIREMENT THAT MATTERS MOST You test on a real device before every handover. Every regression in the past week reached my phone because the work was verified by passing tests and never played. Green suites are not evidence about a game. If you hand over work you have not played, this will not work out. SCREENING — before any interview You get a TestFlight build and two sentences: "Touch is slow. Drops are blocked." Come back with what is wrong — which file, which line, what you would change. Both causes are readable from the source in under an hour if you know where to look. I am not testing whether you can guess. I am testing whether you read the code before answering. TO APPLY First line: the canvas game you shipped to the App Store, with a link. Second: one touch or pointer bug you found on a physical iOS device that did not appear in a browser or simulator. Nothing else. No CV summary, no portfolio wall, no "passionate full-stack developer".