When organizing an old project some time ago, I counted how many tools I opened in a day.

As a result, I use VSCode for writing code; switch back to Xcode when debugging certain modules; run build scripts when creating test packages; and open another tool when uploading installation packages.

These actions have become habitual, so I rarely think about: what exactly are iOS development tools?

What Developers Face Every Day is a Process

Many articles discussing iOS development tools simply list a bunch of software names. However, from the perspective of the actual development process, tools have different purposes. For example, a typical feature development cycle goes through these steps:

• Creating a project
• Writing code
• Version management
• Compiling the application
• Running on a device
• Debugging issues
• Generating an installation package
• Uploading for testing

Each step involves different tools.

Writing Code: The Editor Determines Work Habits

For many developers, the most frequently used tool is the editor. Xcode comes with built-in editing capabilities, and Swift projects are almost inseparable from it.

On the other hand, VSCode is becoming increasingly common, especially when maintaining front-end, back-end, and mobile projects simultaneously. Many developers want to minimize editor switching. Syntax highlighting, auto-completion, and plugin support do not change business logic but affect the rhythm of daily coding.

Therefore, choosing an editor is more about choosing a way of working.

Project Management: Project Structure Matters More Than Expected

As the project scale grows, tools take on other responsibilities, such as:

• Managing targets
• Managing schemes
• Managing dependencies
• Managing resource files

These tasks are rarely discussed in technical sharing but happen every day. If a project contains both Swift and Objective-C modules, the importance of project structure management becomes even more apparent. Problems encountered during development sometimes stem not from the code itself but from project configuration.

Compilation: The Most Overlooked Step

Many people do not think about what happens behind the scenes when they click the Run button. In reality, a simple compilation action may include:

• Parsing the project
• Reading configuration
• Selecting architecture
• Calling SDKs
• Linking system libraries
• Generating the application

Only after all these steps are complete can the application run. For developers, the compiler is usually unobtrusive, but it determines whether a project can become an executable program.

Device Debugging: The Most Frequent Action in Development

Many features can only be verified on a real device, such as:

• Push notifications
• Camera permissions
• Bluetooth functionality
• Location services

Therefore, device debugging happens almost every day. If a page requires repeated modifications and verifications, the cycle of “modify code → run on phone → view results” repeats many times. Whether a tool can shorten this path directly affects the continuity of the development process.

Build and Distribution: Another Process After Development Ends

Many people equate development with writing code. However, after the code is complete, there is a completely different process:

• Building the Release version
• Generating the installation package
• Testing distribution
• Submitting for review

The tools involved here are different from those in the development phase. For example, Fastlane is more oriented toward automated builds.

AppUploader is more focused on uploading and distribution. They solve problems that arise after development is complete.

More Developers Are Starting to Focus on Tool Processes

As projects become more complex, a phenomenon gradually appears: the number of tools increases. For example:

• VSCode for writing code
• Xcode for managing projects
• Fastlane for automated builds
• AppUploader for uploading installation packages
• Git for version management

Each tool is specialized, but the switching cost is real. During development, frequent switching between multiple windows is often necessary. Some teams continue this approach because each tool can maximize its utility. However, some tools are beginning to explore a different path.

A More Integrated Approach

Recently, I came across an iOS development tool called Kxapp.

What caught my attention is not that it supports some new language, but that it attempts to reassemble several parts of the toolchain into a single environment.

Currently, Kxapp supports:

• Swift projects
• Objective-C projects
• Flutter projects

The editor uses the VSCode architecture, so many developers will find it familiar. In addition to code editing, it also includes its own set of compilation tools that can directly handle project building. The ability to run on a real device and build installation packages is also integrated into the same environment.

For developers who need to frequently switch between projects, quickly verify requirements, or maintain multiple technology stacks, this design approach is quite interesting.

It does not change iOS development itself but attempts to reduce the back-and-forth between tools.

If iOS development is understood as “writing code,” then the role of tools seems limited. But if development is seen as a process, you will find that:

Editors, compilers, debugging tools, build tools, and distribution tools all participate in the same process.

Different developers make different choices. Some prefer to handle each step separately, while others lean towards using integrated tools. The recently seen Kxapp is one such attempt.