Last year, while maintaining a hybrid project, I found that the project simultaneously contained Swift pages, Objective-C legacy modules, new Flutter features, and a set of automated build scripts. During development, the editor, build tools, upload tools, and debugging tools were scattered across different places.
Sometimes, even just modifying an API field required going through the process: changing code → compiling → installing → packet capture → repackaging → uploading for testing.
Throughout this entire process, the actual time spent writing code wasn't that long. After that period, I began to realize that the choice of iOS development tools directly affects how a project is developed.
Don't Rush to Choose an IDE
When many people look for iOS development tools, their first reaction is: which IDE is better? But in a project, the IDE is only part of the toolchain. What really needs to be considered is:
- What type is the project?
- What language does the team use?
- Is automation required?
- Is frequent on-device debugging needed?
- Does it maintain multiple technology stacks?
Different conditions lead to different tool combinations.
If the Project is Primarily Native Swift
For pure Swift projects, Xcode remains the core, because it directly handles project management, Interface Builder, simulators, Archive, certificates, and signing.
Especially when dealing with Provisioning Profiles, App Store Connect, and Release builds, Xcode still offers the highest level of integration. However, many developers choose to separate the "code editing" action, for example:
- Using VSCode to edit Swift files
- Using Git plugins
- Using AI-assisted plugins
- Using terminal scripts to manage the project
The reason for this is not to replace Xcode, but to reduce context switching during development.
If the Project Includes Flutter or Multiple Technology Stacks
This type of project presents a problem: different modules correspond to different tools. For example, Flutter pages are in VSCode, the iOS project is in Xcode, and automation scripts are in the terminal. As switching becomes more frequent, the development rhythm becomes fragmented. Therefore, some teams start to pay attention to "unified development environments," which is why in recent years, some integrated iOS development tools have emerged.
When Are Automation Tools Worth Adding?
Many personal projects don't integrate CI/CD at the beginning, but once a project enters stages such as multi-person collaboration, high-frequency testing, or continuous release, automation tools become important. For example:
Fastlane handles automatic building, packaging, uploading to TestFlight, and releasing versions. For instance, after running fastlane beta, the entire release process can be completed directly.
GitHub Actions / Jenkins are more suitable for team collaboration. After code is committed, they can automatically compile, test, build, and upload. These tools solve the problem of "reducing repetitive work" rather than "development."
Debugging Tools Are More Important Than You Think
In many iOS projects, the real time sink is debugging, such as abnormal API responses, inconsistent permission behavior, and differences between real devices and simulators. At such times, you start to rely on:
Charles handles: packet capture, viewing requests, and analyzing APIs.
On-device debugging tools handle: installing apps, viewing logs, and verifying device behavior. Especially when Bluetooth, push notifications, camera, and similar features are involved, on-device verification is inevitable.
A New Direction: Putting the Whole Process Back into One Environment
The problem with many development processes today is not that a particular tool is bad, but that the tools are too scattered. For example:
- Write code in VSCode
- Compile in Xcode
- Package with Fastlane
- Upload with AppUploader
Each step is fine, but the switching itself constantly interrupts the development process. Recently, I came across an interesting tool: Kuaixie (kxapp). Its direction is not to introduce a new programming language, but to try to reintegrate several high-frequency actions.
Currently, it supports Swift projects, Objective-C projects, and Flutter projects. Its editor is based on the VSCode architecture, and it also includes its own set of iOS compilation tools. After modifying a project, you can directly build, run on a real device, and generate installation packages. This kind of tool is suitable for development scenarios that require frequently switching projects, maintaining multiple technology stacks, and wanting to reduce tool hopping.
Choosing Tools Is Essentially Choosing a Development Workflow
If we revisit the question of iOS development tool selection, we find that it's no longer about which IDE to choose, but about how to organize the entire development workflow. Some teams choose to split each phase and handle each tool independently, while others prefer to minimize switching and put the development workflow back into one environment. Both approaches are valid; the key lies in project scale, team habits, and development rhythm.
Top comments (0)