HarmonyOS and the Software Crisis — An Engineering Analysis of Rebuilding a Platform

Geoffrey Chen


Many people first noticed that HarmonyOS had fundamentally changed not at a Huawei launch event, but after buying a new handset. They tried to install an Android APK they had used for years and found that it would not run, or that they had to wait for a native HarmonyOS version. To an ordinary user, this looks like an inconvenient compatibility issue. In software engineering terms, it signals something much larger: a mature application platform has deliberately given up an inherited software relationship and is attempting to build its own runtime, toolchain, distribution system, service interfaces, and developer ecosystem.

This is not an ordinary operating-system upgrade. It is closer to constructing a new city beside one that is still inhabited, then asking residents, businesses, public services, and transport links to migrate over time. Roads and buildings can be finished first. Whether the city actually works depends on whether the places people need every day are already there.

The causal direction matters

HarmonyOS NEXT’s application problem should not be reduced to a claim that Huawei lacked the technical ability to make Android compatibility work. That reverses the causal order.

Earlier Huawei phone software could, to a substantial extent, inherit the Android application ecosystem. Whatever architectural changes occurred underneath, users did not abruptly lose their software assets so long as APKs could run and Android’s application framework and interfaces remained available. The defining change in HarmonyOS NEXT is that it intentionally stops following that compatibility route. Huawei has described the system as not using Android application libraries and as not directly opening Android APKs; applications are instead expected to be developed and distributed natively for HarmonyOS.

That is a strategic choice. It plainly has technical aims: fuller control of the stack, less dependence on an external platform, a unified model across phones, tablets, wearables, vehicles, and other devices, and a domestically controllable platform in China. Once that choice is made, however, the technical consequences are unavoidable. The large body of software previously attached to Android cannot be carried automatically into the new system. It must be adapted, rewritten, tested, released, and maintained.

The point, then, is not that HarmonyOS is incompatible with Android because of a technical failure. It is that, in pursuing platform independence, HarmonyOS has chosen to discontinue Android compatibility and has therefore exposed ecosystem costs that the compatibility layer used to absorb. That is the correct starting point for the analysis.

An operating system is not yet a software platform

The discussion often blurs the difference between an operating system and a software platform.

In the narrow technical sense, an operating system includes a kernel, process and memory management, a file system, drivers, permissions, and a basic runtime. A capable large company can, with sustained investment, build a stable, responsive, secure operating system. Huawei’s strengths in telecommunications equipment, device hardware, system software, and large-scale engineering are real. A shortage of applications is not proof that it cannot build an operating system.

But a smartphone is not a machine bought merely to boot and make calls. What users actually buy is a platform. Beyond the underlying system, that platform includes APIs, programming languages, SDKs, compilers, debugging tools, an app store, payment and advertising capabilities, push services, maps, identity systems, cloud synchronisation, privacy and security rules, technical support, third-party libraries, open-source communities, and a dense web of dependent services.

Users do not experience a kernel as advanced or otherwise. They experience whether banking works, whether medical booking and government services are available, whether internal workplace software runs, and whether music, photographs, smart-home devices, overseas communication, and an occasional specialised utility can be relied upon. The real value of a platform is not what it theoretically permits developers to build. It is what it already supplies reliably, and whether users can trust it to be there when needed.

That is why a counterintuitive fact has long held in software. Building a new operating system is hard; building a new general-purpose software platform is harder. The first is mainly a problem of engineering and organisation. The second must also deal with accumulated history, market coordination, commercial incentives, developer time, and user trust.

A contemporary form of the software crisis

The phrase “software crisis” became prominent in software-engineering discussions from the late 1960s and through the 1970s. As computer systems grew more complex, projects routinely ran late, exceeded budgets, delivered unreliable quality, and became difficult to change after release. Software engineering emerged in response to a basic question: when a system becomes too large for any individual to grasp directly, how can it still be built, maintained, and evolved reliably?

HarmonyOS presents a different case from those early large projects, but the structure is similar. The issue is not a defective line of code or a missing API. It is that both system scale and coordination scale have grown beyond what a single organisation can directly control. A modern mobile platform is no longer a simple collection of apps. It is a network of code, accounts, payments, data, brands, user habits, regulatory requirements, enterprise processes, and developer incentives.

Compatibility is not an incidental feature in that network. It is a mechanism for preserving history. When old apps continue to run, users’ previous software purchases, stored data, learned habits, and established workflows remain valid. A compatibility layer can look like technical baggage, but it performs an enormous social and economic function: it prevents history from being erased in a single version change.

When a platform cuts compatibility, it does not abolish historical costs. It reallocates them. Developers must adapt or rebuild, enterprises must revalidate internal applications, service providers must maintain two versions, and users must download again, migrate data, and tolerate functional differences. The platform owner may share part of the cost through funding, tools, and promotion. The cost itself does not disappear.

Why application counts are not the central metric

HarmonyOS ecosystem building is often presented through figures for the number of native applications. Those figures matter, but they are profoundly incomplete.

An app store with one hundred thousand applications does not mean a user’s life is covered. Apps differ radically in value. A torch utility, a wallpaper app, and a fully featured major-bank client each count as one app, while their practical significance is entirely different. What determines usability is not the total count but the structure of coverage.

First come high-frequency essentials: messaging, payment, maps, transport, shopping, banking, healthcare, government services, work, and education must be stable and complete. Then come long-tail needs. A person may rarely use a specialised app, but suddenly need it while travelling, lodging a tax return, repairing equipment, attending a meeting, or handling a work matter. Third is functional depth. Even when an app has launched, it may offer only basics and lack complex workflows, plug-ins, accessibility support, cross-device work, data migration, or enterprise management. Fourth is update cadence. A platform needs more than a one-off migration release; it must continue to receive feature updates, security patches, and new service integrations.

An application ecosystem is therefore not a checklist that can be completed once. It is a maintenance system that must keep operating. Numbers can rise rapidly in the short term. Completeness and maturity take long-term use to form.

Two-sided network effects and the cold-start problem

Mobile platforms naturally have two-sided network effects. More users attract developers because potential revenue, brand exposure, and service value increase. More applications attract users because the platform becomes more useful. Android and iOS are advantaged not merely by their present technical implementations, but by a positive feedback loop that has run for well over a decade.

A new platform must start outside that loop. Developers ask whether the HarmonyOS user base justifies maintaining another codebase over the long term. Users ask whether the software they need is complete and whether gaps will persist. If each side waits for the other to move first, the platform faces a cold start.

Huawei is not starting from nothing. It has a substantial device base, brand recognition, distribution, investment capacity, an app store, and important partnerships in the Chinese market. These are real conditions for a launch. Yet having a chance to start is not the same as having passed the platform threshold. Passing it means developers no longer regard HarmonyOS as a short-lived adaptation exercise but as a first-class platform requiring sustained investment. It also means that users no longer treat it as a special system whose omissions need constant checking.

Subsidies can help create a first version of an app. Commercial and administrative coordination can bring key services online. Tools can reduce porting work. None of these, on their own, can create ten years of developer experience, third-party components, stable business models, and user habits. Those emerge only through repeated use and durable returns.

Recompiling is not rebuilding a platform

It is tempting to argue that modern cross-platform tools make migration easy and that many Android apps require only modest code changes. That is true for some simple applications.

A real-world application is rarely an isolated body of interface code. It may call identity systems, payments, push messaging, maps and location, cameras and media, advertising components, analytics, anti-fraud systems, cloud APIs, enterprise identity management, and device-specific security capabilities. It is connected to existing databases, customer-service processes, operations back ends, testing systems, and compliance requirements. If one critical dependency is missing, the work is not a matter of changing several screens. It is the rebuilding of a business chain.

Long-term maintenance matters even more. Each added platform creates another set of devices, system versions, permission models, performance issues, crash reports, and release processes to test. For a large internet company, this is a resource-allocation question. For smaller developers, independent developers, overseas services, and internal enterprise teams, the return may not cover the continuing cost.

Native development is therefore not simply getting an app into a new store. A platform must offer developers strong tools, stable interfaces, clear documentation, dependable commercial returns, and a predictable technical path. Without these, even teams that complete the first migration may drift behind in later releases.

China provides the conditions, and sets the initial boundary

HarmonyOS cannot simply be told as another version of the Windows Phone or BlackBerry story. China has a huge, intensely digitised domestic market in which payments, social services, transport, commerce, content, and public services are concentrated in a group of firms with formidable engineering capacity. Huawei also has enough market standing to encourage high-value domestic applications to adapt early. For people whose work and daily life rely mainly on Chinese services, switching costs can fall quickly once core applications are sufficiently complete.

At the same time, this makes the ecosystem’s initial centre of gravity more domestic. For users who depend on international services, overseas banks, multinational enterprise software, Google-linked services, specialist tools, or niche apps, the gap has a different character. The question is not merely whether an app is translated or whether an approximate substitute appears in a store. It is whether the original service provider has the commercial incentive, legal conditions, and technical resources to maintain a long-term version for the platform.

This is not a moral judgement about HarmonyOS. It is a normal consequence of platform boundaries. Every platform is shaped by its most stable market, most active developers, and most sustainable commercial relationships. HarmonyOS must first show that it can form a stable loop in its core market. Globalisation is a further and harder layer of the problem.

Compatibility is not weakness, and a clean break is not automatically progress

Technical discussions sometimes treat legacy compatibility as a burden and a complete rewrite as purer or more advanced. In engineering practice, compatibility is often among a mature system’s most valuable capabilities.

Microsoft has retained a great deal of Windows history not because it cannot design new systems, but because the value of enterprise applications, industry-specific software, and established workflows exceeds the aesthetic benefit of an architectural clean slate. When Apple moved from PowerPC to Intel and later to Apple Silicon, it provided transition paths such as Rosetta. Android itself has long maintained API levels, compatibility behaviours, and developer migration paths to avoid making old apps fail at scale after one upgrade.

Compatibility has costs, of course. It adds architectural complexity, security exposure, and maintenance work, and can constrain later evolution. Huawei may have chosen a full break precisely to avoid carrying Android’s legacy indefinitely and to establish genuinely independent technical and commercial boundaries. That objective is intelligible.

Its intelligibility does not remove the cost. Platform strategy has to recognise a plain fact: compatibility is not technical laziness. It protects existing software assets, users’ time, and social coordination. Cutting it asks the whole ecosystem to participate in a reconstruction.

The real test is daily friction, not the launch event

HarmonyOS NEXT should not be assessed mainly through launch-event demonstrations, application-signing totals, or short-term installation numbers. The more revealing questions are ordinary ones.

When users need an infrequent but critical service, can they complete the task within minutes rather than return to an old device or hunt for a workaround? Do developers support HarmonyOS with each product update, rather than completing a one-time demonstration adaptation? Can enterprises move their internal applications, device management, and security compliance? Do apps preserve functional parity, data continuity, and stable experience? When people replace their phones, do they still worry that their accumulated digital life will be cut off again?

These indicators are less dramatic than application counts, but they are closer to platform quality. A mature platform is one that users rarely have to notice. Software quietly carries work and daily life in the background, and the platform itself becomes transparent.

Conclusion — HarmonyOS faces a question of time

Huawei is not merely producing a handset operating system to replace Android. It is attempting to transform terminal products that formerly relied on an external ecosystem into an independent platform with its own development languages, system interfaces, application distribution, and service network. That is a long-term strategy, not a version upgrade.

Seen this way, HarmonyOS’s application difficulties are neither absurd nor surprising. They are the price of platform independence. The real question is not whether Huawei can write a new system. It is whether, over enough time, it can enable developers, service providers, enterprises, and users to turn that system into a normal platform—one that no longer needs repeated explanation for its exceptional limitations.

An operating system can be built by one company. An ecosystem can only be sustained by many independent participants whose interests continue to align. HarmonyOS NEXT’s difficulty lies precisely on that boundary.

Sources

Discover more from Geoffrey Chen

Subscribe to get the latest posts sent to your email.