Bringing Princess Maker 2 to an iPad with REA and Codex

REA makes finished software a source of development evidence

REA stands for Reverse Engineer Anything. It connects reverse-engineering tools so an AI agent can investigate executable files and application structure. Native-program analysis can use tools such as Ghidra or Hopper to examine functions and call relationships; JavaScript and Electron analysis can follow modules and data flows. Findings are recorded with evidence that can inform later implementation.

Reverse engineering has a long history. What changes is how its tasks connect. AI agents can participate in a process that previously required someone to interpret an analysis tool's output and carry that explanation into another development environment. A single workflow can trace a function, explain it, implement a change and test it. This connection builds on existing tools and accumulated open-source work.

The Princess Maker 2 project left specific records of that investigation. Early materials include Ghidra-based analysis of a 16-bit DOS executable, functions and cross-references. Later records trace how visual resources are selected and copied. Public PC-98 source code was also consulted, but it was not treated as identical to the Korean DOS version. Executable behavior had to be compared with the reference source.

That analysis helped identify where changes could be made. To attach a new image at the right moment, the implementation must know which image a particular game state selects. REA's contribution was evidence about the original behavior on which implementation and testing could rely; producing the finished iOS app required the subsequent development work.

Changing the display and controls while preserving the rules

This app did not rewrite every rule of the original game. DOSBox Pure handled the original game's execution, input, saves and audio, while an iOS frontend built with C++ and SDL connected touch controls and the new display. It preserved the original execution while adapting the device interface and visual presentation.

That choice clarified the development goal. Existing rules and save structures could be retained, concentrating work on the visuals and controls the user wanted to change. Combining an original runtime with a new interface is one route to using older software on new devices. Analysis tools help determine which parts to preserve and which to replace.

The visual update used artwork made with image-generation tools, processed into transparent PNGs and mapped to original resources. Backgrounds and information panels needed consistency, while characters had to change with age, lessons, jobs and locations. If the new image did not match the image selected by the original game, an attractive individual screen could still be followed by an inconsistent scene or broken movement. The user identified these mismatches, and the scene mappings were revised.

The change is better understood by comparing the same scene than by counting image files. The comparison below keeps the original housework sequence while changing the backgrounds, characters and information panels. Some small equipment and status icons retain their original appearance; this was not a replacement of every image in the game.

Codex's work continued beyond the installation file

The project's endpoint is significant. Codex carried the analysis into artwork production and processing, scene mapping, code changes, tests, iOS building and signing, and installation on the iPad. The workflow brought together analysis tools, image-generation tools, compilers and device-management tools. Its output was an app that could run again on the actual device.

Installation included backing up existing saves and comparing hashes for 67 game and runtime files before and after the update. The final report recorded 54 desktop execution-flow checks and nine iOS simulator checks passing. On the physical iPad, the app launched, resumed the saved game and displayed the updated home screen. These results apply to that version and those checks; they do not establish exhaustive coverage of every branch or device.

The process involved repeated revisions and checks. Artwork consistency was revisited, and checks interrupted by insufficient storage were resumed. A person supplied the goals and aesthetic judgment, evaluated the results and provided the necessary device connection and access. Saying that Codex performed the end-to-end work means that it carried the technical execution from analysis through installation under those conditions. Human judgment and existing software remained part of the process.

That distinction makes the change more tangible. The user could focus more on describing the desired result and unacceptable errors, instead of learning every technical specialty to perform each stage personally. As AI takes on more execution, translating human requirements into testable conditions becomes increasingly valuable.

What Adobe- and Office-like applications suggest

Public development communities are also experimenting with new implementations of familiar product functions. Brandon Thomas's ArtCraft family is one example. In an October 2 Hacker News post, Thomas said he was using Claude Opus 5.5 to build Adobe-like applications in Rust. PhotoCraft covers image editing, VectorCraft vector illustration and FilmCraft video editing; WordCraft, GridCraft and DeckCraft extend the work to documents, spreadsheets and presentations.

The available evidence does not establish that these projects used REA to recreate Adobe or Microsoft products. ArtCraft's public implementations and REA's reverse-engineering tools should be evaluated separately. Both nevertheless raise a related question: must familiar workflows remain tied to one company's product, or can the required tasks be assembled into a different implementation?

The existence of similar features and the ability to replace an established product in professional work require different tests. On October 24, ArtCraft's official app directory described PhotoCraft as early alpha and WordCraft, GridCraft and DeckCraft as in development. Image editors must preserve complex files after saving; word processors must handle pagination; spreadsheets must retain calculations and formatting. A menu of features does not by itself solve those problems.

These limitations do not erase the significance of the work. Public implementations can be inspected, fixed and extended. Their maturity needs careful assessment, alongside recognition that more people can now attempt a wider range of software development.

Community examples make the scope of verification visible

REA's official examples define smaller units of verification. Its DX-Ball example reconstructs a sound-panning function and compares it with the original x86 execution, reporting matching results across 3,205 cases and a 63-byte recompiled function. The Notion example traces clipboard handling from renderer code through interprocess communication. The TH04 example investigates bullet-angle calculation in a DOS game. These examples specify the behavior investigated and the limits of what was checked.

Individual users report similar connections between analysis and implementation. In an October 9 post, Kintu described using Codex and REA to investigate Sony's Sound Connect app and then build and install an Android app controlling wind-noise reduction on XM4 headphones. Existing public protocol documentation helped where analysis stalled, and several revisions were needed. This remains the developer's own report, but it parallels the iPad project in moving a desired function into a separate tool.

Other reports expose the limits of an investigation. On October 20, Connor Turland described tracing Slack notification handling to a path that reads macOS Do Not Disturb state, without fully explaining the final display behavior of client code delivered by the server. Code and service behavior outside the inspected material required additional evidence. A detailed reverse-engineering result is still bounded by what can be observed.

This approach helps build trust in a reconstruction. Once one behavior can be explained and tested, it can support work on the next function. Assuming that similar-looking screens imply identical internal processing can instead lead to failures when real documents and data are introduced.

Princess Maker 2's scene mappings illustrate the same issue. Creating an appealing character and displaying the exact action selected by the original game had to be solved together. One measure of AI-assisted development's maturity will be the specificity of tests comparing original and new behavior, alongside the quantity of generated code or listed features.

Software companies' advantage extends to quality after implementation

The change I see in these examples concerns where development begins. Alongside building a program from requirements and a blank screen, individuals can now consider observing existing software and adapting selected parts for another environment. REA connects the analysis; agents such as Codex can carry the findings into implementation and execution.

This could put pressure on developers to explain why familiar features alone justify choosing their products. If users can more readily create alternatives for their workflows, the reasons to buy extend to file compatibility, collaboration, accessibility, reliable updates and incident response. That is a judgment about how competition may broaden, rather than a prediction that large software vendors will soon disappear.

Established developers retain important advantages. Experience with diverse files and edge cases, plugin ecosystems, collaboration systems and long-term maintenance are difficult to replace in a short demonstration. New AI-assisted apps must also open and save users' files safely and demonstrate that changes have not broken existing functionality. Faster development does not remove that responsibility.

For users, smaller custom projects may represent the more immediate change: combining repeated editing steps instead of building a complete image editor, creating a helper that reads a necessary file instead of replacing an enterprise system, or attaching a new display and input device to an old program's rules. The Princess Maker 2 iPad app illustrates that last direction.

Applications need to work well for both people and agents

The change also appears in the design of new apps. WordCraft, GridCraft and DeckCraft publish command-line and MCP interfaces. These let AI agents work with document structures, cells and formulas, and slides through commands, reducing reliance on finding and clicking screen controls. A usable human interface increasingly needs to be accompanied by a structure that agents can read and manipulate accurately.

Verifiable outputs and reversible changes belong alongside those interfaces. An app and its agent should be able to explain which files changed, what differed before and after saving, and whether previous work can continue after an update. The iPad project's save-preservation checks served precisely that purpose. Users want continuity in what they have accumulated as well as new features.

Materials available for analysis also need to be distinguished from materials that can be distributed to others. This personal project does not imply permission to redistribute original game files or third-party images and code. Keeping track of public specifications, newly created code and artwork, and assets taken from existing programs is part of sustainable development.

REA's potential to mark a turning point in software development lies in these changes. It helps turn the behavior of a finished product into evidence from which people can learn and build. Princess Maker 2 running again on an iPad mini is one instance of that potential reaching a physical device. The value of development will be judged by speed together with how accurately and durably the result works in the environment its user wants.