For most people Xcode just handles it for you. I’ve never touched it by hand.
It can be, it’s designed for that (as opposed to something like an Xcode project file), but it doesn’t come up for most of us.
Obviously it’s different if you’re not developing on a Mac. But given the usual audience of Swift users, I bet it’s hard to find good tutorials for this kind of stuff.
This. And this was a problem with MS/Windows development for years, too, over-reliance on Visual Studio... In fact, XCode reminds me a lot of older versions of Visual Studio, complete with terrible giant configuration dialogs, generated code galore, and subpar refactoring and external tooling support.
I really don't get Mac/iOS developer's weird stockholm syndrome with XCode -- when I worked doing iOS for a period of time, I used JetBrain's AppCode and it helped take the edge off things.
Granted, I haven't ventured into XCode & iOS dev since Swift came on the scene. That does look to have improved things.
I've worked with Xcode since it was Project Builder. And I worked with Visual C++ from the days when it was two disparate versions, one 16-bit and one 32-bit.
I used to love Visual Studio. Not MFC and its crap-heap of hokey macros, but the IDE. Project Builder was primitive as hell by comparison.
Fast-forward 20 years, and Visual Studio is still plagued by the same ridiculous UI defects it suffered from in the '90s, and Xcode is vastly improved from Project Builder.
I've heard (and evidence bears it out) that there's no one left at Apple who understands how Xcode works at this point. The giant piles of settings, many of which are specified in multiple places in multiple ways, and the corruptibility of the project files... once your project goes wrong there's often no coming back. Granted, this is far less frequent than it used to be, but still... this thing needs a ground-up rewrite behind the scenes.
I work in Xcode daily, and I would be open to trying something else if I thought it would fully integrate all of the non-coding BS that encrusts development. Specifically things like code-signing, certificates, SDK locations, simulator integration... Do third-party IDEs offer seamless support for all that stuff?
Thanks. That's why I haven't bothered to explore anything like that. It's enough of a PITA in Apple's own tools, without troubleshooting third-party hacks.
On the other hand, I did a desktop project in Qt and was shocked at how decently it generated and built an Xcode project. I did have to write a script to sign and package the app for distribution, but it wasn't as painful as plain-old iPhone development used to be simply because of the wildly unreliable certificate BS in Xcode.
Yeah some developers can't be bothered to use productive tools, there is nothing like being able to light up fire with bones and sticks, feel in control of the universe. /s
How was what I posted an anti-IDE rant when I spoke clearly about using AppCode?
The problem with XCode isn't that it's an IDE. It's that it's a shitty one, and Apple keeps trying to shove it on people by coupling the dev experience with their own IDE.
The right thing for platform makers to do is provide tools and infrastructure which can be used in a modular fashion by an ecosystem of third party tools. Offering their own IDE is fine, too, but it should not be required. This is best for the long term health of the platform, and best for developers, too.
He did not do it again. He complained that Apple tied development to ITS OWN IDE, hampering people from using OTHER IDEs.
And he is correct. The problem is that Apple's development environment is such a pile of poorly-understood spaghetti and band-aided shit that I don't think anyone at Apple has the chops (or certainly the time) to clean it up.
"The right thing for platform makers to do is provide tools and infrastructure which can be used in a modular fashion by an ecosystem of third party tools."
I'd dare to say that I have a decent experience with server-side swift using vapor at this point, shipping few production apps. I'd historically always use Xcode, but decided to try to give using Visual Studio Code with that swift extension a shot.
It's been fine, but not an order of magnitude better than using Xcode. Having copilot is nice, but the auto completion is somehow worse than Xcode from my experience so far. And the list goes on, some things are better in vscode, some in Xcode. I might eventually switch back to just using Xcode.
That Package.swift file is the build configuration file. No Xcode required. It describes how to build your program, like a Makefile. Plus, the file is itself a Swift program, where the PackageDescription API serves as a kind of domain-specific language for declaratively describing your dependencies, etc: https://developer.apple.com/documentation/packagedescription
I also would not have known what to do about pretty much any of the problems he encountered.