arXiv:2606.07085v1 [cs.SE] 5 Jun 2026
Porting Declarative UI to HarmonyOS: A Heuristic-guided LLM Approach Kunwu Zheng∗
Pengyu Xue∗
Zhen Yang†
Shandong University Qingdao, China [email protected]
Shandong University Qingdao, China [email protected]
Shandong University Qingdao, China [email protected]
Xiran Lyu
Peishi Lai
Mengying Zhao
Shandong University Qingdao, China [email protected]
Shandong University Qingdao, China [email protected]
Shandong University Qingdao, China [email protected]
Yutian Tang
Huizhi Zhang
Xianhang Li
University of Glasgow Glasgow, United Kingdom [email protected]
Shandong University Qingdao, China [email protected]
Shandong University Qingdao, China [email protected]
Linhao Wu
Chengyi Wang
Shandong University Qingdao, China [email protected]
Shandong University Qingdao, China [email protected]
Abstract
Keywords
As an emerging operating system, HarmonyOS has a significant demand for software migration from platforms such as Android and iOS, where the User Interface (UI) translation accounts for a critical link. However, the latest UI development has shifted to declarative paradigms, e.g., Kotlin Jetpack Compose (KJC) for Android, SwiftUI for iOS, and ArkUI for HarmonyOS, rendering prior translation approaches inapplicable, as they target either backend logic or legacy imperative UIs. As such, this paper targets ArkUI and proposes an automatic translation approach, namely ArkTrans, to port UI files from Android and iOS to HarmonyOS. ArkTrans overcomes two salient challenges during the translation: (1) Programming Language (PL) unfamiliarity, and (2) severe syntactic chaos. Towards the first challenge, ArkTrans heuristically constructs ArkUI skeletons by extracting metadata from source PL, thereby guiding LLMs’ initial translation. As for the second challenge, ArkTrans executes empirically revealed postfixing rules via pattern matching to repair most of the remaining syntactic errors. To examine the effectiveness of ArkTrans, we construct a 100-sample parallel UI page translation benchmark from KJC/SwiftUI to ArkUI at the file level. Extensive experiments demonstrate that LLMs with direct/one-shot prompting cannot translate a single compilable UI page. In contrast, at most 90.67% ArkTrans-translated files can be successfully compiled with high visual fidelity.
Declarative UI, ArkUI, Code Translation, Large Language Models
CCS Concepts • Software and its engineering → Software development techniques. ∗ These authors contributed equally to this work. † Corresponding author.
1
Introduction
As the mobile ecosystem continues to expand, Android and iOS dominate with a vast array of applications. In contrast, HarmonyOS, as an emerging operating system, suffers from a relative scarcity of software support. Automatically translating existing applications to HarmonyOS, therefore, presents a promising direction for rapidly enriching its software ecosystem. This paper focuses on mobile code translation from the perspective of the User Interface (UI), one of the most critical components of mobile applications [32]. However, the latest UI development has progressively updated to the declarative programming paradigm in practice [53, 8]. For example, Android applications use Kotlin Jetpack Compose (KJC) for UI development [23], iOS applications adopt SwiftUI [7], while applications on HarmonyOS are developed with ArkUI [53], which are three UI development frameworks of their respective PLs, i.e., Kotlin [19], Swift [25], and ArkTS [52]. Therefore, although Prior research on automatic program translation has achieved notable success across functional to repository levels, their proposed approaches are illsuited for translating mobile UIs. Because they primarily focused on backend logic, such as converting server-side software with complex control flows and data manipulations [47, 42, 16, 45]. Very few of the other research [9, 12] that lie in the mobile UI translation area remain within the scope of translating imperative UI, such as XML [18] and UIKit [35], leaving them powerless to apply to the latest declarative UI. Therefore, it is urgent to develop effective code translation tools for the latest mobile UI migration. Nonetheless, declarative UI migration from KJC and SwiftUI to ArkUI still faces two main challenges. (1) PL unfamiliarity. ArkUI
Kunwu Zheng, Pengyu Xue, Zhen Yang, Xiran Lyu, Peishi Lai, Mengying Zhao, Yutian Tang, Huizhi Zhang, Xianhang Li, Linhao Wu, and Chengyi Wang
is an emerging UI framework, officially launched in 2023. Hence, its existing corpus on code hosting platforms, such as Gitee [10] and GitHub [11], is relatively scarce, compared with other mainstream PLs, such as Python and Java. In this case, LLMs lack sufficient training examples to master their programming paradigm and PLspecific syntax [12, 52]. Our empirical study (shown in Section 4.1) also proved the inability of State-Of-The-Art (SOTA) LLMs in translating KJC and SwiftUI to ArkUI with direct prompting, even failing on any of their compilation. (2) Severe syntactic chaos. Owing to the inability to program with ArkUI, LLMs tend to directly copy the source PL’s syntax or even mix both the source and target syntax during the translation. According to our empirical study, 40% failures of direct prompting translation results stem from syntactic errors. In particular, even given effective guidance to familiarize LLMs with ArkUI programming, 51.4% syntactic errors remain unresolved. To address the above challenges, we propose ArkTrans with a heuristically constructed ArkUI skeleton for guiding LLMs in ArkUI programming and a post-fix engine to resolve those most common syntactic errors. Specifically, ArkTrans consists of four steps, namely Metadata Extraction (ME), Skeleton Construction (SC), LLM-driven Translation (LT), and Post-Fixing (PF). ME aims to hierarchically extract metadata from source UI files and construct UI trees for maintaining necessary elements and layouts. The SC step synthesizes a deterministic skeleton, thereby finalizing the UI topology with partial ArkUI code while ensuring the maximum preservation of the metadata that cannot be migrated with heuristics. Subsequently, LT invokes an LLM to translate the above ArkUI skeleton into executable code with a specific example for guidance. Finally, ArkTrans leverages the empirically revealed post-fixing rules to resolve the remaining syntactic errors. To examine the effectiveness of ArkTrans, we construct a 100sample parallel UI migration benchmark at the file level. It covers eight categories of application scenarios (e.g., E-commerce, smart home, and social media), consisting of equivalent KJC and SwiftUI code files for fairly evaluating their translation to ArkUI. Extensive experiments demonstrate the high effectiveness of ArkTrans. For KJC/SwiftUI-to-ArkUI translations with GPT-5.2 as the backbone, ArkTrans achieves a Compilation Success Rate at 53.33%– 90.67%. Regarding the visual fidelity, ArkTrans obtains a CLIP Similarity score of 45.59%–78.89% and a Color Histogram Similarity score of 30.23%–56.01% from the perspective of global metrics. Towards the local metrics, ArkTrans still maintains its superiority. It achieves a Position Score of 23.30%–47.00%, a Size Score of 24.50%–48.40%, a Color Score of 23.20%–46.30%, and a Text Integrity score of 47.70%–82.50%. In contrast, all SOTA LLMs under test with direct and one-shot prompting cannot even generate a compilable file, not to mention the visual fidelity after file rendering. Afterwards, we further conduct a series of ablation studies to explore the contribution of each component and verify the generality of ArkTrans on diverse LLMs, all proving that ArkTrans can be a powerful tool for enriching the HarmonyOS ecosystem. The contribution of this work is fourfold: (1) We construct the first KJC/SwiftUI-to-ArkUI translation benchmark, consisting of 100 file-level samples covering eight diverse application scenarios.
(2) We conduct the first empirical study on KJC/SwiftUI-to-ArkUI translation, summarizing a series of typical failures for guiding the design of ArkTrans. (3) We propose ArkTrans, a skeleton-guided and post-fixingenhanced code translation framework for porting declarative UIs to HarmonyOS. Accordingly, we establish a progressive evaluation system for both code executability and visual fidelity. (4) We conduct extensive experiments and empirically prove the effectiveness of ArkTrans. All code, benchmark, and results are shown in [1].
2
Approach
In this section, we elaborate on the methodology and design motivations of ArkTrans, a UI migration framework designed KJC/SwiftUIto-ArkUI translation.
2.1
Overview
Figure 1 presents the workflow of ArkTrans with a simplified translation example. ArkTrans accepts UI files of source-PLs (KJC or SwiftUI) as inputs and outputs semantically equivalent ArkUI code. Overall, ArkTrans consists of four main stages: (1) Metadata Extraction (ME): This stage parses the source UI file to extract its component hierarchies and associated properties for UI tree construction in JSON format. (2) Skeleton Construction (SC): Using the above UI tree, ArkTrans generates an ArkUI skeleton by performing cross-PL component mapping and establishes a layout constraint for follow-up semantic translation. (3) LLM-driven Translation (LT): This stage invokes an LLM to populate the skeleton and offer a one-shot example from the ArkUI skeleton to its corresponding code, enabling the LLM to generate syntactically correct code while strictly adhering to the pre-defined layout topology. (4) Post-Fixing (PF): This final stage uses a set of heuristic rules to fix common LLM errors identified in our empirical study. By resolving recurrent syntax issues through pattern matching, ArkTrans ensures the translated code follows the HarmonyOS compiler requirements and ArkUI standards.
2.2
Step 1: Metadata Extraction (ME)
ME aims to hierarchically extract metadata from source UI files to construct a structural UI tree, which maintains the necessary elements (e.g., components and attributes) and UI layouts for followup semantic translation. Each node in the tree is a tuple ⟨ comp, props, mod, children ⟩. comp: the component type (e.g., Button, Text); props: a set of key-value pairs (𝑘𝑝 , 𝑣 𝑝 ) representing named parameters passed to the component (e.g., {value: "Confirm"}); mod: a set of key-value pairs (𝑘𝑚 , 𝑣𝑚 ) representing chained modifier calls (e.g., {align: Alignment.CenterStart}); children: an ordered list of child nodes, preserving the nesting hierarchy of the original UI. As shown in Algorithm 1, we implement a recursive extraction process that leverages an Abstract Syntax Tree (AST) to identify UI patterns while filtering out non-UI logic. 2.2.1 Entry Point Localization. In declarative UI frameworks, initiating a UI page of mobile applications requires a segment of boilerplate configuration code as the entry for compilers to execute, which also serves as the root node of our entire UI tree. However, the syntax for these entry points varies significantly across platforms.
Porting Declarative UI to HarmonyOS: A Heuristic-guided LLM Approach
Figure 1: Workflow of ArkTrans
Algorithm 1 UI Tree Construction Require: Source files S , blacklist B Ensure: UI trees T = { comp, props, mod, children } 1: 𝑛 root ← LocateEntryPoint ( S) 2: Φ ← CollectCusCompDefs ( S, 𝑛 root ) 3: T ← Extract (𝑛 root , Φ, B ) 4: function Extract(𝑛 , Φ, B ) 5: if 𝑛 is not a function call or initializer call then 6: return null 7: 𝑛𝑎𝑚𝑒 ← GetCallName (𝑛) 8: if 𝑛𝑎𝑚𝑒 ∈ B or 𝑛𝑎𝑚𝑒 is not PascalCase then 9: return null 10: if 𝑛𝑎𝑚𝑒 ∈ Φ then 11: return Extract ( FetchCompDef (𝑛𝑎𝑚𝑒, Φ), Φ, B ) 12: T.𝑐ℎ𝑖𝑙𝑑𝑟𝑒𝑛 ← T ( {𝑛𝑎𝑚𝑒, ∅, ∅, [ ] } ) 13: for 𝑎 in GetArguments (𝑛) do ⊲ traverse arguments for 𝑛 14: if IsModifierCall (𝑎) then 15: T.mod [ GetModName (𝑎) ] ← ExtractValue (𝑎, Φ) 16: else if IsProperty (𝑎) then 17: T.props [ GetPropName (𝑎) ] ← ExtractValue (𝑎, Φ) 18: return T 19: function ExtractValue(𝑎, Φ) 20: if 𝑎 is literal or identifier then 21: return Normalize (𝑎, Φ) 22: else 23: return Extract (𝑎, Φ, B )
To ensure the extraction process begins at the correct hierarchical level, we implement the LocateEntryPoint (Line 1). For KJC, the algorithm parses the source code to an AST and locates top-level functions annotated with @Composable that possess no parameters, as these typically define the primary UI entry. For SwiftUI, the algorithm identifies struct declarations conforming to the View protocol and designates the internal body property as the starting point for recursive traversal. The LocateEntryPoint procedure isolates pure UI declarations from boilerplate configuration code, establishing a clear scanning boundary for subsequent extraction.
2.2.2 Component Identification. Following entry point localization, the algorithm recursively traverses the AST to identify UI components using a naming convention heuristic (Lines 5–9): an AST node 𝑛 is considered a potential UI component if it is a function call or initializer call that follows PascalCase. This rule applies uniformly across both frameworks: in KJC, UI components are typically declared as @Composable functions and instantiated via PascalCase function calls (e.g., Button, Column); in SwiftUI, components are defined as structs conforming to the View protocol and instantiated via PascalCase initializer calls within the body (e.g., VStack, Text). To eliminate non-visual interference, we apply a component blacklist (B) that prunes functional entities (Line 8). This blacklist includes PL-specific hooks such as LaunchedEffect in KJC, as well as SwiftUI’s property wrappers, e.g., @State, @Binding, and lifecycle modifiers, e.g., .onAppear. The complete list of blacklisted tokens is provided in our repository for reference [1]. Besides, the algorithm maintains a custom component set Φ, whose definitions are outside the entry point, via CollectCusCompDefs (Line 2). If an identified component refers to a locally defined one in Φ, the algorithm utilizes FetchCompDef (Line 11) to fetch its definition and parse its internal structure, ensuring that custom components are fully expanded into primitive UI elements. 2.2.3 Attribute Extraction and Recursion. Once a component node is confirmed, the algorithm harvests its associated properties and establishes ownership relationships (Lines 12-17). By iterating through the argument list, the algorithm captures chained calls and named parameters into the mod and props fields, respectively. If an argument is not a literal or identifier, it may be a nested component. Then, a sub-recursive call will be triggered via Extract (Line 23), ensuring that the parent-child nesting relationships within the source code are faithfully reconstructed as branches in the hierarchical UI tree. Line 25’s auxiliary function Normalize standardizes extracted values by removing quotes from strings, converting numeric strings to numbers, and resolving simple constant references.
2.3
Step 2: Skeleton Construction (SC)
Based on the aforementioned UI tree, the SC stage synthesizes a deterministic ArkUI code skeleton. Its primary objective is to finalize the UI topology while ensuring the maximum preservation of the metadata that cannot be migrated with heuristics. The detailed procedure is formalized in Algorithm 2. First, it retrieves a component template for node 𝑛 from D (line 3). D is a mapping dictionary, defining a series of mappable components, properties, and modifiers from source PLs (KJC/SwiftUI) to their ArkUI counterparts. The specific mapping table can be found at [1]. Next, the algorithm iterates over the component’s properties (lines 4–8): if a property is defined in D, it is injected directly into the template; otherwise, it is preserved as a comment. Modifiers are processed similarly (lines 9–13): known modifiers become chained calls (e.g., button().align().color()), while unknown ones are kept as comments. After handling the current node, the algorithm recursively builds skeletons for all child nodes (lines 14–16). This yields a complete ArkUI skeleton with all known attributes translated and unknown ones annotated.
Kunwu Zheng, Pengyu Xue, Zhen Yang, Xiran Lyu, Peishi Lai, Mengying Zhao, Yutian Tang, Huizhi Zhang, Xianhang Li, Linhao Wu, and Chengyi Wang
Algorithm 2 Skeleton Construction Require: UI tree Troot , Component Mapping Dictionary D Ensure: ArkUI code skeleton 𝑆 1: 𝑆 ← BuildSkeleton ( Troot ) 2: function BuildSkeleton(𝑛 ) 3: 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 ← D [𝑛.𝑐𝑜𝑚𝑝 ].𝑡𝑒𝑚𝑝𝑙𝑎𝑡𝑒 4: for (𝑘𝑝 , 𝑣𝑝 ) in 𝑛.𝑝𝑟𝑜𝑝𝑠 do 5: if D [𝑛.𝑐𝑜𝑚𝑝 ] has property 𝑘𝑝 then 6: 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 ← replace 𝑘𝑝 in 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 with 𝑣𝑝 7: else 8: 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 ← 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 + “ // prop: 𝑘𝑝 = 𝑣𝑝 ” 9: for (𝑘𝑚 , 𝑣𝑚 ) in 𝑛.𝑚𝑜𝑑 do 10: if D [𝑛.𝑐𝑜𝑚𝑝 ] has modifier 𝑘𝑚 then 11: 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 ← 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 + “.𝑘𝑚 (𝑣𝑚 )” 12: else 13: 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 ← 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 + “ // modifier: 𝑘𝑚 = 𝑣𝑚 ” 14: 𝑐ℎ𝑖𝑙𝑑𝑆𝑘𝑒𝑙𝑒𝑡𝑜𝑛𝑠 ← [ ] 15: for 𝑐 in 𝑛.𝑐ℎ𝑖𝑙𝑑𝑟𝑒𝑛 do 16: 𝑐ℎ𝑖𝑙𝑑𝑆𝑘𝑒𝑙𝑒𝑡𝑜𝑛𝑠.append ( BuildSkeleton (𝑐 ) ) 17: 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛 ← 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛.replace ( "%s", 𝑐ℎ𝑖𝑙𝑑𝑆𝑘𝑒𝑙𝑒𝑡𝑜𝑛𝑠 ) 18: return 𝑠𝑘𝑒𝑙𝑒𝑡𝑜𝑛
2.4
Step 3: LLM-driven Translation (LT)
In the ST stage, ArkTrans invokes an LLM to translate the ArkUI skeleton into executable code. To achieve this, we construct a structured prompting strategy and an associated skeleton-to-ArkUI example for specific guidance. 2.4.1 Prompt Structure. The prompt for Skeleton-to-ArkUI translation is divided into three functional segments: (1) the system role, (2) the contextual data, containing the aforementioned ArkUI skeleton and a set of color constants extracted from the metadata, and (3) an explicit translation instruction, along with associated basic requirements. The specific prompt can be found in [1]. This inclusion of explicit color metadata ensures the consistent preservation of visual styles throughout the migration, a benefit further validated by our ablation studies in Section 4.4. 2.4.2 One-shot Learning Example Illustration. Although the skeleton above has been partially transformed into ArkUI code via heuristics as mentioned in Section 2.3, it still has lots of annotated elements of the source PL that need to be translated. To familiarize LLMs with programming ArkUI code according to the associated skeleton, we craft a demonstration example (available in our repository [1]) to guide LLMs for in-context learning. The example covers most kinds of syntactic errors revealed in the empirical study of Section 4.1, including property assignment, modifier chaining, layout property expansion, component naming, and state management.
2.5
Step 4: Post-Fixing (PF)
Despite the provision of an ArkUI skeleton and demonstration example to familiarize LLMs with ArkUI programming, a series of syntactic errors still widely exist. To bridge this gap, the PF stage executes a post-fixing module through a series of deterministic transformations. These rules are summarized from the second phase of the empirical study in Section 4.1, where their formal definitions are as follows: 2.5.1 Constant Inlining (CI). In source-PL frameworks, design tokens, including colors, spacing, typography, and layout margins, are often stored in static classes. Specifically, KJC uses an object
declaration to hold these constants, while SwiftUI employs an enum with static properties. During migration, LLMs frequently copy these PL-specific class references into the translated ArkUI code and mixes into component instantiation. The red region of Figure 2(b) present an example, where the Designtoken is a copied colors class, and Designtoken.primaryColor is mistakenly referenced, leading to compilation failure of unresolved references to these external constant holders. To resolve this issue, we design the following rules.
Figure 2: A constant inlining example Let 𝑆 be the translated code containing unresolved references to externally defined constants. Let K ∈ 𝑆 be an identifier set of design tokens that are defined outside all components. We construct a substitution mapping: Σ(𝑆) = {𝑘 ↦→ 𝑣 | 𝑣 = lookup(𝑘), K ∈ 𝑆, 𝑘 ∈ K, 𝑣 ∈ 𝑆 } where lookup returns a constant value 𝑣 associated with 𝑘 based on the external definitions. Σ(𝑆) is the inlined code, in which every occurrence of 𝑘 ∈ K in 𝑆 is replaced by its matched literal 𝑣. After inlining, any class (e.g., DesignTokens) that is no longer referenced becomes dead. In fact, originally, they cannot be compiled in the HarmonyOS environment either. Formally, the transformation Γ removes all such unused class definitions: Γ(𝑆) = Σ(𝑆) \ {𝑐 del ∈ 𝐶 | refs(𝑐 del, Σ(𝑆)) == 0} where 𝐶 denotes all the class definitions, 𝑐 del denotes the class definitions of design tokens to be removed, and refs(𝑐𝑑𝑒𝑙 , Σ(𝑆)) denotes the removing condition: a 𝑐 del is no longer referenced by inlined code Σ(𝑆). The operator \prunes these obsolete classes, producing a clean output, as shown in Figure 2. 2.5.2 Lexical Rectification (LR). The red region of Figure 3(b) demonstrates another syntactic copy example that KJC’s toInt() appears directly in the generated code, causing compilation errors. To resolve such lexical-level errors, we design a function T𝑙𝑒𝑥 (𝑡) to replace lexical tokens 𝑡 (e.g., basic APIs, operators, and styles) from the source PL with their ArkUI counterparts 𝑡 ′ , if the mapping exists. Formally, ( 𝑡 ′ if (𝑡 ↦→ 𝑡 ′ ) ∈ Tmap T𝑙𝑒𝑥 (𝑡) = 𝑡 otherwise where Tmap is a mapping of lexical tokens (e.g., mapping Kotlin’s toInt() to ArkTS’s Number()).
Figure 3: A rectifying lexical/layout property example
Porting Declarative UI to HarmonyOS: A Heuristic-guided LLM Approach
2.5.3 Layout Property Rectification (LPR). In source-PL frameworks, layout properties padding and margin can be specified with directional shorthands (horizontal, vertical) that do not exist in ArkUI. However, such source patterns tend to be copied to the translated ArkUI code, thereby causing syntactic errors as shown in the red region of Figure 3(b). To that end, we define a mapping Ψ that expands each source property (𝑘, 𝑣) into a set of ArkUI-compatible properties: (Ð 𝑞𝑖 ∈Ψ(𝑘 ) {(𝑞𝑖 , 𝑣)}, if 𝑘 ∈ dom(Ψ) T𝑙𝑝 (𝑘, 𝑣) = {(𝑘, 𝑣)}, otherwise where dom(Ψ) is the set of source shorthands that have a defined expansion, and Ψ(𝑘) is the corresponding ArkUI layout property names composed of a set of 𝑞𝑖 given 𝑘. For instance, when Ψ(horizontal) = {left, right}, horizontal: 16 expands to {left : 16, right : 16}. The transformation is applied to every layout property in the code, producing a syntactically correct ArkUI component and largely maintaining the visual consistency as shown in the green region of Figure 3. 2.5.4 Structural Integrity Validation (SIV). Even after constant inlining and syntactic alignment, the generated code may still contain structural errors that violate ArkUI’s component placement rules or result in mismatched delimiters. Figure 4 illustrates a typical example: the Blank component, used for flexible spacing, is only valid when placed inside a linear layout container (Row or Column). However, LLMs may incorrectly generate a Blank inside a non-linear container such as Stack, List, or Grid. Additionally, the code may have unbalanced braces, causing syntax errors. To address these issues, we define a two-stage structural validation process.
Figure 4: A structural integrity validation example Let H be the component hierarchy of the generated code. We define a structural validator Ω that checks every node 𝑛 against the set S of valid parent-child pairings in ArkUI: ( 𝑛 if (𝑛, par(𝑛)) ∈ S Ω(𝑛) = 𝜏 (𝑛) otherwise where par(𝑛) denotes the parent node of 𝑛, and 𝜏 (𝑛) is a repair function that replaces an invalid node with a semantically neutral but syntactically valid substitute. As shown in Figure 4(b), a Blank appears outside a Row or Column, 𝜏 precisely replaces it with an empty Column. This preserves the structural position in the render tree while avoiding compilation failures. In addition to structural validity, the generated code may contain unbalanced braces (missing closing parentheses or curly braces). We define a balancing operator B that takes the generated code 𝑆 and ensures that all delimiters in 𝐷 = {{, }, (, ), [, ]} are properly matched. In practice, the generated code typically only suffers from missing trailing closing brackets; therefore, appending the necessary closing delimiters at the end of 𝑆 suffices to resolve: B (𝑆) = 𝑆 ⊕ 𝑑 𝑘 ,
𝑘 = max(0, Δ𝐷 (𝑆))
where Δ𝐷 (𝑆) computes the imbalance (opening minus closing), and 𝑑 ∈ 𝐷 is the corresponding closing delimiter. ⊕ denotes the concatenation between code and delimiters. If 𝑆 contains one extra opening brace, B appends a single closing brace.
3
Evaluation Setup
This section presents the associated setup for experimentation.
3.1
Research Questions
We propose Research Questions (RQs) below to comprehensively evaluate ArkTrans in the context of cross-platform UI migration. RQ1 (Empirical Study): What are the major challenges when migrating KJC/SwiftUI code to ArkUI with LLMs? This RQ includes two phases. First, we analyze the compilation failures of GPT-5.2, one of the SOTA LLMs, when directly translating 50 UI files in total without any auxiliary information. Secondly, we equip GPT-5.2 with skeleton guidance to re-evaluate on the same dataset to quantify the remaining errors that motivate the design of our rule-based post-fixing stages. RQ2 (Overall Performance): How effective is ArkTrans in UI page migration from KJC/SwiftUI to ArkUI? The migration from KJC/SwiftUI to ArkUI involves significant paradigm shifts. This RQ assesses the UI page migration efficacy of ArkTrans from the aspects of code executability and visual fidelity, where the latter can be further divided into global and local metrics (Detailed in Section 3.4), thereby ensuring a systematic examination. Since ArkTrans is the first UI migration approach among declarative PLs, we utilize direct and one-shot prompting as primary baselines. To verify its generality, we conduct evaluations on 150 unseen samples in total, all of which are strictly excluded from our empirical analysis in RQ1. RQ3 (Ablation Study): What is the contribution of each core component to the performance of ArkTrans? ArkTrans integrates several key modules, including the metadata extraction from source-PL (ME), the construction of the ArkUI skeleton (SC), in-context learning through one-shot demonstrations (LT), and rulebased post-fixing (PF). Evaluating the incremental contribution of these components is essential to understanding how the above components collectively mitigate the zero-success barrier observed in unguided LLM translation. RQ4 (Cross-Model Generalizability): To what extent does ArkTrans maintain its effectiveness across diverse LLMs? The performance of UI migration often depends on the underlying reasoning capabilities of the backbone LLMs. This RQ verifies the robustness of ArkTrans by integrating it with various SOTA LLMs, such as GPT-5.2, DeepSeek-V3.2, Kimi-K2-turbo, and GLM-5. We aim to determine whether ArkTrans can consistently enhance the performance of diverse model architectures, effectively decoupling migration quality from raw model abilities.
3.2
Benchmark
To our knowledge, there is no existing benchmark for assessing KJC/SwiftUI-to-ArkUI translation. In addition, files are the primary
Kunwu Zheng, Pengyu Xue, Zhen Yang, Xiran Lyu, Peishi Lai, Mengying Zhao, Yutian Tang, Huizhi Zhang, Xianhang Li, Linhao Wu, and Chengyi Wang
compilation unit in UI pages. Thus, we manually construct a filelevel UI migration benchmark in this work, which costs 200 personhours. In the field of code translation, the construction of highquality parallel benchmarks typically follows the paradigm of starting from a calibration PL and manually extending it to target PLs [47, 45, 46]. To construct the benchmark, three software engineers, each with over three years of professional mobile development experience, manually implemented various UI effects derived from open-source Android projects using KJC. These implementations were then manually ported to SwiftUI to create functionally equivalent counterparts. The development process strictly adhered to standardized naming and layout conventions; consequently, each implementation was engineered as a standalone page file, maintaining zero dependencies on external files or third-party libraries. Table 1: Statistical summary of the benchmark
code snippet and its corresponding ArkUI implementation) within the prompt. Notably, to ensure a fair comparison, the example used in One-shot Prompting are consistent with the example provided to ArkTrans. For RQ3 and RQ4, we exclusively employ Direct Prompting as the baseline. Detailed prompt and specific one-shot examples are publicly available in our repository [1].
3.4
Evaluation Metrics
LOC
DEP
Previous research [9, 12] on UI migration has largely remained at the level of measuring compilation success rates or overall visual similarity, lacking a systematic evaluation for fine-grained elements against the complicated UI pages. Inspired by the UI code generation area [36], we adapt a progressive evaluation system spanning two aspects: code executability and visual fidelity. In particular, the latter is further partitioned into global and local metrics for finegrained analysis. For all the aforementioned metrics, higher values indicate superior migration performance.
E-commerce Finance Lifestyle Smart Home Productivity Education Social Media Utilities
15 13 16 11 13 7 15 10
2024.2 2062.8 2035.4 2000.4 1772.8 2217.1 2003.2 2282.7
22.3 18.8 15.4 20.1 16.8 23.0 19.8 29.8
280.7 278.4 322.1 315.9 256.2 289.1 289.1 295.6
7.1 6.6 5.8 5.8 7.3 7.3 6.7 7.5
1440.6 1716.5 1395.1 1396.7 1485.4 1467.0 1298.4 1469.7
21.9 20.5 19.5 20.2 18.8 23.1 19.1 28.3
210.3 250.5 218.9 227.0 216.8 230.0 208.4 221.5
7.7 8.2 6.6 7.1 7.7 8.6 7.9 8.3
3.4.1 Code Executability. Compilation Success Rate (CSR): This metric computes the ratio of translated samples that can be successfully compiled within the HarmonyOS environment at the file level. CSR ( Í𝑁is defined as follows: 1 if Compile(𝑦ˆ𝑘 ) → success 𝑘=1 𝑐𝑠 (𝑦ˆ𝑘 ) , where 𝑐𝑠 (𝑦ˆ𝑘 ) = 𝐶𝑆𝑅 = 𝑁 0 if Compile(𝑦ˆ𝑘 ) → error
Overall
100
2050.2
20.7
290.9
6.8
1458.7
21.4
222.9
7.8
where 𝑁 denotes the total number of samples (files) and 𝑦ˆ𝑘 represents the 𝑘-th translated ArkUI file.
KJC Category
SwiftUI
# TK
CP
LOC
DEP
TK
CP
Note: # denotes the number of tasks; TK, CP, LOC, and DEP represent the average values of Tokens, Number of UI Components, Lines of Code, and Maximum Nesting Depth, respectively.
To ensure that the translated SwiftUI code achieves faithful consistency with the original Kotlin calibration in terms of both functionality and visual presentation, we introduce a rigorous verification mechanism. Beyond manual code review, we execute the UI page files and compare their rendered screenshots. A translation pair is considered consistent and formally included in the benchmark only if it satisfies a strict multi-metric threshold, where the visual similarity metrics defined in Section 3.4 (CLIP, CH, Pos, Size, Color, and Text) should exceed 0.9. For any samples failing to meet this comprehensive criterion, the translation team performed iterative calibration and re-translation. Table 1 provides a comprehensive breakdown of the benchmark, including per-domain distribution and structural metrics for the 100 high-quality parallel UI page files. Notably, E-commerce (15%), Social Media (15%), and Lifestyle (16%) constitute the majority of the samples, ensuring the benchmark covers the most representative interaction patterns in current mobile applications. For further analysis, we randomly partition the benchmark into two subsets: 25% of the page files are designated for an empirical study in RQ1, while the remaining 75% serve as the test set for evaluation in RQ2–RQ4.
3.3
Baselines
For RQ2, to evaluate the inherent capabilities of LLMs in UI code translation, we employ two baseline strategies: Direct Prompting and One-shot Prompting. Direct Prompting serves as a zero-shot baseline, representing the LLM’s raw translation performance without any external guidance. Building upon this, One-shot Prompting incorporates an end-to-end translation example (i.e., a source UI
3.4.2 Visual Fidelity. To holistically assess visual similarity, we employ both global and local metrics. (1) Global Metrics. CLIP Similarity (CLIP): We measure highlevel semantic alignment using a pre-trained vision-language model, namely CLIP [33]. For clarity, we use the model name as an abbreviation for this metric. 𝐸 (𝐼𝑅 ) · 𝐸 (𝐼𝐺 ) 𝐶𝐿𝐼𝑃 = ∥𝐸 (𝐼𝑅 )∥∥𝐸 (𝐼𝐺 )∥ where 𝐼𝑅 and 𝐼𝐺 denote the reference and generated UI pages, respectively. 𝐸 (·) denotes using CLIP-ViT-B/32 to encode UI pages as embeddings for similarity comparison. Color Histogram Similarity (CH): We quantify global tonal consistency by the intersection of normalized 48-bin HSV [38] 48 histograms: ∑︁ 𝐶𝐻 = min(𝐻𝑅 (𝑘), 𝐻𝐺 (𝑘)) 𝑘=1
where 𝐻𝑅 and 𝐻𝐺 are the HSV histograms of 𝐼𝑅 and 𝐼𝐺 . (2) Local Metrics. Considering the complicated UI designs, we propose a multi-strategy block extraction pipeline using diverse image processing techniques, thereby improving the extraction accuracy for follow-up block-wise evaluation. Specifically, (1) we employ MSER [24] to detect small containers. (2) To capture largescale containers and layout boundaries, we utilize Canny edge detection [2] followed by morphological closing [14]. This combination bridges fragmented edge pixels into closed structural units, preventing the omission of subtle layout frames. (3) Color quantization [15] is concurrently applied to segment the blocks with substantial chromatic differences. All candidate blocks undergo Non-Maximum Suppression (NMS) [28] with an empirically determined IoU threshold of 0.6 to prune redundant detections. This
Porting Declarative UI to HarmonyOS: A Heuristic-guided LLM Approach
above process yields the final block sets 𝑅 = {𝑟 1, ..., 𝑟𝑚 } from the reference UI (𝐼𝑅 ) and 𝐺 = {𝑔1, ..., 𝑔𝑛 } from the generated UI (𝐼𝐺 ), where 𝑚 and 𝑛 are the numbers of detected blocks in each image. We establish optimal matches 𝑀 = {(𝑟, 𝑔)} using the Jonker-Volgenant algorithm [22] to minimize a joint cost of spatial and chromatic distances. To ensure the evaluation aligns with human visual perception, we propose an area-weighted scoring mechanism that prioritizes visually larger blocks. First, we follow [36] to introduce the Bilateral Area Coverage (𝐶) for global quality constraint, which simultaneously penalizes component omissions and hallucinations during LLM generation by normalizing the matched area of block sets from both reference and generated UI components against their total Í block area: (𝑟,𝑔) ∈𝑀 (𝐴(𝑟 ) + 𝐴(𝑔)) Í 𝐶=Í 𝑟 ∈𝑅 𝐴(𝑟 ) + 𝑔∈𝐺 𝐴(𝑔) where 𝐴(𝑟 ) and 𝐴(𝑔) denote the areas (in pixels) of blocks 𝑟 and 𝑔, respectively. Subsequently, we propose to employ the reference area 𝐴(𝑟 ) as a weighting factor for each pair of blocks in the followup score calculation, thereby ensuring that larger blocks account for more proportions to final scores. Each local metric is defined as follows: Position Score (Pos): this metric measures the area-weighted spatial deviation distance among all (𝑟, 𝑔) in 𝑀. The lower the deviation distance, the higher the Pos, meaning the higher-quality of translated code. The score is defined as: −2·𝑑𝑝𝑜𝑠 (𝑟,𝑔) · 𝐴(𝑟 ) (𝑟,𝑔) ∈𝑀 𝑒 Í 𝑃𝑜𝑠 = 𝐶 × 𝑟 ∈𝑀 𝐴(𝑟 ) √︃ 𝑔 𝑔 where 𝑑𝑝𝑜𝑠 (𝑟, 𝑔) = (𝑐 𝑥𝑟 − 𝑐 𝑥 ) 2 + (𝑐 𝑟𝑦 − 𝑐 𝑦 ) 2 is the Euclidean dis-
Í
tance between the normalized centers (𝑐 𝑥 , 𝑐 𝑦 ) ∈ [0, 1] 2 of blocks 𝑟 and 𝑔. The deviation score follows a Gaussian decay paradigm [17]. Size Score (Size): This metric evaluates area-weighted size fidelity through normalized width and height offsets. The score is Í defined as: (𝑟,𝑔) ∈𝑀 (1 − |𝑤 𝑟 − 𝑤𝑔 | − |ℎ𝑟 − ℎ𝑔 |) · 𝐴(𝑟 ) Í 𝑆𝑖𝑧𝑒 = 𝐶 × 𝑟 ∈𝑀 𝐴(𝑟 ) where 𝑤𝑟 , ℎ𝑟 and 𝑤𝑔 , ℎ𝑔 represent the width and height proportions of blocks 𝑟 and 𝑔 relative to the whole page size (𝑊 , 𝐻 ). This proportional normalization ensures a resolution-invariant evaluation, preventing scores from being biased by differing image scales. Color Score (Color): This metric evaluates area-weighted chromatic accuracy via HSV histogram intersection for all matched pairs (𝑟, 𝑔) ∈ 𝑀. The score is defined as: Í Í𝐾 min(ℎ (𝑘), ℎ (𝑘)) · 𝐴(𝑟 ) 𝑟 𝑔 (𝑟,𝑔) ∈𝑀 𝑘=1 Í 𝐶𝑜𝑙𝑜𝑟 = 𝐶 × 𝑟 ∈𝑀 𝐴(𝑟 ) where ℎ𝑟 and ℎ𝑔 represent the color distribution ratios (normalized HSV histograms) of blocks 𝑟 and 𝑔, and 𝐾 denotes the total number of bins in the color space. Each bin 𝑘 ∈ {1, . . . , 𝐾 } acts as a specific color category; the term min(ℎ𝑟 (𝑘), ℎ𝑔 (𝑘)) calculates the common overlap of these color categories between the two blocks. Textual Integrity (Text): We identify textual blocks and extract their content using EasyOCR [21] from matched blocks (𝑟, 𝑔) ∈ 𝑀. On the basis of only textual block pairs 𝑀𝑡𝑒𝑥𝑡 ⊆ 𝑀, we define Text below:
Í 𝑇 𝑒𝑥𝑡 = 𝐶𝑡𝑒𝑥𝑡 ×
(𝑟,𝑔) ∈𝑀𝑡𝑒𝑥𝑡 𝑠𝑡𝑒𝑥𝑡 (𝑟, 𝑔) · 𝐴(𝑟 )
Í
𝑟 ∈𝑀𝑡𝑒𝑥𝑡 𝐴(𝑟 )
2· |OCR(𝑟 )∩OCR(𝑔) |
where 𝑠𝑡𝑒𝑥𝑡 (𝑟, 𝑔) = |OCR(𝑟 ) |+|OCR(𝑔) | is the character-level SørensenDice similarity[37] between the extracted text strings, and 𝐶𝑡𝑒𝑥𝑡 is the bilateral area coverage computed exclusively on textual blocks.
3.5
Implementation Details
We employ four state-of-the-art LLMs for evaluation: GPT-5.2 [29], Kimi-K2-Turbo [26], GLM-5 [51], and DeepSeek-V3.2 [6], released between 2025 and 2026. Among these, Kimi-K2-Turbo has 1 trillion parameters, GLM-5 has 744 billion, DeepSeek-V3.2 has 671 billion, while GPT-5.2’s parameter count has not been disclosed. To implement the above LLMs, we invoke their corresponding APIs via Moonshot AI, Zhipu AI, DeepSeek, and OpenAI. During the inference on all experiments, we set the temperature 𝑡 = 0 and sampling number 𝑛 = 1 to obtain deterministic outputs, minimizing randomness and ensuring reproducibility. All other hyperparameters are kept at their default values. For the construction of UI trees and ArkUI skeletons, we utilize tree-sitter-kotlin (v1.1.0) and treesitter-swift (v0.0.1) to parse the source code into ASTs. We conduct our experiments on the latest mobile operating systems available at the time of writing: Android 16 (API 36), iOS 18.6, and HarmonyOS 6.0.2. To ensure a consistent screen size across platforms, we use the iPhone SE (3rd generation) simulator for iOS and configure equivalent screen dimensions for Android and HarmonyOS. The screen resolution is uniformly set to 720 × 1280 at 320 DPI across all platforms, with the iOS simulator configured to the closest available dimensions (750 × 1334) while maintaining the same physical density.
4
Evaluation Results
This section discusses the experimental results of ArkTrans.
4.1
RQ1: Empirical Study
To understand the challenges of migrating KJC and SwiftUI code to ArkUI, we selected 25 files from each PL (50 in total) and used GPT-5.2 to perform direct translation without any auxiliary information, and analyzed the compilation errors; the remaining 75 files are used in subsequent research questions. None of the 50 outputs compiled successfully. Manual inspection revealed a total of 847 errors, averaging about 17 errors per file. The overwhelming majority of errors, about 60% are structural retention errors: the LLM directly retains the expression patterns from the source framework, which often violates ArkUI’s layout rules. The remaining 40% are syntactic residue errors that fall into five typical categories, mirroring the syntactic differences illustrated in Figure 5: property assignment(a, 10.1%), modifier chaining(b, 32.5%), layout property shorthands(c, 27.4%), component naming(d, 20.0%), and state management(e, 10.0%). These results confirm that direct LLM translations fail completely on the HarmonyOS platform, because the SOTA LLM is unfamiliar with ArkUI programming in the absence of effective guidance. In the second phase, we followed the first three steps of ArkTrans to examine the translation effectiveness on the same 50 KJC and SwiftUI files. We found that although most of the structure
Kunwu Zheng, Pengyu Xue, Zhen Yang, Xiran Lyu, Peishi Lai, Mengying Zhao, Yutian Tang, Huizhi Zhang, Xianhang Li, Linhao Wu, and Chengyi Wang
Figure 5: Syntactic differences across frameworks retention errors have been eliminated, 51.4% of the original syntactic errors persist, distributed more scattered and subtle, such as unresolved constant references (e.g., referring to a primaryColor), lexical residuals (e.g., invoking toInt()), layout shorthands (e.g., using padding(horizontal)), and structural violations (e.g., Blank inside Stack). This demonstrates that general guidance is insufficient for addressing various kinds of syntactic errors. Rather, we should perhaps design targeted fixing strategies. x Finding 1: SOTA LLMs, such as GPT-5.2, face two main challenges when translating KJC/SwiftUI to ArkUI, one is PL unfamiliarity and the second is severe syntactic errors.
4.2
x Finding 3: SwiftUI-to-ArkUI migration consistently demonstrates lower performance on executability and visual fidelity, owing to the more prominent syntactic conflicts against ArkUI.
RQ2: Overall Performance
ArkTrans vs. Direct LLM prompting. GPT-5.2 is used in this RQ as the backbone LLM for both ArkTrans and baselines. Table 2 summarizes the performance comparison between ArkTrans and two baseline prompting strategies (i.e., Direct and One-shot Prompting). As illustrated, ArkTrans substantially outperforms the baselines in both code executability and visual fidelity across all tested source PLs. Specifically, while both Direct and One-shot Prompting fail to produce any compilable code (0.00% CSR), ArkTrans achieves a high CSR of 53.33%–90.67%. This contrast suggests that even with a high-quality demonstration, the profound paradigm gaps remain unbridgeable for SOTA LLMs through simple prompting. Beyond executability, ArkTrans exhibits superior performance in visual consistency. For global layout reconstruction, ArkTrans achieves scores of 30.23%–56.01% for CH and 45.59%-78.89% for CLIP across KJC/SwiftUI-to-ArkUI translations. This consistent improvement is further evidenced by local metrics: ArkTrans maintains high fidelity with scores of 47.70%–82.50% for Text, 23.00%-47.00% for Pos, 24.50%–48.40% for Size, and 23.20%–46.30% for Color. These results confirm its efficacy in preserving the fine-grained visual attributes of the original UI. x Finding 2: ArkTrans significantly enhances UI translation performance, achieving a CSR of up to 53.33%-90.67% where baselines completely fail. It successfully preserves both global visual style (CH/CLIP) and local layout (Pos/Size/Color/Text).
Table 2: Effectiveness of ArkTrans and baselines Visual Fidelity (G) Sou. PL
Method
Visual Fidelity (L)
CSR (%) CH
CLIP
Pos
Size
Color
Text
KJC
Direct Prompting One-shot Prompting ArkTrans (Ours)
0.00 0.00 90.67
0.00 0.00 56.01
0.00 0.00 78.89
0.00 0.00 47.00
0.00 0.00 48.40
0.00 0.00 46.30
0.00 0.00 82.50
SwiftUI
Direct Prompting One-shot Prompting ArkTrans (Ours)
0.00 0.00 53.33
0.00 0.00 30.23
0.00 0.00 45.59
0.00 0.00 23.30
0.00 0.00 24.50
0.00 0.00 23.20
0.00 0.00 47.70
Note: G denotes Global Metrics, L denotes Local Metrics.
Comparison among translation directions. When comparing different migration paths, we observe that KJC-to-ArkUI migration generally outperforms SwiftUI-to-ArkUI across most metrics. As shown in Table 2, the CSR for KJC reaches 90.67%, which is 37.34% higher than that of SwiftUI (53.33%). This performance gap extends to Visual Fidelity, where KJC achieves significantly higher CH (56.01% vs. 30.23%), CLIP (78.89% vs. 45.59%), Pos (47.00% vs. 23.30%), Size (48.40% vs. 24.50%), Color (46.30% vs. 23.20%), and Text (82.50% vs. 47.70%) scores. This disparity stems from the inherent complexity of SwiftUI-to-ArkUI migration. SwiftUI’s reliance on implicit type inference and nested declarative syntax frequently conflicts with ArkTS’s rigid static type-checking and strict @Builder scoping rules. For instance, ArkTS often fails to compile array literals without explicit interface definitions, an issue rarely encountered in Swift, triggering “non-inferrable type” errors. Similarly, SwiftUI’s nested UI declarations often violate ArkUI’s @Builder isolation policy, leading LLMs to define UI components outside valid scopes or mix non-UI code within UI blocks. These errors are far less prevalent in the KJC-to-ArkUI translation, explaining the observed performance gap.
4.3
RQ3: Ablation Study
RQ2 evaluates how each core component of ArkTrans contributes to the overall UI translation performance. GPT-5.2 is still adopted as the backbone LLM throughout this RQ. For a more systematic evaluation, we define four configurations (from A to D) that progressively integrate components from the baseline toward the full framework: Configuration A (+ UI Tree): Builds upon the Direct LLM prompting by incorporating the extracted JSON-format UI tree of the source language (KJC/SwiftUI), thereby providing the model with explicit structural information as a reference. Configuration B (+ ArkUI Skeleton): Building on A, this configuration further replaces the UI tree with the constructed ArkUI skeleton for translation reference, thereby providing ArkUI-specific guidance. Configuration C (+ One-shot examples): Adds a one-shot example of translating ArkUI Skeleton to ArkUI code as an extra element for the prompt of Configuration B, thereby guiding the LLM in handling complex property mappings and syntax conventions. Configuration D (Full ArkTrans): The complete framework, which introduces rule-based post-fixing to deterministically resolve remaining syntax errors and refine layout attributes after the initial translation. Table 3 summarizes the results of the ablation study across two migration paths. Specifically, the experimental results reveal that incorporating the UI tree (A) alone is insufficient to break the 0.00% CSR barrier for both KJC/SwiftUI-to-ArkUI translations. This is explainable as UI trees can only improve LLMs’ code understanding to source PLs by explicitly providing necessary UI components, attributes, and their whole layout, yet they lack the specific guidance for cross-PL translation. However, the introduction of the ArkUI
Porting Declarative UI to HarmonyOS: A Heuristic-guided LLM Approach
Table 3: Ablation study of different components in ArkTrans Visual Fidelity (G) Sou. PL
Variant
Visual Fidelity (L)
CSR (%) CH
CLIP
Pos
Size
Color
Text
KJC
Direct Prompting A: + Source UI Tree B: + ArkUI Skeleton C: + One-shot example D: Full ArkTrans
0.00 0.00 13.33 50.67 90.67
0.00 0.00 8.52 27.94 56.01
0.00 0.00 11.41 43.53 78.89
0.00 0.00 7.90 24.40 47.00
0.00 0.00 8.50 25.50 48.40
0.00 0.00 6.40 24.80 46.30
0.00 0.00 12.50 48.00 82.50
SwiftUI
Direct Prompting A: + Source UI Tree B: + ArkUI Skeleton C: + One-shot example D: Full ArkTrans
0.00 0.00 8.00 21.33 53.33
0.00 0.00 4.58 14.42 30.23
0.00 0.00 6.83 18.86 45.59
0.00 0.00 3.10 11.40 23.30
0.00 0.00 3.40 10.50 24.50
0.00 0.00 2.80 9.80 23.20
0.00 0.00 7.00 16.90 47.70
skeleton (B) achieves a breakthrough, especially in code executability, reaching 13.33% and 8.00% on CSR for KJC- and SwiftUI-toArkUI translations, respectively. As for other metrics related to visual fidelity, the performance improvements are also significant and break the 0.00% barriers as well. Considering that the ArkUI skeleton carries partial ArkUI code for constraining the whole layout, as well as component and attribute placeholders for LLMs to populate, LLMs can obtain more hints about the ArkUI syntax and are allowed to focus on filling domain-specific details rather than inferring the entire component hierarchy with an unfamiliar PL. Afterwards, offering an example about how to translate the ArkUI skeleton to its corresponding code (C) triggers a significant performance leap, elevating to 50.67% and 21.33% on CSR for KJC/SwiftUI-to-ArkUI translations, respectively. As for the visual fidelity, the one-shot example also brings significant improvements by 200.00%–287.50% and 141.43%–267.74% for both translation directions across most global and local metrics, respectively, against the performance of (B). This indicates that demonstrations effectively instruct LLMs to master the specific ArkUI syntax and their mapping relations to KJC and SwiftUI when translating skeletons. The final transition to the Full ArkTrans (D) provides the most substantial boost in both executability and visual fidelity. By introducing rule-based post-fixing, ArkTrans improves CSR for KJC/SwiftUI-to-ArkUI translations by 78.94% and 150.02%, respectively. In particular, 90.67% KJC samples can be successfully executed after translation. Regarding the global metrics in visual fidelity, the post-fixing step brings 81.23%–100.47% and 109.64%–141.72% lifting for both translation directions, respectively. Towards the local aspect, the improvements continue with a lifting of 71.88%–92.62% and 104.39%–182.25%, respectively. This dramatic lifting demonstrates that while LLMs can generate fully executable UI pages for lots of samples with preceding guidance, many syntactic errors still exist around the translated code, leading to visual deviation from the original UI designs. Our post-fixing step effectively bridges this gap by applying deterministic corrections, ensuring that the generated ArkUI code is not only syntactically correct but also visually consistent with the source UI.
Figure 6: Ablation study of theme color metadata
Table 4: Ablation study of individual PF components on CSR Sou. PL
Full ArKTrans
w/o CI
w/o LR
w/o LPR
w/o SIV
KJC SwiftUI
90.67 53.33
81.33 33.33
58.67 24.00
78.67 33.33
72.00 30.67
Note: CI, LR, LPR, and SIV denote Constant Inlining, Lexical Rectification, Layout Property Rectification, and Structural Integrity Validation.
To investigate the necessity of offering color constraints in prompt, we remove the “Theme Colors ({color_refs})” from the input prompt of Step 3. As shown in Figure 6 (a), the absence of explicit color mapping leads to a holistic performance collapse across all metrics: Color fidelity suffers the most drastic relative decline of 43.20% (from 46.30% to 26.30%), followed by a 39.85% drop in CH, a 32.36% decrease in CSR, and declines of 32.27%, 31.64%, 26.17%, and 24.79% for CLIP, Pos, Size, and Text scores. As illustrated in Figure 6, comparing the reference UI (b) with the outputs from the full ArkTrans (c) and the variant without color prompts (d), the chromatic deviation is strikingly evident; specifically, the Color score for this sample plummeted from 81.20% to 40.47%, demonstrating that color references are indispensable for maintaining both the structural and visual integrity of the translated UI. To assess the contribution of each PF module, we conduct an ablation study by removing each module in turn and measuring the compilation success rate (CSR). Since these modules only correct syntactic and structural errors without altering the intended visual appearance, we focus on CSR as the primary indicator for this ablation. Table 4 reports the CSR for both KJC/SwiftUI-to-ArkUI translations. Removing any single component leads to a noticeable decline, with the most significant drop observed when lexical rectification is omitted. These results confirm that each PF module, particularly LR, contributes indispensably to compilation success. x Finding 4: The stepwise ablation reveals that all components are necessary and effective to foster the migration performance of ArkTrans.
4.4
RQ4: Generability Across LLMs
Table 5 summarizes the experimental results of ArkTrans integrated with various LLMs. To ensure a fair comparison, all backbone models were evaluated using identical hyper-parameters as mentioned in Section 3.5. ArkTrans with diverse LLMs. As can be seen, ArkTrans achieves a significant performance leap across all evaluated backbones. Notably, regardless of any LLM, using the direct prompting method yields zero scores across all seven evaluation metrics. This total failure underscores the syntax gap that LLMs cannot bridge through their inherent knowledge alone. In contrast, ArkTrans enables every LLM to produce syntactically correct and visually consistent ArkUI code. To be specific, ArkTrans improves the KJC/SwiftUI-to-ArkUI translation on CSR to 44.00%–76.33%, CH to 25.21%–45.41%, CLIP to 38.53%–66.42%, Pos to 23.75%–42.55%, Size to 23.88%–44.10%, Color to 22.70%–41.38%, and Text to 39.68%– 68.53% on average. This suggests the model-agnostic advantage of ArkTrans with the help of ArkUI skeleton for guiding LLMs in programming on unfamiliar ArkUI code and post-fixing to alleviate the chaos of remaining syntactic errors.
Kunwu Zheng, Pengyu Xue, Zhen Yang, Xiran Lyu, Peishi Lai, Mengying Zhao, Yutian Tang, Huizhi Zhang, Xianhang Li, Linhao Wu, and Chengyi Wang
x Finding 5: ArkTrans generalizes effectively across SOTA LLMs of different architectures.
Comparison between translation directions. Apparently, SwiftUI-to-ArkUI translation consistently brings much more difficulties than KJC-to-ArkUI ones for all LLMs under test, showing the same trend as RQ2. Nevertheless, when horizontally comparing the performance of ArkTrans among different LLMs for each translation direction, we find that DeepSeek-V3.2 achieves the greatest improvement in SwiftUI-to-ArkUI translation. This is because, although DeepSeek-V3.2 is prone to API hallucinations in the more challenging SwiftUI-to-ArkUI task, its errors follow highly regular patterns that are more easily rectified by ArkTrans’s post-fixing engine. In contrast, GPT-5.2 excels in KJC-to-ArkUI migration due to its superior logical consistency and grasp of component hierarchies, which minimizes structural violations. x Finding 6: Although SwiftUI-to-ArkUI translation brings more difficulties among all LLMs under test, DeepSeek-V3.2 excels GPT-5.2 in this translation direction, which only ranks almost the last position in KJC-to-ArkUI translation.
Table 5: Generalizability of ArkTrans across various LLMs Visual Fidelity (G) Sou. PL
KJC
SwiftUI
5
Model
Method
Visual Fidelity (L)
CSR (%) CH
CLIP
Pos
Size
Color
Text
DeepSeek-V3.2
Direct Prompting ArkTrans
0.00 65.33
0.00 33.71
0.00 56.30
0.00 36.10
0.00 39.40
0.00 35.80
0.00 57.40
GLM-5
Direct Prompting ArkTrans
0.00 80.00
0.00 52.68
0.00 70.57
0.00 48.60
0.00 47.00
0.00 46.00
0.00 72.00
Kimi-K2-Turbo
Direct Prompting ArkTrans
0.00 69.33
0.00 39.23
0.00 59.90
0.00 38.50
0.00 41.60
0.00 37.40
0.00 62.20
GPT-5.2
Direct Prompting ArkTrans
0.00 90.67
0.00 56.01
0.00 78.89
0.00 47.00
0.00 48.40
0.00 46.30
0.00 82.50
DeepSeek-V3.2
Direct Prompting ArkTrans
0.00 54.67
0.00 28.77
0.00 47.66
0.00 29.90
0.00 32.60
0.00 29.90
0.00 49.20
GLM-5
Direct Prompting ArkTrans
0.00 44.00
0.00 28.51
0.00 39.87
0.00 27.60
0.00 25.50
0.00 25.40
0.00 40.70
Kimi-K2-Turbo
Direct Prompting ArkTrans
0.00 24.00
0.00 13.33
0.00 21.00
0.00 14.20
0.00 12.90
0.00 12.30
0.00 21.40
GPT-5.2
Direct Prompting ArkTrans
0.00 53.33
0.00 30.23
0.00 45.59
0.00 23.30
0.00 24.50
0.00 23.20
0.00 47.70
Threats to Validity
External Validity concerns the generality of ArkTrans. First, regarding PL generality, while our evaluation is limited to KJC and SwiftUI, we specifically selected these as they represent the two most widely adopted PLs for Android and iOS platforms. By addressing these dominant platforms, our study covers the most prevalent mobile UI scenarios in the industry today. Second, to address the threat of model-dependency, we demonstrate in RQ3 that ArkTrans is model-agnostic, maintaining consistent performance gains across four diverse SOTA LLM architectures. Another threat is the dataset scope. Although we selected representative UI layouts, they may not cover all industrial-scale edge cases. Nonetheless, the diversity of our benchmarks, shown in Table 1, provides meaningful insights into the robustness of ArkTrans. Internal Validity relates to potential biases in experimental design. To mitigate implementation errors in our post-fixing module, we conducted rigorous manual verification of the transformation rules. Regarding data leakage, the risk is minimal as our evaluation benchmark is self-constructed and is not included in the pre-training data of the evaluated LLMs. Additionally, [48] revealed
that functional equivalent code files of different PLs are normally unpaired in LLMs’ pre-training, thus the code translation task is not significantly affected by data leakage. Finally, we have released our complete replication package to promote transparency and reproducibility. Construct Validity concerns the evaluation quality. We adopt a multi-dimensional protocol in assessment: (1) Code executability is measured via Compilation Success Rate (CSR); (2) Visual fidelity is captured through both global metrics (CLIP and CH) and Local Metrics (Position, Size, Color, and Text) of various dimensions. As such, The above holistic evaluation system ensures our measurements align with the practical requirements of functional and aesthetic UI porting.
6 Related Work 6.1 LLMs for Code Translation Recent work has explored the use of large language models for automated code generation and translation [34, 27, 5, 50]. Early studies mainly focused on fine-grained translation tasks, where individual functions or methods are translated independently. For example, benchmarks such as MultiPL-E [3] provide multilingual datasets for evaluating function-level code generation and translation. Pan et al. [31] further conducted an empirical study of bugs introduced by LLMs during code translation, highlighting the reliability challenges of LLM-based translation systems. Other studies have attempted to improve the performance of function-level code translation through various strategies, such as leveraging test cases for validation (UniTrans [47]), applying multi-agent frameworks to iteratively repair translations (TRANSAGENT [42]), developing specialized translation models (SteloCoder [30]), incorporating external knowledge sources such as API information [41], or introducing general correction modules to refine translated code (Rectifier [49]). However, function-level translation tools often struggle to capture dependencies across functions and modules, which makes them difficult to apply to real-world software systems. To address this limitation, recent work has explored coarse-grained translation that operates on larger program units, such as classes or entire repositories. For instance, ClassEval-T [45] evaluates LLMs on class-level code translation tasks, while TransLibEval [46] studies translation involving third-party library dependencies. More recent approaches further consider repository-level translation and validation across multiple files and modules, including methods that leverage program skeletons to capture the high-level structure of programs during translation [16, 20, 40]. Inspired by these studies, our work adopts a skeleton-based representation to model the structural organization of UI components during translation. While LLM-based code translation has shown promising results, most existing studies focus on backend logics In contrast, automated translation across modern declarative UI frameworks remains relatively underexplored. In this work, we address this gap by investigating automated translation from SwiftUI/KJC-based UI frameworks to ArkUI and introducing a parallel dataset to support this task.
Porting Declarative UI to HarmonyOS: A Heuristic-guided LLM Approach
6.2
UI Coding Automation
Prior work on UI automation has predominantly focused on designto-code generation [13, 39, 43, 44], where UI designs or screenshots are translated into executable code. Early research [4] often bootstrap implementation by translating UI design images into GUI skeletons, while more recent studies [36, 53] extend this line to declarative UI generation using multimodal models and structured intermediate representations. However, compared to the extensive research on design-to-code, code-to-code UI migration across platforms remains understudied. Existing efforts like GUIMigrator [9] and UITrans [12] either do not target the HarmonyOS ecosystem or still focus on migrating from outdated imperative layouts (e.g., Android XML) rather than modern declarative frameworks. To our knowledge, ArkTrans is the first to address UI migration as a direct code translation problem between modern declarative frameworks, specifically porting KJC and SwiftUI to ArkUI.
7
[14] [15] [16]
[17] [18] [19] [20] [21]
[22]
Conclusion
This work introduces ArkTrans, the first heuristic-guided LLM approach for declarative UI migration, and establishes a dedicated parallel benchmark of 100 file-level samples. Experiments with SOTA LLMs demonstrate that ArkTrans significantly outperforms direct and one-shot baselines, achieving a CSR of up to 90.67% where baselines failed to produce any compilable code. This highlights the necessity of structured skeleton awareness in UI translation. Furthermore, our component analysis and cross-model validation provide practical insights for designing robust UI-aware code translators to enrich the HarmonyOS ecosystem. Future work will incorporate refined compiler feedback and expand the benchmark to include a broader range of UI components. Data Availability: We open-sourced the data and reproduction package at [1].
[23] [24] [25] [26] [27] [28] [29] [30] [31]
References [1] [2] [3] [4]
[5] [6] [7] [8] [9] [10] [11] [12] [13]
Anonymous. [n. d.] Data for arktrans. [Papered. ] (). John Canny. 2009. A computational approach to edge detection. IEEE Transactions on pattern analysis and machine intelligence, 6, 679–698. Federico Cassano et al. 2022. Multipl-e: a scalable and extensible approach to benchmarking neural code generation. arXiv preprint arXiv:2208.08227. Chunyang Chen, Ting Su, Guozhu Meng, Zhenchang Xing, and Yang Liu. 2018. From ui design image to gui skeleton: a neural machine translator to bootstrap mobile gui implementation. In Proceedings of the 40th International Conference on Software Engineering, 665–676. Mark Chen et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. Deepseek. 2025. Deepseek - Official API Interface. (2025). Retrieved November 13, 2025 from https://www.deepseek.com/zh. Michele Fadda. 2024. An iOS Developer’s Guide to SwiftUI: Design and build beautiful apps quickly and easily with minimum code. Packt Publishing Ltd. Kevin Furjan, Filip Kisić, and Daniel Bele. 2025. Declarative ios programming and architectural patterns. In Security Issues in Communication Devices, Networks and Computing Models. CRC Press, 18–27. Yi Gao, Xing Hu, Tongtong Xu, Xin Xia, and Xiaohu Yang. 2024. A rule-based approach for ui migration from android to ios. arXiv preprint arXiv:2409.16656. 2026. Gitee. [Online; accessed 2026-03-20]. (Mar. 2026). https://gitee.com/. 2026. Github. [Online; accessed 2026-03-20]. (Mar. 2026). https://github.com/. Lina Gong, Chen Wang, Di Cui, Yujun Huang, and Mingqiang Wei. 2025. Uitrans: seamless ui translation from android to harmonyos. In Proceedings of the 16th International Conference on Internetware, 142–146. Yi Gui, Zhen Li, Yao Wan, Yemin Shi, Hongyu Zhang, Yi Su, Shaoling Dong, Xing Zhou, and Wenbin Jiang. 2024. Vision2ui: a real-world dataset with layout for code generation from ui designs. arXiv preprint arXiv:2404.06369, 5.
[32]
[33] [34] [35] [36]
[37] [38] [39] [40] [41]
Robert M Haralick, Stanley R Sternberg, and Xinhua Zhuang. 1987. Image analysis using mathematical morphology. IEEE transactions on pattern analysis and machine intelligence, 4, 532–550. Paul Heckbert. 1982. Color image quantization for frame buffer display. ACM Siggraph Computer Graphics, 16, 3, 297–307. Ali Reza Ibrahimzada, Kaiyao Ke, Mrigank Pawagi, Muhammad Salman Abid, Rangeet Pan, Saurabh Sinha, and Reyhaneh Jabbarvand. 2025. Alphatrans: a neuro-symbolic compositional approach for repository-level code translation and validation. Proceedings of the ACM on Software Engineering, 2, FSE, 2454– 2476. FM Izrailev and A Castaneda-Mendoza. 2006. Return probability: exponential versus gaussian decay. Physics Letters A, 350, 5-6, 355–362. Wallace Jackson. 2014. Introduction to xml: defining an android app, its design, and constants. In Android Apps for Absolute Beginners. Springer, 101–130. Dmitry Jemerov and Svetlana Isakova. 2017. Kotlin in action. Simon and Schuster. Kaiyao Ke, Ali Reza Ibrahimzada, Rangeet Pan, Saurabh Sinha, and Reyhaneh Jabbarvand. 2025. Advancing automated in-isolation validation in repositorylevel code translation. arXiv preprint arXiv:2511.21878. Rakpong Kittinaradorn, Chu-Cheng Lin, Munchurl Kim, and Yi-Chao Chen. 2020. EasyOCR: ready-to-use OCR with 80+ supported languages and all popular writing scripts. https://github.com/JaidedAI/EasyOCR. Accessed: 2024-0520. (2020). Donald B Malkoff. 1997. Evaluation of the jonker-volgenant-castanon (jvc) assignment algorithm for track association. In Signal Processing, Sensor Fusion, and Target Recognition VI. Vol. 3068. SPIE, 228–239. S Marchenko. 2023. Jetpack compose: new approaches to android ui development. Publishing House “Baltija Publishing”. Jiri Matas, Ondrej Chum, Martin Urban, and Tomás Pajdla. 2004. Robust widebaseline stereo from maximally stable extremal regions. Image and vision computing, 22, 10, 761–767. Matthew Mathias, John Gallagher, and Mikey Ward. 2020. Swift Programming: The Big Nerd Ranch Guide. Pearson Technology Group. Moonshot AI. 2024. Moonshot ai: scaling to the next dimension. https://www .moonshot.cn/. Accessed: 2024-05-22. (2024). Noor Nashid, Mifta Sintaha, and Ali Mesbah. 2023. Retrieval-based prompt selection for code-related few-shot learning. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2450–2462. Alexander Neubeck and Luc Van Gool. 2006. Efficient non-maximum suppression. In 18th international conference on pattern recognition (ICPR’06). Vol. 3. Ieee, 850–855. OpenAI. 2025. (2025). Retrieved November 13, 2025 from https://openai.com/. Jialing Pan, Adrien Sadé, Jin Kim, Eric Soriano, Guillem Sole, and Sylvain Flamant. 2023. Stelocoder: a decoder-only llm for multi-language to python code translation. arXiv preprint arXiv:2310.15539. Rangeet Pan et al. 2024. Lost in translation: a study of bugs introduced by large language models while translating code. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 1–13. Iqra Qasim, Farooque Azam, Muhammad Waseem Anwar, Hanny Tufail, and Tehreem Qasim. 2018. Mobile user interface development techniques: a systematic literature review. In 2018 IEEE 9th Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON). IEEE, 1029–1034. Alec Radford et al. 2021. Learning transferable visual models from natural language supervision. In International conference on machine learning. PmLR, 8748–8763. Baptiste Roziere, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised translation of programming languages. Advances in neural information processing systems, 33, 20601–20611. Erica Sadun. 2013. iOS Drawing: Practical UIKit Solutions. Addison-Wesley. Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu, and Diyi Yang. 2025. Design2code: benchmarking multimodal code generation for automated front-end engineering. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), 3956–3974. Th Sorenson. 1948. A method of establishing groups of equal amplitude in plant sociology based on similarity of species content and its application to analyses of the vegetation on danish commons. Biol Skar, 5, 1. Shamik Sural, Gang Qian, and Sakti Pramanik. 2002. Segmentation and histogram generation using the hsv color space for image retrieval. In Proceedings. international conference on image processing. Vol. 2. IEEE, II–II. Yuxuan Wan, Chaozheng Wang, Yi Dong, Wenxuan Wang, Shuqing Li, Yintong Huo, and Michael R Lyu. 2024. Automatically generating ui code from screenshot: a divide-and-conquer-based approach. arXiv preprint arXiv:2406.16386. Bo Wang, Tianyu Li, Ruishi Li, Umang Mathur, and Prateek Saxena. 2025. Program skeletons for automated program translation. Proceedings of the ACM on Programming Languages, 9, PLDI, 920–944. Chaofan Wang, Guanjie Qiu, Xiaodong Gu, and Beijun Shen. 2025. Apirat: integrating multi-source api knowledge for enhanced code translation with
Kunwu Zheng, Pengyu Xue, Zhen Yang, Xiran Lyu, Peishi Lai, Mengying Zhao, Yutian Tang, Huizhi Zhang, Xianhang Li, Linhao Wu, and Chengyi Wang
[42]
[43]
[44] [45] [46]
llms. In 2025 IEEE 49th Annual Computers, Software, and Applications Conference (COMPSAC). IEEE, 1400–1405. Minghao Wu, Jiahao Xu, and Longyue Wang. 2024. Transagents: build your translation company with language agents. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, 131–141. Shuhong Xiao, Yunnong Chen, Jiazhi Li, Liuqing Chen, Lingyun Sun, and Tingting Zhou. 2024. Prototype2code: end-to-end front-end code generation from ui design prototypes. In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. Vol. 88353. American Society of Mechanical Engineers, V02BT02A038. Yong Xu, Lili Bo, Xiaobing Sun, Bin Li, Jing Jiang, and Wei Zhou. 2021. Image2emmet: automatic code generation from web user interface image. Journal of Software: Evolution and Process, 33, 8, e2369. Pengyu Xue et al. 2025. Classeval-t: evaluating large language models in classlevel code translation. Proceedings of the ACM on Software Engineering, 2, ISSTA, 1421–1444. Pengyu Xue et al. 2025. Translibeval: demystify large language models’ capability in third-party library-targeted code translation. arXiv preprint arXiv:2509.12087.
[47] [48] [49] [50] [51] [52]
[53]
Zhen Yang et al. 2024. Exploring and unleashing the power of large language models in automated code translation. Proceedings of the ACM on Software Engineering, 1, FSE, 1585–1608. Zhen Yang et al. 2025. Rethinking the effects of data contamination in code intelligence. arXiv preprint arXiv:2506.02791. Xin Yin, Chao Ni, Tien N Nguyen, Shaohua Wang, and Xiaohu Yang. 2024. Rectifier: code translation with corrector via llms. arXiv preprint arXiv:2407.07472. Wayne Xin Zhao et al. 2023. A survey of large language models. arXiv preprint arXiv:2303.18223, 1, 2, 1–124. Zhipu AI. 2024. Glm-5: zhipu ai’s next-generation large language model (745b parameters). https://glm5.net/. Accessed: 2024-05-22. (2024). Bo Zhou, Jiaqi Shi, Ying Wang, Li Li, Tsz On Li, Hai Yu, and Zhiliang Zhu. 2025. Porting software libraries to openharmony: transitioning from typescript or javascript to arkts. Proceedings of the ACM on Software Engineering, 2, ISSTA, 1445–1466. Ting Zhou, Yanjie Zhao, Xinyi Hou, Xiaoyu Sun, Kai Chen, and Haoyu Wang. 2025. Declarui: bridging design and development with automated declarative ui code generation. Proceedings of the ACM on Software Engineering, 2, FSE, 219–241.
Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009