uni-app x Vapor Mode Renders Twice as Fast as Native UIKit on iOS

Background

uni-app x Vapor Mode is a new version of the cross-platform development framework launched by DCloud in 2026.

The product's defining characteristic is: Faster than native.

Following the release of the uni-app x Vapor Mode for HarmonyOS, the iOS version has also been released as an alpha in version 5.1+ and officially released in version 5.14.

iOS's native performance optimization is an industry benchmark, and achieving performance that surpasses iOS native is extremely difficult. This might seem like a fantasy to many. Therefore, a rigorous and objective benchmark is particularly important.

The goal of this benchmark test is to truthfully present key performance indicators and ensure that developers can reproduce this benchmark themselves and reach similar conclusions.

First, a brief introduction to uni-app x and Vapor Mode:

• uni-app x uses Vue syntax and removes the Virtual DOM in Vapor Mode.
• In Vapor Mode, templates and styles are compiled into machine code or bytecode; script is compiled into JavaScript on iOS.
• uni-app x is based on the native rendering pipeline, can integrate with the native component ecosystem, and occupies less memory.
• Vapor Mode provides a large number of self-developed high-performance components, such as view, text, image, list, rich-text, swiper, slider, picker, etc.

Test Metrics

The core performance metrics of a UI system are: rendering speed and frame rate.

The goal is to pursue faster rendering speeds and fewer dropped frames.

Human perception can be recorded on video, but test metrics must be precisely measurable, requiring an accurate measurement scheme.

Environment Declaration

This Benchmark uses two of the lowest-end iPhone SE2 models currently sold for iOS, released in 2020. Specific information is as follows:

• Device Model: iPhone SE2
• OS Version: iOS 26
• All run in release mode.
• Battery level around 90%, power-saving mode not enabled.
• All devices were restarted before testing and left idle for 2 minutes. All other app processes were killed.

View and Text Rendering Speed Test

View and text are the core foundations of a rendering engine; a large number of components are built upon these two basic components. The rendering speed of these two basic components is the most core performance indicator of a rendering engine.

A reliable way to verify if the creation speed of a view and text is fast enough is to create a large number of view and text components on the same screen and calculate the time consumed.

Test Method

After clicking a button, 2000 views are created on the screen, each view has a background color, and each view contains a text component nested inside.

The 2000 views must be displayed in the same screen area. The views have no set width or height, and the text font is small. The views are divided into 50 rows, with 40 views per row, and each row is wrapped in an outer view.

That is, a total of 4050 elements, including 2050 views and 2000 texts.

A comparison of creation speed is conducted using uni-app x Vapor Mode and Native UIKit.

First, let's look at the screen recording comparison. The left side is Native UIKit, and the right side is uni-app x Vapor Mode.

For high-definition video, please visit Bilibili: uni-app x vs UIKit 4050 element rendering speed comparison video (iOS platform)

The time consumed is displayed at the top of the interface, in ms. Native UIKit took 325.76ms, and uni-app x Vapor Mode took 167ms. Timing explanation:

• The start time is the moment the button's click event is triggered.
• The end time is the moment all rendering commands on the main thread have been sent to the OS rendering process. At this point, the main thread has completed the work required for this rendering and is idle.

This end time is not the time the image is visible to the naked eye. In reality, the rendering process and GPU still need some time to work before the screen displays the image, but this subsequent period cannot be timed programmatically and is around 1 frame. Therefore, this period is ignored in subsequent precise comparisons, and the current end time definition is retained.

The experiment was repeated 5 times. The app process was killed and re-entered each time. The detailed time consumption is as follows:

Native UIKit	uni-app x Vapor Mode iOS
325.76	167
330	157
330	159
330	160
328	160

Average values:

UIKit	uni-app x Vapor Mode
328.75	160.6

The unit for the above data is ms.

Test Conclusion

Conclusion: In the 4050 view and text same-screen rendering test, the rendering speed of uni-app x Vapor Mode is 2 times that of iOS native UIKit.

It should be noted that on iOS 18, the gap between native and uni-app x Vapor Mode is even larger, especially with SwiftUI. Test data on the lower-end iPhone XR, iOS 18 is as follows:

	5-run Average Time (ms)
Native UIKit	339.7 (340.9 339.1 337.7 343.9 336.9)
Native SwiftUI	610.56 (609.6 614.2 613.1 613 602.9)
uni-app x Vapor Mode	185.8 (186 186 185 185 187)

When rendering 4050 elements, the incremental memory usage of uni-app x is also lower, in the order of uni-app x < UIKit < SwiftUI. The related data is extensive and will not be listed in this report. Interested developers can use Xcode to observe it themselves.

Reproduction Project Source Code and Experience Method

For the above two examples, the source code is as follows:

• iOS native source code: https://gitcode.com/dcloud/test4050-ios
• uni-app x source code: https://gitcode.com/dcloud/hello-uni-app-x/blob/alpha/pages/template/4050/4050.uvue

For the native version, you need to compile the original project yourself in Xcode.

uni-app x Vapor Mode can be compiled in HBuilderX version 5.14+. Note that running on a real device is in debug mode and cannot be used for performance testing. You must publish it as a formal package and install it to test performance in release mode.

You can also download the sample app directly without compiling uni-app x:

The hello uni-app x sample app has been listed on the App Store via ABM. Scan the QR code below with an iOS phone and log in with a DCloud account to download:

After installing hello uni-app x, click Templates in the bottom right corner -> view and text performance test at the top.

As a general-purpose engine, uni-app x has not made any custom optimizations for this example, and there are no behaviors such as preloading, pre-measurement, or forcing the use of performance cores that would affect the fairness of the experiment.

Long List Frame Drop Test

The status of the list component in a rendering engine is second only to view and text.

Modern rendering engines all use recycling technology to implement long lists, ensuring that memory does not continuously grow after sustained scrolling of a long list.

Long lists using recycling technology load quickly because only a portion of the data is loaded. However, the difficulty lies in not dropping frames during fast scrolling. When continuously loading data and reusing existing views, if the list is complex, it is difficult to complete rendering within one frame, which causes frame drops or white screens.

Test Method

Design a very complex "deadly long list":

• Load 4000 rows of data, 7.4M JSON.
• Each row has over 40+ elements, including text, images, videos, and custom Vue components.
• Each row has a nesting depth of 10+ layers.
• The list renders a total of 20,000 elements, occupying about 1333 screens on a regular phone.
• The list also contains a large number of complex rendering styles such as shadows, rounded corners, and borders.

In manual experience, users can experience loading speed and smoothness during fast scrolling, but in a rigorous Benchmark, precise comparison data is needed.

First, an FPS component needs to be created to monitor the system's frame callbacks. On an iPhone SE2, a frame callback is triggered every 16.6ms. If the code response time between two frame callbacks exceeds 16.6ms, it means a frame has been dropped.

This FPS component needs to be implemented using the same logic for both the native version and the uni-app x version. See the subsequent Reproduction Project section for source code.

At the same time, the code for the deadly long list also needs to be implemented with the same logic in iOS native and uni-app x. Due to workload reasons, only the SwiftUI version was written for the long list test, not the UIKit version.

Enter the long list on both ends, long-press to select the scroll bar, drag the scroll bar to make the list scroll quickly, scroll to the bottom, load all 4000 rows of data, and then click to return to the top.

The scroll-back speed is the same on both ends. During the process of scrolling back to the top, calculate the frame rate to verify frame drops. Also, make an intuitive visual comparison from the recording.

First, let's look at the screen recording comparison. The left side is uni-app x Vapor Mode, and the right side is Native SwiftUI.

For high-definition video, please visit Bilibili: uni-app x High-Performance Demo - Deadly Long List - iOS Platform

From the visual experience, it can be seen that the native list on the right has a large number of gray blocks during fast scrolling, unable to render images and videos in time. The uni-app x list on the left can render them all in time, with no gray blocks visible. The numbers on the FPS component show the native version largely around 30 or 40, while uni-app x is basically above 50.

The experiment was repeated 5 times, killing the app and re-entering each time, and re-scrolling to the top.

The test data for the 5 runs is as follows:

• SwiftUI:
• • Average FPS during scroll-back: 40.06, Max FPS: 60, Min FPS: 28.1
  • Average FPS during scroll-back: 37, Max FPS: 60, Min FPS: 25
  • Average FPS during scroll-back: 38, Max FPS: 60, Min FPS: 23
  • Average FPS during scroll-back: 37, Max FPS: 60, Min FPS: 27
  • Average FPS during scroll-back: 36, Max FPS: 60, Min FPS: 27
• uni-app-x Vapor Mode:
• • Average FPS during scroll-back: 50, Max FPS: 60, Min FPS: 16.23
  • Average FPS during scroll-back: 54, Max FPS: 60, Min FPS: 19
  • Average FPS during scroll-back: 48, Max FPS: 60, Min FPS: 16
  • Average FPS during scroll-back: 48, Max FPS: 60, Min FPS: 15
  • Average FPS during scroll-back: 48, Max FPS: 60, Min FPS: 21

The 5-run average FPS for SwiftUI is 37.6, with a max FPS of 60 and a min FPS of 23.

The 5-run average FPS for uni-app x Vapor Mode is 49.6, with a max FPS of 60 and a min FPS of 15.

Test Conclusion

Conclusion: In the long list frame rate test, the average frame rate of uni-app x Vapor Mode is 1.32 times that of SwiftUI.

Although the frame rate of uni-app x is not much faster than SwiftUI for long lists, considering the large number of gray blocks that SwiftUI does not render during scrolling, it can be inferred that it uses a method of skipping rendering during fast scrolling to reduce frame drops. Which user experience is better is clear at a glance.

Additionally, the video in the SwiftUI version of the long list did not implement memory of the video playback progress. That is, if video A is played to 5 seconds, scrolled away from, and then scrolled back to display video A, video A will play from the beginning.

But the uni-app x version remembers the playback progress. Besides the functional difference, this difference also needs to be considered in the frame rate comparison. Remembering playback progress itself consumes time, meaning that if uni-app x canceled the playback progress memory, the frame rate could be further improved.

Reproduction Project Source Code and Experience Method

For the above two examples, the source code is as follows:

• iOS SwiftUI version source code: https://gitcode.com/dcloud/iOSDeadlyList-SwiftUI
• uni-app x version source code: https://gitcode.com/dcloud/hello-uni-app-x/blob/alpha/pages/template/long-list-perf/long-list-perf.uvue

For the native version, you need to compile the original project yourself.

uni-app x Vapor Mode can be compiled and run in HBuilderX version 5.14+ (note: publish as a formal package for installation testing, do not use real device run for performance testing).

The hello uni-app x sample app has been listed on the App Store via ABM. Scan the QR code below with an iOS phone:

After installing hello uni-app x, click Templates in the bottom right corner -> Deadly Long List at the top.

As a general-purpose engine, uni-app x has not made any custom optimizations for this example, and there are no behaviors such as preloading, pre-measurement, or forcing binding to performance cores that would affect the experimental results.

Other Components

A rendering engine, besides view, text, and list, also needs more high-performance components.

uni-app x has conducted extreme performance tests for various components, but due to limited effort, test cases for iOS native components have not been developed for performance comparison.

Therefore, the following components have no native comparison data, only data for uni-app x Vapor Mode.

Developers can experience the performance tests of various components in hello uni-app x. Almost every component example provides a separate component performance test.

• rich-text component:

The rich-text component is very important, whether for news, UGC content, or AI-outputted Markdown rich text, including tables and code highlighting. There hasn't been a good solution for these on the App platform in the past. Most developers could only endure problems like slow webview initialization, high memory usage, and white screens during fast scrolling. uni-app x Vapor Mode provides what should be the industry's current best rich-text component. The following test loads a 50,000-character long article with a single rich-text component, including 59 illustrations. You can see: 1. No waiting to enter the page. 2. Fast scrolling up and down without frame drops or white screens; everything is rendered instantly. 3. The speed of loading images over the network for the first time is affected by network speed. Upon re-entry, local cache is used, making it faster.

For high-definition video, please visit Bilibili: uni-app x High-Performance Demo - richtext component - iOS Platform

• swiper component:

Clicking an image in the aforementioned 50,000-character long article opens an image preview interface, which is implemented using the swiper component. You can see that 59 images are presented in the swiper without waiting, and switching images left and right has no delay. Many single-metric improvements can be achieved by sacrificing other metrics. For example, lazy loading at startup makes startup fast but subsequent switching slow. Achieving both fast startup and fast switching without preloading is truly good performance.

• picker component:

Load 4000 records of province/city/district data. The component pops up without waiting, with no preloading; the data is loaded and rendered only when the picker is clicked.

For high-definition video, please visit Bilibili: uni-app x High-Performance Demo - picker component - iOS Platform

• slider component:

Enter a page with 100 sliders, entering instantly. Dragging the 100 sliders is silky smooth. There is absolutely no worry about communication blocking between the logic layer and the rendering layer.

For high-definition video, please visit Bilibili: uni-app x High-Performance Demo - slider component - iOS Platform

Note: The screen recording frame rate can only be 60Hz; actual use on a high refresh rate screen phone is 120Hz. Same below.

• loading component:

Rotate 100 loadings on the screen simultaneously, while the timer text updates every millisecond, with absolutely no frame drops under high drawing pressure.

For high-definition video, please visit Bilibili: uni-app x High-Performance Demo - loading component - iOS Platform

• canvas component:

Move hundreds of small balls simultaneously on the screen without dropping frames.

For high-definition video, please visit Bilibili: uni-app x High-Performance Demo - canvas - iOS Platform

• Numerous form components

All have 100 or 200 creation speed test monitors. The hello uni-app x template also provides performance test examples for calendars, vertical swipe videos, swipe-to-delete long lists, and AI chat streaming typewriter effects.

For high-definition video, please visit Bilibili:

• uni-app x High-Performance Calendar Demo (iOS Platform)
• uni-app x High-Performance Demo - Swipe to Delete - iOS Platform
• uni-app x Streaming Typewriter Performance Demo (iOS Platform)

In the AI era, many apps need to embed an open-source AI chat library that can parse Markdown in a streaming manner without dropping frames during the parsing process. For this purpose, DCloud has launched the open-source uni-ai x, see https://ext.dcloud.net.cn/plugin?id=23902

No user likes waiting, and no user likes stuttering or dropped frames.

Since the release of the iPhone in 2007, mobile phone users have had to wait 300ms for every page transition every day for decades. uni-app x will support significantly shortening this time. hello uni-app x's Vapor Mode has already defaulted to 150ms, and this 150ms is mostly reserved for the network.

If developers use emerging network technologies like h3 and optimize server speed, the waiting time can be shortened even further.

FAQ

Is the App platform of uni-app x self-rendering or native rendering?

It is native rendering. To be precise, it makes almost all components itself on the native rendering pipeline.

If self-rendering were used, the coexistence of two rendering pipelines would consume additional hardware resources. Initialization would be slow and memory usage high.

Moreover, the native ecosystem has developed over many years, with many third-party component SDKs, such as maps, live streaming, and ads. Self-rendering solutions have many problems when integrating with the native ecosystem. The issues of scroll synchronization and resource consumption when two rendering pipelines merge on the same page mean this route is not the best solution.

From a macro perspective, optimizing within the native rendering pipeline, providing faster core components, and being compatible with all native components is more meaningful for the industry than establishing a separate component ecosystem.

Why is uni-app x's Vapor Mode faster than native rendering if both are native rendering?

This involves thousands of engineering optimizations. Here are a few examples:

1. Android's Compose UI is also based on the native rendering pipeline, but it does not use Android's built-in View or TextView; instead, it implements its own component system.

   This path is viable, but Compose UI has not become a good benchmark; its actual rendering speed is slower than the View system. (In the aforementioned 4050 example comparison, there are test cases for native View and Compose UI, see details)

   uni-app x Vapor Mode also barely uses the system's built-in components, whether it's TextView, RecyclerView, ViewPager... basically none are used. The newly developed components achieve higher performance.

2. The code in Vue's template and style is directly compiled into highly optimized machine code/bytecode.

   The current side effect is that compilation speed has become slower. DCloud will improve the compiler later to further enhance compilation speed.

Flattening was found in the uni-app x example. If not flattened, would the rendering speed in uni-app x Vapor Mode still be faster than native?

Without flattening, uni-app x Vapor Mode is still faster than UIKit and SwiftUI. Interested developers can modify the 4050.uvue code to test it themselves.

Is K/N driving the C-layer rendering also faster than SwiftUI or uni-app x Vapor Mode?

Compose Multiplatform uses self-rendering on iOS, which has native UI ecosystem integration issues and poor performance.

The performance ranking is uni-app x Vapor Mode > UIKit > SwiftUI > Compose Multiplatform.

In the AI era, is cross-platform still significant?

Improving production efficiency is an unchanging trend in social development. Both AI and cross-platform are important means to promote production efficiency.

However, if AI is used to generate multi-platform code, AI is not a stable public abstraction. If you practice it, you will find that except for the first sentence sent to AI, which can be reused across platforms, every subsequent problem needs to be handled per platform. It is difficult to make a commercial-grade application without professional platform knowledge.

Improving performance is an unchanging trend in user experience development. Page switching reduced from 300ms waiting to 150ms, and silky smooth interaction with any operation, are important reasons why users choose one app or abandon another. AI + native UI system cannot achieve higher performance than uni-app x.

Additionally, welcome to follow uni-agent, which understands uni-app series products better than any AI coding tool and can help developers better use AI to generate code for uni-app x, uniCloud, and other products.

AI generates React code by default. What is the impact on Vue?

Since the market share of React in the US development market is higher than Vue, AI defaults to using React when no frontend framework is specified. But if one thinks that AI-generated React code is better than Vue, that's the opposite.

1. In fact, Vue's more standardized and constrained writing style leads to fewer AI hallucinations, while the flexible React makes it easier for AI to make mistakes.
2. React has an ecosystem advantage overseas, but the domestic multi-end situation is more complex than abroad, and there are actually more cross-end Vue libraries domestically.
3. On the web platform, the performance and package size of Vue Vapor Mode are ahead of React. With the maturity of Vue 3.6, the industry may usher in a watershed moment.

Vue 3.6 Vapor Mode is still in beta on the web platform. Can it be used commercially on App?

Currently, the official Vue Vapor Mode on the web platform needs to focus on the stability of features like SSR server rendering, which are not used on the App platform. The Vue part of the App platform's Vapor Mode has already passed all relevant test cases independently.

Moreover, uni-app x's Vapor Mode does not just use Vue's Virtual-DOM-free technology. Being Virtual-DOM-free can only get closer to native, not surpass it. The core of surpassing native is uni-app x's new rendering engine and various new C-based component libraries. Just to reduce concepts and conditional compilation, this new rendering engine has not been given an independent external name.

When will uni-app x Vapor Mode be released for Android? Is it also faster than native?

The Android version of uni-app x Vapor Mode is already in a group testing state. It can be downloaded by joining the uni-app x IM group. It is expected to be officially released to the public in a few days.

Whether on iOS or Android, it is 2~3 times faster than native, and both are based on the native rendering pipeline.

The following preview comparison test cases have been made public:

• The 4050 same-screen creation example APK for uni-app x Vapor Mode on the Android platform: https://gitcode.com/dcloud/test4050-uni-app-x-vapor, install the APK to experience it.
• Source code for native View and Compose UI on the Android platform: https://gitcode.com/dcloud/test4050-android

The comparison data for the above examples on a Huawei Mate30 (Android version) is as follows:

	5-run Cold Start Average Time (unit: ms)
Native View	436
Native Compose UI	673.2
Native Compose UI AOT	544.2
uni-app x Vapor Mode	224

A similar, comprehensive performance evaluation report will be released for the Android version later.

Being both cross-platform and having higher performance than native was once considered a fantasy.

DCloud has always treated this fantasy as a dream and continues to strive for it. uni-app x was launched in 2023, and Vapor Mode in 2026. Years of unremitting pursuit of this dream have turned what others saw as fantasy into reality.

Keep moving forward!