> it's limited in number, so once in a while I have to delete the sample apps I installed
10, but only for Apple accounts that are not a part of the Apple developer program (99$) AFAIK
> regularly, I have to clean the cache, then clean the hidden cache, then quit Xcode, go and erase some DerivedData, restart Xcode and hope it works
Yes and no… I have been an Apple platform developer for ages, and yes, this has been true for a long time: deleting the derived data was indeed needed way too often (but doing this only has always been enough though, no need to play w/ anything else). The whole build system of Xcode, while powerful, is extremely poorly known (because very poorly documented, obviously), and was, truthfully, unreliable. However, it is getting MUCH better nowadays (and it is also open-sourced; technically they rewrote it in the open from scratch AFAIK). It’s been a long time since I’ve had to delete the derived data tbh. (I still have to close/reopen the project way too often though ><)
Wrt. having to use Xcode, it’s not really true (Xcode only calls other binaries after all), but it is de facto true in the sense that most of the binaries Xcode uses are either internal and/or poorly documented (it’s a theme…).
> Signing is a pain during Apple development.
Honestly haven't have got issues in a while; automatic signing kind of “just works” nowadays. At least for me (and all my teammates).
> You need a development team
No, you can use a standard (free) Apple account, but there are limitations (namely the 10 apps allowed, and the long, difficult(-ish) path to enable it on your phone).
> The Xcode project files are a big mess.
To start off, I’d like to say, having worked (very little) with android studio, I find it as much as a mess as Xcode, if not more.
Once again, poor documentation (you guessed it), and wrong initial implementation (Xcode is very old!) lead to poor practices. Currently, a proper gitignore in an “Apple project” is (not the widely propagated `gitignore` file found on the web):
xcuserdata/
That’s it. You can add `.DS_Store` if you feel like it, but this should be in a global gitignore, not in the repo.
Other than that the structure of an xcodeproj is relatively straightforward: `project.pbxproj` contains the project references and targets/build settings, then there are a bunch of auxiliary files, those of which that are in a `xchshareddata` folder (basically everything that is not in an `xcuserdata` folder) should be shared. These auxiliary files contains mostly the schemes of the projects (configuration to launch the targets), but there can also be shared breakpoints, the Xcode Cloud manifest, performance tests baselines, etc. And also more recently, SwiftPM files (basically the Package.resolved file) are there.
The central `project.pbxproj` file format is an old plist format. Whatever, it’s just a text files containing reference to other files, basically. One of the big problems we had with this was merge conflicts when two different branches added files to the project. Now Xcode supports “folder references” for code too (long time coming, but we have it now!), so this does not really happen anymore (obviously old projects have to be migrated, but the migration works well).
> You want to change something? Go to the Xcode GUI, change some obscure field somewhere…
Yes, but again also no. Proper projects should use xcconfig files and never touch the GUI, thus leaving the pbxproj file alone. It’s not mandatory, obviously, but it’s way better. Also if you modularize your app using SPM, the config of the modules now resides in the `Package.swift` files, not in the GUI at all anymore.
Other solutions exist, that skip the pbxproj altogether in the committed file, and instead have another file format describing how to generate the pbxproj with a project generator. Honestly, using the folder reference mentioned earlier and xcconfig files solves pretty much all of the issues I ever had with pbxproj, so I truly think it’s overkill. It was useful, though.
> Compiling without Xcode is impossible
Depends. For iOS apps, yes. For everything that do not target being an “Apple app,” no. `swift build -c release` and you’re done. I’m pretty sure even “Apple Apps” will end up being simple modules in the end, but we’re not there yet…
Other than that, yeah, xcodebuild sucks very much, though it is not that complex either.
> Talking about CI, you need a macOS machine. That is a pain in itself.
I would not go so far as to say that it is a pain, but yes.
> You want to share your app just with a friend?
It’s 90 days, and if I’m not mistaken google is also taking this route more and more, no? Locking up the platform, I mean.
> talk about SPM that chose to abuse GitHub for distribution
Not GitHub. Any git repository. It’s not the same at all!
> I cannot distribute just a binary, I have to dedicate a repo for that.
Wrong, at least on Apple platforms, and will be wrong for other platforms later. You can distribute xcframeworks via SPM (but the manifest does indeed have to be at the root of a repo, which is indeed annoying to say the least).
Regarding both latest points, you can also use a custom registry and not use git repositories to setup your dependencies. (Disclaimer: I intend on using that, but have not already.)
Also, if you’re using Xcode (because you can be doing other things than iOS apps with Swift), you can use a workspace to put any dependency you want in it. They are just there, ready to be imported. That way you can have e.g. a submodule with your monorepo and any dependency you want in your Xcode project.
> You want to do something with USB?
No. Never have, never will ^^ But I trust you there (: