back

by frizlab·11d ago·view on hn ↗
Excellent question. I have mostly used Apple tools, but have also tried (most notably) VSCode, android studio, zed, Eclipse, vim and Sublime Text. None of these convinced me, except Sublime which I still use for “non-Apple” projects (also non-android, obviously). I also like vim, but not for coding, just as a general text editor.

I particularly hate VSCode, for some reason (the reason is not that it comes from M$ if you’re wondering; I’m not really sure why tbh, probably because it’s electron and feels particularly not native).

I am aware of IntelliJ, but have never tried it. Given that android studio is based off this AFAIK, I’ll probably not really like it either, I guess? idk

1 comments
Right.

For me I think it is a bit more general than "just" the IDE.

For a start, it's painful to install the apps I develop on Apple devices: it's limited in number, so once in a while I have to delete the sample apps I installed. Also I need to "trust the developer" for each app, and apparently more than once (everytime I uninstall the app maybe?), and it requires going through an unintuitive path in the settings and clicking the wrong choice the first time because "allow" is in red (as if it meant "cancel").

Then it has to go through Xcode. I hate Xcode, but I can accept that people like it. My experience is that 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. All the iOS developers I know are aware of this, so it feels like it's "part of the process"? For Android you can use whatever you please, to the point where you could even write your own IDE!

Signing is a pain during Apple development. You need a development team, sometimes it doesn't work for some unclear reason.

The Xcode project files are a big mess. Developers routinely version a whole hierarchy of file (xcodeproj, xcworkspace and whatnot) without understanding what's there. You want to change something? Go to the Xcode GUI, change some obscure field somewhere, and your xcodeproj files will change in a way you can't understand anyway. "Trust me bro, it worked on my computer", I guess?

Compiling without Xcode is impossible. For Android you can just use gradle (or another build system if you really want), for Apple you have to use Xcode. For scripts or for a CI, you probably want the command line; I find the Xcode CLI extremely bad (I am a Linux person, my favourite kind of UI is CLI, so it's not like I'm confused with CLIs in general).

Talking about CI, you need a macOS machine. That is a pain in itself.

You want to share your app just with a friend? You have to go through TestFlight, send them an invite, and the app will only be available for some days (is it 30 or 90 days?).

Did we talk about SPM that chose to abuse GitHub for distribution? I cannot distribute just a binary, I have to dedicate a repo for that. Wanna use a monorepo? Your Package.swift cannot go into the "swift/" subdirectory, no no: SwiftPM WANTS it at the root of the repo. And SwiftPM will make a complete clone of the whole repo, so all your users will have to download the whole monorepo. People love to hate the Java ecosystem, but Maven solved the package distribution decades ago.

You want to do something with USB? Forget it. Really (don't get me started on MFi). Apple only supports a handful of devices, versus the plethora of Android devices. But still the Android experience is vastly better there: USB has just worked since the very beginning.

I don't know SwiftUI well enough to comment, but the article seems to confirm that it is absolutely consistent with the rest of the developer experience.

And for all that joy, you have to pay 100$/year?

I understand that developers must develop for Apple, because people love their Apple devices. I just don't get it when developer don't hate the Apple developer experience.

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