bad-apple is the source behind playing the Bad Apple PV inside fourteen apps

The premise: one promotional video, fourteen interfaces

Bad Apple!! is a promotional video for a Japanese doujin music circle, and this repository exists because of a challenge: play that video on as many platforms and interfaces as possible. The README calls it the internet challenge of playing the Bad Apple PV on as many platforms and interfaces as possible.

The table of versions lists fourteen of them, and the list is the interesting part rather than the code. Google Maps, Visual Studio Code, the WeBWorK homework system, Windows 10 File Explorer, Ubuntu, Microsoft Paint, the Desmos graphing calculator, Minecraft Creepers, pure CSS, the Unity game engine, YouTube Studio, the DMOJ online judge, a Turing machine and Scrabble.

Read that list and you can see the challenge was never about the animation. Rendering a black and white silhouette video is easy; rendering it in the address bar of Google Maps, inside a paint program, on a chess board made of Scrabble tiles, or on the tiles of a Turing machine is not. Each entry is a different way of convincing a piece of software to draw something it was never asked to draw.

The videos are published on three platforms. Each version links to a YouTube video, most also link to a Niconico upload and a Bilibili upload, and a few, including Ubuntu, Unity, DMOJ and Scrabble, carry only the YouTube link.

The repository itself says its purpose in one line: code from the author's Bad Apple videos. The primary language is recorded as ASP.NET, and the last push to the default branch was on 2026-09-02, with no GitHub releases.

Every platform is its own subproject

The repository layout matches the table one to one. At the top level there are directories named gmaps, vscode-formatter, webwork, file-explorer, april-fools, ms-paint, desmos, desmos2, desmos3, minecraft-creepers, css, unity-ragdolls, yt-studio, dmoj, turing-machines and scrabble, plus a preprocess directory and a screenshot of the finished work.

Each entry in the README's table links to the corresponding directory, which means the structure is a gallery of separate implementations rather than a single application with pluggable back ends. There is no shared runtime described anywhere, and no configuration file that points at a platform.

Two things in the layout hint at what is shared. The preprocess directory suggests a preparation step, plausibly producing the assets the versions then draw, and the .gitmodules file at the top level means at least one asset comes from a git submodule. That is a sensible arrangement for this project: the audio and the frame data are the same everywhere, and only the drawing code differs.

The desmos entries are worth noting because there are three of them, desmos, desmos2 and desmos3, while the table points at desmos3. Only the third is credited in the table of versions, so the earlier directories are either earlier attempts or alternate approaches to the same target.

The naming is also a hint about the techniques. unity-ragdolls suggests the animation is played by a physics simulation rather than by a sprite sheet, minecraft-creepers suggests the pixels are drawn with blocks, css suggests a browser-only implementation with no scripting at all, and turing-machines and scrabble describe the output medium rather than the software being modified.

The video is the deliverable, the code is the evidence

The distribution model here is unusual, and it shapes how you should evaluate the repository.

The homepage recorded for the project is a YouTube playlist rather than a documentation site, and the README opens with a link to the Bad Apple PV on YouTube, then links to a Niconico series and a Bilibili channel. Each row of the versions table ends with the video for that platform.

That means the artifact the audience consumes is a video, and the repository is the supporting material for it. There is no README inside each subdirectory in the documentation available here, no test suite, no issue tracker convention and no continuous integration. The two badges in the README header are a unit test workflow badge and a Zenodo DOI badge, which is the profile of a project that is archived for citation rather than consumed as a dependency.

The three video hosts are not interchangeable either. YouTube is present for every version, which makes it the canonical archive. Niconico and Bilibili carry most of the versions as well, and for a Japanese doujin video the Niconico upload is likely the one that reaches the original audience, while Bilibili covers the Chinese platform.

For a reader, the practical approach is to watch the video first and then read the directory. The video tells you what the result looks like, and the code tells you what it took.

The unusual entries, and what they demonstrate

Some of the platforms are demonstrations of technique rather than of software.

A Turing machine is a computing model made of tape and a head, and playing a video on one means the animation is driven by the machine's own state transitions. The Scrabble version draws the frames with letter tiles, so each pixel becomes a Scrabble piece on a board. The Minecraft Creepers version uses the game's block grid and its own entity rendering. The pure CSS version is the constraint case, because it renders the animation with nothing but stylesheets in a browser.

Then there are the office and productivity applications, which are the harder half of the list because they were not built for this. A paint program is asked to draw a frame by frame. A graphing calculator is asked to draw with a limited expression language. A file manager is asked to display video inside a list of files. The online judge and the homework system are web applications whose authors never intended them to be animation surfaces.

The april-fools directory is the odd one out by name alone. The table lists Ubuntu against that directory, which suggests the Ubuntu version was published as an April Fools entry rather than as a straightforward port, and that the joke is part of what makes the video worth watching.

Taken together, the entries are a catalogue of rendering surfaces: a web map, an editor, a homework system, a file manager, an operating system, a paint program, a calculator, a game, a browser, a game engine, a video dashboard, a judge, a mathematical model and a board game.

Where to get it and what running one involves

There is no install step to document, because the README does not describe a build for any of the versions.

What the project points you at is the repository itself and the video playlist. To see the technique, you watch the video for the platform you are interested in and then read the matching subdirectory. To try one, you clone the repository and work inside the directory for that platform, which is the only guidance the project gives.

The reason is visible in the table. Each version targets a different host with different constraints, so the work in each directory is different in kind. The Visual Studio Code version is an extension, the pure CSS version is a set of stylesheets, the Unity version is a scene in a game engine, and the WeBWorK version is a change to a web application that teachers and students log into. There is no common build command, no shared dependency manifest and no package to install.

Two practical consequences follow. You should pick the directory that matches the platform you actually want to study rather than trying to build the project as a whole. And you should expect to read the code before running it, because the README explains the goal of each version but not how to launch it.

The preprocess directory and the .gitmodules file are the two places to look first if the code depends on assets you do not have, since they suggest the shared inputs are prepared once and pulled in rather than committed to every directory.

No licence, no releases, and what that means for reuse

Two facts about this repository should shape any plan to reuse its code.

First, the licence field is recorded as unknown, and there is no licence file in the top level listing, which shows .gitignore, .gitmodules, README.md, screenshot.png and the platform directories. The README does not carry a licence section either, unlike most projects in this space. Without a licence, the default position under copyright law is that nobody may copy, modify or redistribute the code, whatever the repository is public.

Second, there are no GitHub releases. The work is a set of commits on the master branch, with the last push on 2026-09-02. There is no version to pin, no changelog and no packaged artefact, which for this kind of project is reasonable, since the deliverable is a video rather than a software release.

Neither point makes the repository less interesting to read. It does mean that anyone planning to take code from it, adapt one of the ports, or fold a technique into their own project has to ask the author first, and that anyone planning to depend on it has to accept that there is no compatibility promise to depend on.

The same applies to the material the versions draw. The audio is from the original promotional video, and the artwork in it belongs to the music circle, so even a technically clean port of the drawing code raises rights questions about the content it displays. That is a licensing fact to verify rather than a conclusion to draw from the code.

Editorial conclusion

Adopt this repository if you are studying how the same short animation is pushed into interfaces you do not control, since each subdirectory is a self-contained demonstration of one technique against one platform. Do not adopt it as a library, a package or a framework, because there is no shared API, no build documentation, no tagged release and no licence on the repository. Before you reuse any of the code, ask the author about licensing, and read the subdirectory you care about rather than the root, because the table in the README is the only index of which technique was used where, and the preprocess folder plus the .gitmodules file suggest the versions share prepared assets rather than a common library.

Frequently asked questions

Official sources

1. Issues
2. kevinjycui/bad-apple on GitHub
3. Project website
4. README