Item — HN Reader

> 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 (:

Thanks for all the insights! To be clear, I didn't want to say that developing for Apple is impossible, right?

I totally trust that once you know how to deal with it, it's fine. But it is extremely frustrating to me as compared to pretty much any other system I have ever tried.

And your message seems to confirm my feeling. A bunch of "yes and no", "there is a workaround", "it's gotten better", "that's not ideal".

Just your explanation about the xcode project files being fine... you have to introduce xcodeproj, pbxproj, xchshareddata, xcuserdata, Info.plist, .DS_Store, and xcconfig. With xcconfig presumably making it easier to deal with the rest. I see how you can be comfortable with that system, but... that's more complicated than pretty much everything else I know, be it Rust, or C/C++ with CMake, or Gradle, or Python. Note that Android-Studio doesn't have project files per se, it's Gradle. Just like an IDE could use CMake.

I cannot read those xc files and pretend to understand them. Which is a problem because some of those at least are versioned and need to be reviewed. I can read a build.gradle.kts and understand what it does. For iOS I actually use "xcodegen" which looks a lot more like what I would fine sane. But that's a third-party tool.

Finally there is a difference between a solo developer and a company account. For a company, it's okay to pay the licence, or to have a custom registry. And for employees, it's fine to spend days handling all that because that's part of the job. But I hate having to touch Apple stuff in my free time, because the developer experience is terribly frustrating to me.

> 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.

Just to be clear: I didn't mean that I like Google, right? :-)

I hate what they are doing there, especially the remote attestation stuff. But I find AOSP pretty good, and open source. I am a GrapheneOS user, and that's the very best mobile OS I know by a long shot. And I owe that to Google releasing AOSP as open source.