With rapid advancements in AI, it appears that the era of low-code or even no-code development is imminent. However, over the past year, rather than diminishing, various tools for professional developers have emerged continually. Whether it’s breakthroughs in AI-assisted coding or enhancements in collaboration and cross-platform capabilities, it all highlights the continuing importance of professional developers. Google’s recent releases, Android Studio Cloud and Firebase Studio, further emphasize this commitment to professional-grade tools.
In contrast, within the Apple ecosystem, Xcode, arguably the most vital development tool, has lacked genuinely inspiring updates in recent years. As WWDC 2025 approaches, the highly anticipated Swift Assist announced in the previous event is still nowhere to be seen. Can Xcode still capture developers’ enthusiasm? What changes does it need to stay competitive and relevant? In this article, I will outline several key improvements I hope to see in Xcode.
SPM: The Ideal Way to Organize Projects
The Swift Package Manager (SPM) has existed for several years but has never fully become the primary build tool for Apple ecosystem applications. Compared to Xcode’s proprietary project files, SPM uses a purely code-based format (Package.swift), offering better readability and control, making merging easier, and promoting compatibility with other coding tools.
Although Apple previously allowed SPM to build iOS apps within Swift Playgrounds, it’s disappointing that this functionality hasn’t been extended to Xcode. Moreover, support for SPM in Xcode has regressed, notably in Xcode 16, where the convenient drag-and-drop functionality for referencing local libraries was replaced by manual path configurations (such as ../../PACKAGE_NAME/). This downgrade has significantly hindered the development experience, creating issues like the inability to auto-sync changes, run tests on local libraries, or simultaneously open libraries and projects in separate Xcode windows. Consequently, Xcode has become one of the least friendly environments for SPM, pushing many developers toward alternative editors.
If Apple were to fully embrace and support SPM, it could become the ideal method for project organization, code sharing, and collaborative development within the Apple ecosystem.
Enhanced Directory Organization Capabilities
The introduction of buildable folders in Xcode 16 might seem minor, yet it cleverly resolves a longstanding pain point: the mismatch between virtual logic groups and actual filesystem structures. As a developer, my preference for using SPM stems from its reliance on real directory structures, offering clear logic and seamless integration with Git version control.
I hope future versions of Xcode build on this advantage, adopting mature practices from tools like VSCode and introducing hierarchical, human-readable configuration systems akin to .vscode. For instance, in my current projects, I utilize a root .code-workspace file to globally set Swift compilation parameters, formatting, and linting rules, while specific customizations (such as particular snippets or format rules) are managed within each subdirectory (.vscode/settings.json). This hierarchical approach empowers developers with precise control and significantly boosts version management efficiency during team collaboration.
This real-directory-based, openly configurable organization essentially delivers a higher-level, more intuitive “what you see is what you get” development experience—where your editor directly mirrors the file system, and configuration changes are transparently reflected in readable text files rather than hidden in binary formats.
A More Open Plugin Ecosystem
One key factor in VSCode’s rapid success has been its open and rich plugin ecosystem. Although not a full-fledged IDE by strict definitions, VSCode’s flexible plugin system allows it to meet a wide variety of personalized developer needs.
Conversely, recent Xcode versions have imposed increasing restrictions on plugin development. For instance, currently, no formatting plugins can automatically access .swiftformat files due to Apple’s strict permission policies.
Developers differ from general consumers—they possess mature security awareness and problem-solving capabilities. Apple should not restrict plugin development for a professional tool like Xcode based on consumer-level security considerations. Maintaining an open and vibrant plugin ecosystem is essential for Xcode’s sustained growth and innovation.
Streamlining Xcode
After more than two decades of evolution, Xcode has become a massive collection of functionalities, integrating everything from code editing, debugging, and publishing to 2D and 3D engines, data modeling, and Xib view design. This extensive complexity not only impacts software performance and load times but also imposes unnecessary burdens on users.
I strongly suggest that Apple takes a bold step in splitting lesser-used functionalities into independent applications. This would streamline Xcode, allowing developers to focus exclusively on its core editing and debugging capabilities.
Deepening AI Capabilities
Currently, Xcode’s Predicative Code Completion significantly trails behind mainstream AI-driven coding tools. Even if Swift Assist eventually reaches industry standards, ample room remains for Xcode to further leverage AI capabilities in other areas.
For example, AI could assist developers in optimizing UI designs in previews and simulators, improving human-computer interaction and accessibility. Additionally, AI could enhance crash report analysis, quickly and accurately pinpointing issues and suggesting fixes.
Naturally, enabling greater permissions for third-party AI plugins would significantly accelerate advancements in AI integration within Xcode.
More Practical Cloud Services
While Xcode Cloud provides cloud-based compilation and deployment, I believe Apple can further enhance its utility by offering cross-platform, multi-version cloud testing services. This is especially crucial given the significant variations across SwiftUI and SwiftData frameworks between different platforms and system versions. Such services would greatly simplify debugging and issue replication processes. For instance, Apple could establish a remote device lab, allowing developers to quickly test compatibility across various devices and OS versions directly from the cloud, significantly speeding up the troubleshooting and issue-resolution workflow.
Making Xcode a Preferred Developer Tool
Even though alternative development tools exist, I still personally prefer coding in Xcode. Yet, due to shortcomings in its features and user experience, my day-to-day usage of Xcode has noticeably declined. My earnest hope is that Xcode experiences a substantial leap forward, reclaiming its position as developers’ preferred choice—not merely because it is bound by Apple’s ecosystem.
While I don’t expect WWDC 2025 to fulfill all these wishes at once, I remain optimistic that Apple can genuinely respond to developers’ feedback, delivering meaningful and exciting improvements to Xcode in the near future.