The QR Code That Forgot Its Memory

Nicole’s QR Code iOS project entered Phase 2, where she added a visual toggle between Circle and Square styles. The underlying QR structure remained the same, but the rendering changed between two distinct visual languages.

While testing an 8-second demo, she noticed an unexpected behavior: every time she switched styles, the QR code regenerated randomly. What appeared to be a visual toggle was actually resetting the entire underlying data.

She realized the system was not preserving state. Instead of storing a fixed QR data structure, the app was regenerating new data on each toggle. This led her to an important insight: the QR code itself must be stable, while only the rendering layer should change.

Under the surface, her implementation already included a structured system:

a 25 × 25 grid-based QR layout randomized filling simulating data regions manually constructed finder patterns and calibration blocks a rendering layer controlled by a simple Circle/Square toggle

But the key learning moment was conceptual, not visual.

She began separating:

• data (the QR matrix, ~550 cells) • rendering (circle or square style) • state (what must persist across UI changes)

This marked her first exposure to a core software design principle:

👉 separation of data and presentation

From this point onward, the system must ensure that:

QR data is generated once and stored visual style is only a rendering layer UI interactions do not mutate underlying data unintentionally

In simple terms:

The QR code should remain stable. Only how it looks should change.