Company Introduction
Kuaishou is China’s first short video platform. Our company’s core mission to “Embrace All Lifestyles”.
To provide users with a professional and easy-to-use video editor tool, our company also has been developing a mobile app called Kuaiying over the last few years. According to a survey about the popularity of video editor software in China, Kuaiying is among the top 3 this year. Our iOS app is a top 10 Photo&Video app on the App Store.
Why did you pursue a cross-platform development strategy?
Initially, Android team and iOS team seperately developed the app via Kotlin and Objective-C.
As the complexity of the project increased and the business grew, we encountered a bottleneck problem which the inconsistencies in core data structures and business logic in iOS and Android platform would significantly degrade the user experience of modifying parts of the template created by our video editor. To be specific, iOS customers could not use the template made from our Android app.
In addition, the logic of editor functions is usually complex in Kuaiying App. The traditional native app development approach brought about some key issues:
● The nonuniform user experience on some features due to the inadequate communication between Android and iOS developers
● The high cost of developing new features and applying new technology.
Therefore, we had to unify the shared data structures and business logic. We began to explore a cross-platform way to refactor the shared parts in our app.
Why did you choose Kotlin Multiplatform Mobile?
Our team investigated a handful of various cross-platform options, each with its share of strengths and weaknesses. We carefully compared C++ with Kotlin Multiplatform and weighed their benefits and shortcomings. Ultimately, we thought that Kotlin Multiplatform is more suitable for our team than C++.
There were a wide-range of reasons for settling on Kotlin Multiplatform. Some of the most compelling include:
● In the short term, adopting Kotlin Multiplatform could take less time and have a lower risk than C++. Since we had already written code about part of shared business logic via Kotlin on Android, which had been validated online for a long time.
● In the long term, Kotlin is more productive for our team than C++. Given its ubiquity in the Android world and its similarity to Swift, we’ve been able to avoid a steep learning curve or a fragmented developer experience.
How did Kotlin Multiplatform Mobile affect your app?
Kotlin Multiplatform Mobile, or KMM for short, was applied on significantly important modules includes the core business logic of video editor in Kuaiying. It has been two years since we sat down to use KMM. Some of the key influences we wanted to share were:
Development Efficiency
The most obvious and important benefit is that the business logic for both iOS and Android development has been truly unified. For a video editor, the majority of functions and abilities are extremely complex, which need a large amount of time to design and development. There is no saying that the implementation on iOS is totally the same as on Android with the traditional workflow. Sincerely, the integration of KMM technology has significantly improved productivity and reduced the cost of maintaining it and developing new features.
However, they also got pains decreased efficiency when interacted with Kotlin/Native.
● When the Kotlin code builds failed in Xcode, it is definitely difficult to figure out a cause. We need to look for issues based on the line number and file name about the error Xcode showed. To avoid this kind of troubles, we recommend that Android developers write the shared code via Kotlin and verified it successfully. Then iOS developers only need to update submodule and apply this code.
● When we set breakpoints on Kotlin code in debugging mode, can not find the values of variables in Xcode.
Stability online
Satisfactorily, the functions and user experience in our video editor are more consistent and stable than before.
On the other hand, it also brings other issues to be solved need. It is arduous to classify online crash by reasons and understand the stack tree of crash from Kotlin on the iOS platform.
Performance
Based on the idea “shared business, native UI” that Kotlin Multiplatform promoted, KMM simultaneously ensure speed and quality of native forms.
Nevertheless, we found a laggy when editing a complicated draft. That is because calling from Objective-C to Kotlin code takes longer than calling from Objective-C to Objective-C code. For setString() API, calling Kotlin code is 100x slower than call Objective-C code. But this problem is common for every cross-platform solution.
What did you try to overcome above-mentioned difficulties
Our iOS team made a big effort to deal with some troubles in debug mode. The major outcomes include:
Enable to print the details of all SharedXX objects via po <expr> on Xcode.
po <expr> is an usual way to view details of some variables in Xcode. But it did not work for some SharedXX objects, which converted from Kotlin code.
To figure out the reason print failed, we analyzed how po works on Xcode at First. From the description of po command, we knew that it is calling the description API. Then, we explored the differences between SharedSysState and SharedProtoVideoBeautyModel and found that SharedSysState is the data class, while SharedProtoVideoBeautyModel is normal class. Data Class inherited from Any and overrided toString() API, which allows po to print values of data class. We naturally thought that it may be a solution to override the toString() function in SharedBase class before building. As a result, we can see the properties of SharedVideoBeautyParam object.
Fixed two issues of fastKotlinDebug plugin forked xcode-plugin：
○xcode will be laggy if the debug area was opened when breaking on Kotlin code
■ After several failed attempts, we found the script loaded has a few problems. it will not stop response after switching to the konan_lldb_fast.py from konan_lldb.py.
○xcode cannot display the value of inner properties for objects when entering breakpoints on Kotlin code
■ The principle reason for this reason is the different of Python version between on the plugin and on my computer. int and long in Python2 are int in Python 3, so I fixed the problem by changing the Python script.
Now we can open the debug area on Xcode, and for primitive data and strings we can see the results directly. For complex objects, we can expand them to see the internal properties. For large objects like editorBridge, it takes a relatively long time to expand them, about 3 or 4 seconds.
Of course, there are also some unresolved issues in using KMM. For instance, how to analyze stack tree of Kotlin crash as well as how to improve the speed of response when debugging step by step. We hope that most of them will soon be solved, as the technology is maturing and growing fast.
Contacts
JUN XIANG,
iOS Development Engineer — xiangjun@kuaishou.com
Note: The intellectual property rights of this work belong to Kuaishou
