HarmonyOS PC and App Architecture Evolution: Why Software Is Shifting to System-Driven Design

This article examines the architecture evolution of HarmonyOS PC and apps. The core conclusion is that software is moving from window-driven and page-driven models toward a System-driven model. This shift addresses three major pain points: fragmented state, tightly coupled logic, and poor cross-device reuse. Keywords: HarmonyOS, state management, System architecture.

Technical Specification Snapshot

Parameter	Details
Domain	HarmonyOS / PC / App Architecture Evolution
Core Paradigm	Store + System + UI
Key Languages	ArkTS, TypeScript, C++
Typical Frameworks	ArkUI, React, Vue, Traditional GUI
Interaction Model	Event-driven, lifecycle-driven, state-driven
Original Popularity	482 views / 9 likes / 14 bookmarks
Core Dependencies	Declarative UI, state management, rule-engine thinking

The Core Argument Is That the Architectural Center Has Shifted

Although the original topic focuses on HarmonyOS PC and apps, the highest-value insight is not the platform difference itself, but the shift in architectural focus.

In the past, software was organized around windows and pages. Today, systems are increasingly organized around state and rules. HarmonyOS simply exposes this trend more explicitly and more completely.

AI Visual Insight: This image serves as a conceptual cover for a technical article. It visually emphasizes the relationship among HarmonyOS PC, apps, and System architecture, and is typically used to communicate the idea that although device forms differ, the underlying architecture is converging.

AI Visual Insight: This animated image resembles a process or state-transition demonstration, suggesting that a unified driving mechanism exists behind visible UI changes. It reinforces the technical idea that UI is only the external result, while the core lies in internal state transitions.

We Can Summarize the Four Stages with a Single Throughline

PC: Window-driven
App: Page-driven
Web frontend: State-driven UI
HarmonyOS: System-driven state and UI

This progression shows that software forms keep changing, but the underlying goal remains the same: reduce complexity and improve maintainability.

The Window-Driven Model of the PC Era Naturally Tends to Spiral Out of Control

The common model in traditional desktop software is window + events + callbacks. A button click directly executes logic, and an input event immediately updates UI or data.

This model is efficient enough for small tools. But once business complexity grows, state begins to scatter across controls, callbacks, and window instances, and the problem expands quickly.

void onClick() {
  doSomething(); // Handle business logic directly inside the event callback
}

This code shows the typical event-driven style. Its advantage is simplicity, but its drawback is that logic becomes fragmented very easily.

The Problem Is Not the Event Mechanism, but the Lack of a Single Source of Truth for State

When order state, login state, and cache state are each maintained by multiple windows, the system enters a maintenance phase that is difficult to trace.

This is where the first major PC architecture problem emerges: state becomes unmanageable.

The Page-Driven Model of Mobile Apps Introduced Layering but Did Not Solve the Root Cause

With the rise of iOS and Android, software structure shifted from windows to pages. Developers began writing logic around Page, ViewController, and lifecycle events.

This was a meaningful step forward from the desktop era because the page became the organizational unit, and both layering and modular thinking became stronger.

onAppear() {
  fetchData(); // Fetch data when the page appears
}

This code reflects the typical model where business logic is driven by the page lifecycle.

Even When the Page Becomes the Center, Cross-Page Synchronization Remains Hard

The page-driven model introduced structure, but fundamentally it still meant that pages drove everything. Once multiple pages share the same business state, synchronization, propagation, and reuse all become expensive.

A common symptom is this: if Page A changes data, should Page B refresh? In many cases, developers can only rely on manual notifications or repeated requests.

Frontend Frameworks Pushed UI Toward State-Driven Design but Still Left the Rules Layer Incomplete

The real breakthrough of frameworks such as React and Vue was not just componentization. It was teaching developers to accept that state changes should automatically drive UI updates.

That step was critical because it turned the interface from something actively refreshed into something passively mapped from state.

setState({ count: count + 1 }); // Update state, then let the UI react automatically

This code expresses the core idea of modern frontend development: change state first, then let the view respond.

But Many Projects Still Push Business Decisions Back into Components

That means UI may already be state-driven, but it is still unclear why state changes, who changes it, and which rules govern it.

This leads to the third major problem: the absence of a rules layer, which makes state update paths difficult to control.

HarmonyOS Expresses the Store, System, and UI Chain More Completely

In the original discussion, the value of HarmonyOS, especially ArkUI, lies in how naturally it supports a complete chain: Store manages state, System manages rules, and UI handles presentation.

This is not just another MVVM variation. It elevates the rule execution layer into a first-class architectural center.

class CounterSystem {
  constructor(private store: { count: number }) {}

  increment() {
    this.store.count += 1; // The rules layer updates state in a unified way
  }
}

This code shows that state changes no longer scatter across button click handlers. Instead, they are centralized in the System layer.

Once Input Flows into System First, the Page Stops Being the Center of the Application

The new runtime flow can be abstracted as: input enters the rules layer, the rules layer updates state, and state changes then drive the UI.

User input / AI input
        ↓
     System
        ↓
      Store
        ↓
        UI

The significance of this flow is that it reconstructs a complex application from a UI system into a state system.

System-Driven Architecture Is Becoming the Trend Because It Solves Three Longstanding Problems at Once

Unified State Is the First Major Benefit

Once Store becomes the single source of truth, data no longer scatters across pages, components, and control instances. During debugging, you can also clearly understand the current state of the system.

Decoupled Logic Is the Second Major Benefit

UI only triggers intent and no longer carries complex business decisions. Once business rules move into the System layer, both testability and reusability improve significantly.

Extensibility Is the Third Major Benefit

Adding new features no longer means modifying multiple pages. Instead, you add a new System or extend a set of rules. In multi-device scenarios, this advantage multiplies.

function handleIntent(intent: string, store: any) {
  if (intent === 'login') {
    store.user.loggedIn = true; // Let the rules layer take over state transitions in a unified way
  }
}

This code demonstrates the minimal implementation path from intent to state transition.

HarmonyOS Is a Better Fit for This Architecture Because Declarative and Multi-Device Models Are Naturally Compatible

ArkUI’s declarative UI, reactive updates, and multi-device adaptability make it much easier to implement a no-logic UI plus pure-logic System architecture.

That means the same Store and System can be shared across phones, tablets, PCs, and other devices, while each platform keeps only its differentiated presentation layer.

The Key to Multi-Device Consistency Is Not Reusing Components, but Reusing Rules and State

Many teams interpret multi-device unification as one UI running everywhere. In practice, that is rarely realistic.

The truly stable way to unify platforms is to share the same state model and the same business rules, while allowing each device to render the UI that suits it best.

AI Integration Will Further Strengthen the Importance of the System Layer

One especially accurate judgment in the original article is this: AI cannot be stably embedded in the UI layer.

Whether the task is recommendation, decision-making, automated execution, or agent orchestration, AI can only exist as part of the rules layer and then influence state from there.

async function runAISystem(store: any) {
  const suggestion = await getAISuggestion(); // AI produces a decision recommendation first
  store.recommendation = suggestion; // Then the state layer exposes the result externally
}

This code shows that the proper place for AI is the System layer, not page event handlers.

The Real Reason Developers Get Stuck Is That They Still Think in Terms of Pages

Many projects become hard to maintain not because the framework is outdated, but because the mental model remains trapped in which page should contain which logic.

Once logic lives in UI, state lives in components, and pages directly control process flow, complexity grows from linear to exponential as requirements expand.

The Ultimate Insight Is That You Are Not Building a Collection of Pages, but a System of Rules

From PC to apps and then to HarmonyOS, the direction of evolution is remarkably consistent: window-driven design gives way to page-driven design, and page-driven design gives way to System-driven design.

The future of software is not more pages. It is more centralized rules, more unified state, and lighter UI.

FAQ

1. What is the essential difference between System architecture and traditional MVC or MVVM?

Traditional patterns emphasize separation of responsibilities. System architecture goes a step further by emphasizing centralization of the rules layer. The key is not just layering, but ensuring that all state changes pass through a unified rules entry point.

2. Must HarmonyOS projects explicitly define both Store and System?

Not as a language-level requirement, but it is strongly recommended for medium and large projects. Otherwise, business logic will flow back into the page layer and eventually undermine multi-device scalability and testability.

3. Why must AI integration stay close to the System layer in a business application?

Because AI outputs are fundamentally decisions, recommendations, or actions. They naturally belong to rule execution logic. If written directly into the UI layer, they create chaotic flows, untraceable state, and untestable behavior.

Core summary: This article reconstructs the architecture evolution path from PCs and mobile apps to HarmonyOS, explaining why software systems are shifting from window-driven and page-driven models to System-driven design. It also breaks down how the Store, System, and UI three-layer model solves fragmented state, coupled logic, and multi-device scaling challenges.