When Your OS Gets Intent: What HarmonyOS 7 Means for App Builders

A System That Listens for Intent

Two months after the HarmonyOS 7 developer beta debuted at HDC 2026, the buzz has settled. Performance numbers and feature lists are easy to grab. But the real story is architectural: HarmonyOS 7 is the first mobile OS that's been reorganized around the idea of an AI agent at its core.

Think about how you use a phone today. You want to do something—book a court, find a trail, plan a ride—so you pick an app, open it, and navigate menus. HarmonyOS 7 flips that. You state your intention, and the system figures out which apps and services to call, then orchestrates them to get the job done.

That might sound like a voice assistant on steroids, but it's a different beast. A voice assistant answers a query. This is a system that decomposes your request into subtasks, dispatches them to specialized agents, and stitches the results together.

The Six Layers Under the Hood

The whole architecture rests on what Huawei calls HMAF 2.0—the HarmonyOS Multi-Agent Framework. It's a six-layer stack that works like this:

• Xiaoyi is the system-level assistant, the front door for your requests.
• HMAF 2.0 handles task decomposition and coordinates the agents that do the work.
• AI base includes the open-source openPangu 2.0 model (505B parameters) and a 30B on-device model.
• System services—Ark engine, StarShield security, and the cross-device connectivity layer.
• Developer tools—DevEco Code and DevEco CLI.
• Scenario layer—spatial computing and other emerging use cases.

For developers, the shift is immediate: your app is no longer a passive icon. It can expose itself as an agent that the system can call. At the keynote, a demo showed a user saying, "Help me sign up for a marathon." Xiaoyi broke that into subtasks, then coordinated the health, calendar, and search agents to handle it.

Under the hood, you register a capability with HMAF, declare its input schema, and implement an onInvoke method that receives structured arguments. The system handles intent matching. You don't parse natural language; you get clean data.

Two Tracks for Developer Tools

Huawei's toolchain follows a two-track strategy. DevEco Code is the AI-powered IDE that plans, writes, compiles, and fixes code on its own—think of it as a copilot that actually drives. DevEco CLI is the opposite: it's a command-line interface that exposes HarmonyOS's atomic capabilities—build, debug, deploy—so you can plug them into your existing AI tools like Claude or Cursor.

DevEco Code suits new projects and small teams that want to go from zero to one fast. DevEco CLI fits larger teams with established CI pipelines; they don't need to change their workflow, just add a new skill.

Internally, DevEco Code is built on Huawei's self-developed Bifang engine (the "brain") and the open-source OpenCode framework (the "skeleton"). Bifang handles planning and tool use; OpenCode provides the terminal UI and plugin ecosystem. It's a hybrid approach—self-built for deep HarmonyOS integration, open-source for ecosystem compatibility.

One neat trick: the Plan Agent can auto-generate responsive layout code. If you say "this app should work on phones and TVs," it inserts breakpoint-based layout branches into your ArkTS components without you asking. That's not just code completion; that's the tool understanding product logic.

Recreational Apps Face a Fragmentation Headache

For small to mid-size teams building fitness, travel, or event apps, the biggest pain point is device fragmentation. HarmonyOS runs on everything from flagship phones to budget wearables, and each has different screen sizes, chips, and API levels. Testing on all of them is impossible for most teams, so bugs like install failures or layout glitches show up only after launch.

Huawei offers some relief. EasyGo Parallel View lets you adapt to foldables and tablets with a single config file. An automated UX checker can spot oversized images, text clipping, or overlapping elements and point you to the exact source line. But there are gaps: DevEco Code doesn't run on Linux, and it's still tied to DevEco Studio for the best experience.

The bigger issue is AI training data. ArkTS is young. Models trained on Swift or Kotlin produce solid code out of the box; for ArkTS, you'll need to manually fix 15–20% of generated code. That's not a tool deficiency—it's a corpus problem that takes time to solve.

How This Compares to Apple and Google

At their 2026 developer conferences, Apple and Google both talked about AI dev tools, but the framing was different. Apple treated Xcode and Apple Intelligence as separate stories. Google split its AI tools, models, and Android Studio into separate sessions. Huawei put everything—the dev tools, the runtime agents, the assistant—into one keynote and one architecture diagram.

That's not just presentation style. It signals a strategic bet: development-time agents and runtime agents are meant to work together as one system.

On pricing, Apple's Xcode is free but you pay for third-party models. Google bundles Gemini with enterprise plans. Huawei lets you use the built-in GLM-5.1 for free (50 calls per minute) or switch to DeepSeek or OpenAI. They're clearly trying to lower the barrier for developers.

Skill ecosystems differ too. Apple has a few official skills. Google is going cloud-first. Huawei ships 70+ skills covering multi-device dev, debugging, and service generation. Notably, both Apple and Huawei use the SKILL.md open format—so "skill-as-code" is becoming a de facto standard.

The Real Test: Bridging Dev-Time and Runtime Agents

Kuaishou, the video app, is the flagship case. Using HarmonyOS AI tools, they hit 80% AI code generation, 84% acceptance of AI-generated test cases, and a 1.7x boost in overall team efficiency. Two engineers now deliver phone, tablet, and car versions simultaneously—previously that took more.

But the interesting part isn't the code generation rate. Kuaishou already had its own AI coding tool with 30–40% generation rates, yet delivery speed didn't improve. The bottleneck was elsewhere: analysis, design, and refactoring. So they worked with Huawei to build a specialized skill for concurrency safety—a common pain point in HarmonyOS apps. That skill automates the whole loop, from analysis to validation. A task that took two people a week now takes half a day, and cold-start performance improved 16%.

The lesson: targeted skills beat generic code generation. That's a useful takeaway for any team building recreational apps—whether it's a fitness tracker, a hiking guide, or an event booking platform.

What Developers Should Do Now

If you're building for HarmonyOS, three moves make sense.

First, decide which tool track fits your team. New project? Go with DevEco Code. Existing system? Use DevEco CLI to integrate without a rewrite.

Second, check the 70+ existing skills. Someone's probably already solved the concurrency issue you're about to hit. Reuse their work.

Third, grab community knowledge packs like harmonyos-ai-skill—a single Markdown file that plugs HarmonyOS expertise into your favorite AI tool. It's a cheap way to offset the ArkTS corpus gap.

HarmonyOS 7 isn't perfect. Linux support is missing, the corpus gap is real, and the ecosystem is still maturing. But the direction is clear: they're betting that the deepest advantage isn't raw AI power, but the tight coupling of development-time and runtime agents. For developers building the next generation of recreational apps, that's worth paying attention to.