A factory in your hands.

The problem: a cursor is not a finger.

Factory games ask players to repeat precise operations: place a machine, connect a belt, rotate an output, correct a mistake and inspect the result. On a desktop, the cursor, keyboard and large screen work together. On a phone, the same finger must place objects and move the world, while also covering the tile the player wants to see.

Our question was practical: could we preserve the original production simulation while making the construction loop comfortable enough to play on a phone and a foldable? The first target device was a Galaxy Fold 7. A working production chain mattered more than a polished picture of an imaginary interface.

Preserve the simulation. Adapt the boundary.

We retained the original JavaScript/Canvas game simulation and built an offline Android WebView shell around the game. The adaptation work sits in touch input, mobile presentation, localization and the Android window lifecycle.

This let us test a real factory early. It also kept an important distinction clear: this prototype is its own implementation path, not an update that can be dropped into the official mobile edition.

The native shell serves bundled content locally. Fullscreen and display-cutout handling cross a small JavaScript/native boundary. Device pixels must be translated into CSS coordinates so the background can fill the display while controls stay clear of reserved areas.

The editor: build, inspect, correct.

The early interface used large labelled buttons and a separate building picker. That made the controls discoverable, but consumed valuable screen space. Device feedback exposed another issue: opening a picker every time a player wanted a different building interrupted a fast construction loop.

The revised interface uses a compact, horizontally scrollable building rail. Camera and deletion remain quickly accessible. Selecting a building leads directly into placement; dragging a belt previews the path before committing it.

Deletion is a stroke rather than a sequence of isolated taps. Changes are deferred until the finger lifts, and introducing a second finger cancels the pending construction gesture. Two fingers control the camera. Quick erase can return to the previously selected tool and its rotation, reducing the cost of a misplaced object.

These choices favour speed once the player learns the gestures. They also create a testing obligation: transitions between construction and navigation must be predictable, especially when a second finger arrives mid-gesture.

A foldable is more than a larger phone.

We check narrow and wide viewports rather than designing only for the Fold’s inner display. The available space changes the balance between the factory, the tools and the menus. A screen that works well when expanded can still fail on the outside display.

Overlapping upgrade cards were one concrete example. Opening multiple sections exposed a layout problem hidden by testing a single section. The fix needed to preserve each card’s height and let the dialog scroll. Fullscreen testing raised a different concern: hiding system bars and handling the cutout are related, but separate behaviours.

Performance: address transitions, then measure.

Device playtesting identified hesitation near the transition into the map overview, particularly around buildings. The prototype uses hysteresis around that transition, so a small change in zoom does not repeatedly switch rendering modes. It also avoids drawing both modes as an overlapping crossfade.

Playtesting feedback has been encouraging, including a subjective impression of a faster experience than the official mobile app. We have not completed a controlled comparison, so this case makes no startup-time, frame-rate or speed-multiplier claim.

The next comparison needs equivalent factories, fixed device conditions and separate measurements for startup, interactive editing and sustained simulation. A fast empty map is not evidence of a fast large factory.

One translation system.

Mobile-specific text belongs in the original localization pipeline. We integrated the new strings into the YAML language resources rather than maintaining a second JavaScript dictionary. Shared game labels continue to use the original translations; mobile hints describe touch gestures rather than mouse buttons.

Browser automation exercises 24 selectable locales and checks mobile layouts, including right-to-left text. Coverage checks catch missing keys and rendering failures. They do not establish the linguistic quality of every translation; native-speaker review remains separate.

What works today.

• Playable early chains: extraction, belts, cutting and delivery.
• Direct placement, belt dragging, stroke deletion and two-finger camera control.
• Phone and wide-screen layouts, compact tools and an adapted main menu.
• Save/reload and upgrade flows exercised in gameplay checks.
• An offline Android prototype tested by its owner on Galaxy Fold 7.

The browser checks cover interaction, production, saves, localization and layout. Android compilation and browser checks do not replace device testing; the latest native cutout adjustment still needs hardware confirmation.

What this case does not claim.

This is not a complete commercial port. The editor does not yet cover every building variant, blueprint workflow or wire-layer interaction. Compatibility with the official mobile edition’s saves, cloud services, purchases and achievements is not established. iOS has not been built or tested.

The work demonstrates touch-editor design, frontend adaptation and Android integration. Native C++ engine porting and large-factory performance need additional evidence. Those are next engineering questions, not results borrowed from this prototype.

The next useful milestone.

We want a reproducible device demo and benchmark set across the Fold and a more modest Android phone, followed by lifecycle and save-recovery testing. A commercial release would also need a finalized product scope, distinct release branding, a matching corresponding-source package and completion of the third-party asset review.

The strongest result so far is tangible: a player can build a production chain, make a mistake, correct it and keep playing on a touch screen. That gives us a useful foundation for the next iteration.

Source & credits.

Our Android adaptation is published on GitHub, with build instructions and the original project history. The source fork is a prototype; it is not yet a Google Play release.

Original game, simulation and game artwork: shapez and its creators. Zerno’s contribution is the independent mobile adaptation described here. Screenshots show that adaptation and retain the original game’s visual assets.

• Original source repository and GPLv3 license.
• tobspr Games, creators of shapez.
• Official Android edition from Playdigious.

This page documents the prototype. It does not distribute an APK or represent an official store listing.