For a while, I thought the choice of IDE for iOS development was quite limited, because for any native project, most of the work eventually falls on Xcode. But as projects grew more complex, things changed.

My Flutter pages were in one repo, backend scripts in another directory, and some legacy modules were still in Objective-C. At that time, I had Xcode, VSCode, Terminal, and an automated build window open simultaneously on my desktop. Development was no longer just about opening an IDE and writing code; it was also from this point that I revisited the common iOS IDEs available today.

Xcode Is Still the Most Complete iOS IDE

No matter how the tool ecosystem evolves, Xcode remains the core environment for iOS development.

It handles many things, such as creating projects, managing targets, Interface Builder, simulators, real-device debugging, archiving, certificates, and signing.

For pure native projects, it is still the most complete tool, especially in the areas of “Provisioning Profile”, “App Store Connect”, and “Release builds”. Xcode is still the default entry point in these stages. However, once the project scale grows, many developers separate code editing from project management.

VSCode Is Used by More and More Developers for Writing Swift

VSCode was not originally designed for iOS development, but many teams now use VSCode to edit Swift, manage Flutter projects, write build scripts, and handle Git workflows. The reason is that many projects today are not just iOS code; the same repository may contain Swift, Dart, TypeScript, Shell, and JSON configurations. If all code can be handled in a single editor, the development context stays more continuous.

AI plugins, terminal support, and Git plugins have also made VSCode increasingly common in mobile development.

AppCode: Another JetBrains-Style Option

AppCode was once popular in large Objective-C projects. Its strengths are mainly in code analysis, refactoring, navigation, and handling large-scale projects. Especially in legacy project maintenance, the code navigation experience is noticeably better. However, it still depends on the Xcode toolchain, so it acts more like an additional IDE layer.

Android Studio Also Appears in iOS Projects

It might sound odd, but as Flutter projects become more prevalent, Android Studio has also started appearing frequently in iOS development environments. The reason is that Flutter development requires Dart support, widget debugging, and hot reload, and Android Studio’s Flutter support has always been quite comprehensive. As a result, many cross-platform projects now adopt a hybrid workflow:

Flutter → Android Studio
iOS project → Xcode
Scripts and config → VSCode

The problem is exactly here: as tools multiply, the development process gets fragmented.

Beyond the IDE: A Toolchain

When discussing IDEs, many people focus only on code editing, but what truly affects development pace includes compilation, building, real-device running, and package generation.

Some tools split these tasks apart, while some new IDEs are attempting to reintegrate them.

An Interesting Direction

Recently, I came across an iOS IDE called Kuaixie (kxapp). It takes a different approach from traditional IDEs. Many tools focus on one aspect—Xcode manages projects, VSCode handles editing, Fastlane automates builds—while Kuaixie seems to try to bring these actions back into a single environment.

It currently supports Swift projects, Objective-C projects, and Flutter projects. Its editor is based on VSCode architecture and includes its own iOS compilation toolchain. After modifying a project, you can directly build, run on a real device, and generate installation packages.

For those who need to frequently switch tech stacks or quickly validate requirements, this type of IDE is worth paying attention to.

The Evolution of IDEs Reflects Changes in Development Approaches

The question of what iOS IDEs exist is not about which editor is the best, but rather which development workflow is more suitable for the current project. Some teams insist on Xcode as the core, complemented by multiple tools, while others are inclined to handle more things in one environment and minimize tool switching. Both approaches are valid—the choice depends on project scale, team structure, and tech stack.