From iOS to Windows: A Developer’s Journey into Desktop Engineering

Preface

Since graduating, I have worked as an iOS engineer, occasionally touching front‑end and mini‑program development. After leading a multi‑platform DingTalk project, I began exploring desktop development and now have solid Windows development skills.

Supplementary Note

The article reflects personal opinions; my background may affect objectivity. I joined Alibaba after graduation, worked in the DingTalk iOS team, and later led DingTalk’s Flutter foundation (project Dutter). Through Dutter I entered desktop development and accumulated the experience presented here.

My discussion of “desktop development” mainly refers to DingTalk’s desktop client, which has unique tooling and constraints.

Desktop development generally includes Windows, macOS, and Linux, but Windows is the most complex, so the article focuses on Windows.

Desktop Development

This section gives a brief overview of my understanding of desktop development and my impressions after getting hands‑on.

Research Status

Since the 1990s, traditional C/S desktop development has declined in favor of web B/S architectures. Mobile app development surged later, but desktop remains a niche with few specialists, especially in large companies where mobile outweighs desktop in ROI.

Nevertheless, as traffic growth plateaus, high‑value users become the focus, and products like DingTalk need high‑quality native desktop clients (Windows, macOS, Linux) rather than pure web solutions.

Overall Feeling

Learning Windows desktop development feels like learning to drive a manual‑transmission car: you must coordinate many controls rather than just press the accelerator.

Apple products emphasize polished interaction, hiding details and placing frequently used functions intuitively.

Microsoft products offer rich functionality but often present a cluttered UI where many buttons are rarely used.

When moving from Xcode to Windows, we rely on Visual Studio for coding, Spy++ for UI debugging, WinDbg for crash analysis, ProcExp for inter‑process communication, and ProcMon for tracing, among other tools.

Challenges Overcome

Level 1: C++ Language

For those unfamiliar with C++, relearning it for production use requires steady practice and building a personal technical barrier.

Level 2: Visual Studio IDE

Visual Studio is powerful but its UI can feel overwhelming; features like IntelliSense may be unreliable without proper configuration.

Level 3: UI Frameworks (Qt/Duilib)

Windows lacks a unified UI model; Qt and Duilib (both C++‑based) are the mainstream choices, while Electron is not used in DingTalk.

Level 4: Encoding Issues

Windows defaults to ASCII/GBK, causing frequent UTF‑8 related garbles; explicit encoding handling and tools like iconv are necessary.

Level 5: Debugging with PDB & WinDbg

PDB files provide symbols; WinDbg helps turn raw dumps into actionable information.

Level 6: Build & Modularization

Large C/C++ projects require careful engineering; DingTalk has a dedicated team for these challenges.

Takeaways

The experience taught me the importance of cross‑platform thinking, understanding platform strengths, and maintaining a growth mindset rather than treating any OS as a personal barrier.

On Cross‑Platform Development

Language is only a ticket; mastering platform‑specific interactions (gestures vs. mouse/keyboard) is essential.

On Platforms

Each OS has its own value; developers should avoid treating platform expertise as a personal monopoly.

On Being a Technologist

True “geek spirit” lies in curiosity, deep study, and practical breakthroughs rather than labels.