I have noticed that many of my friends are curious about how I use Mac to develop Windows software, as well as what technology stack is commonly used to implement Windows software nowadays. I happen to have some free time to chat with everyone about my thoughts on technology choices for multi client applications and some of my ideas. The following is the first article, introducing various desktop and mobile development technologies and their corresponding considerations. Those who have worked on front-end clients should know that in recent years, the development of front-end clients has generally followed these three paths. The first and most simple and convenient method is to directly write web code and plug it into the browser to run. This includes the early PhoneGap and Cordova, which stuffed web pages into a native shell and provided some bridge capabilities for JavaScript to call some native capabilities, such as calling up mobile cameras and other web hard to do things. The second is cross end development, that is, many years ago, people often heard about one code with multiple ends. At that time, the mobile terminal had such technologies as React Native and Weex. At that time, it was mainly to solve the problem of poor Web performance. One piece of code was packaged to produce iOS and Android at the same time. Here, there was also a very big reason for domestic major manufacturers to use cross end technology, which was dynamic and hot update. The local point was that new pages could be issued directly without store review, which was also an important reason why cross ends were particularly popular at that time when the mobile Internet was developing at a high speed. The desktop version that everyone is familiar with is Electron. Nowadays, many AI desktop versions, VS Code, and Slack are made with this, at the cost of each application coming with Chromium and Node.js, an installation package of over 100 MB, and a significant amount of memory. But the advantage is that under the unified Chromium rendering engine, it can maintain consistent display across multiple platforms, and the code written inside is very easy to write. Many desktop shortcuts will use this technology in the future. More interesting solutions have gradually emerged from cross platform development, similar to Flutter's own implementation of a rendering engine. In the early days, it relied on Skia, but now it has switched to its self-developed Impeller rendering engine to ensure consistency across multiple platforms and balance performance efficiency. This includes the veteran Qt on the desktop, which draws its own interface like Flutter. In the past two years, Tauri written in Rust and Wails written in Go have also appeared on desktop cross platforms. The difference between them and Electron is that they do not include Chromium, but use the system's built-in WebView, which has a much smaller package size. However, the overall development concept and corresponding implementation language are still based on Web to bridge interactions. However, due to the different platforms of the system's WebView, Windows has it, Mac has WKWebView, and Linux has WebKitGTK, so the consistency of multi terminal display is not as good as Electron, and compatibility code still needs to be written. So in this case, even if Electron has a large memory footprint, it will still be chosen more. The third type is native development, which is also a way that many people find difficult to develop before AI. Especially before the use of Objective C in the Apple series, Java in the Android series, and C in the Windows series, which I think require a lot of time for academic classes to learn, read books, and manually code. To do well, it requires a lot of time to study the corresponding underlying principles of the system, which can facilitate the writing of code with better and more stable performance than ordinary R&D. In my opinion, this is a technology that requires a large initial investment and is enjoyed by users in the later stage. When I worked for more than 2 years in 2017, one of the main reasons for my career development was that I spent half a year learning Objective C and iOS Research and development allowed me to advance my essential front-end work towards cross end direction, which happened to solve some difficult problems that cannot be solved by the combination of these two professions. It was also a very happy and interesting time for me to work as a front-line developer at that time. As Swift+SwiftUI, Kotlin+Jetpack Compose, and C+WinUI 3 gradually mature, the writing style of these native languages will gradually align with high-level languages and become easier to write. Declarative code will be shorter and easier to read. However, in China, the widespread use of React Native, Flutter, and Electron has completely overshadowed it, resulting in a shortage of developers and the development of the ecosystem relying entirely on official promotion. This has led to a rapid rise in popularity, but it is also a major reason why people generally feel that Kaka has been used for a long time. Moreover, if they want to migrate to native, if the previous architecture implementation is not good, they are likely to have to rewrite it and cannot reuse it at all. If the implementation is good, for example, if you have already extracted the business logic, solutions like Kotlin Multiplatform share the business logic and write each interface in its own native form can be considered as the fourth path, which is also a trend in recent years. At this point, everyone should have a general understanding that there is also an impossible triangle here, which is R&D efficiency, experience, and performance. Choosing Web is more efficient than performance, choosing native is more performance than experience, and choosing cross end is just taking the middle of these three. If done well, it is easy to take advantage of all, and if done poorly, it is easy to not have one side take advantage of the situation. So, in the case where AI coding is no longer a problem, what technology should we choose? Many times it also depends on your scenario, for example, if you are browsing, clicking buttons, or reading in a web scene, it is highly recommended to use web technology directly; If you need to access the underlying capabilities of the system, or if you need to operate more smoothly and distribute, and if it is already an application scenario, I highly recommend using native technology to achieve it. This way, you can enjoy the numerous optimizations provided by the official system, as well as the most native interaction effects and the lowest memory usage. In addition, AI has greatly reduced the cost of writing two native codes, and the efficiency of the triangle has been compensated for. However, debugging and validation on both platforms have become new costs, which is exactly what people need to focus on. Of course, if the selection of technology is not so important, the workload is very large, and the business effect is far greater than the selection of technology experience, choosing cross end technology is also possible. This way, the iteration and release are also fast, and your users can receive your latest feature updates in the first time. However, in the end, technology serves the business, and ultimately needs to move towards solving problems. For example, when it comes to grabbing concert tickets, people don't pay attention to how your client is stuck, they only focus on whether you can get tickets with me. Even if you do it very smoothly, if you can't get tickets, you will be criticized very badly. Choosing a good technology stack here has become a icing on the cake job. Ultimately, we still need to prioritize solving the most real needs of users, and then think about how to make the user experience better. The next step is to consider whether I need to use native technology to achieve it. I have written so much at once, and I will continue to chat tomorrow. I want to share with everyone how I set up an environment for developing Windows native software on Mac, as well as some pitfalls and best practices I have encountered in Windows/Mac multi terminal development. Haha, welcome to exchange. Let's talk about the technology stack choices in my own mind without asking AI, it's quite interesting.