[_mlxl]

Xcode unironically made me try to change career from iOS developer to pen tester. I've spent way too much time in its guts and I think its left a little bit of taint on my soul. It is unfathomably bad.

And Apple keep bolting stuff on to it (and the new stuff doesn't work - Canvas for SwiftUI previews for example).

It's slow, broken in numerous ways, depends on file formats that aren't used anywhere outside of Apple and completely undocumented. It is such a painful tool to use.

[Cloudef]

It's pretty sad how bad both iOS and Android development ecosystems are. Xcode is crap, homebrew is crap, gradle is crap ... Basically all tools hate automation. SPM seems like thing that could make things better, but it's swift only. Also the build times are ridiculous. How I wish I could just run compiler on a text file and run the god damn program I wrote on the device I own, like on every other sane OS.

[nexuist]

This is why the JavaScript people said screw the whole thing and worked on porting web-esque development to mobile rather than trying to learn how to develop native apps. The difference in developer velocity is obscene. The only close native competitor I can think of is Flutter, which ironically is severely hampered by having to interoperate with Xcode (the thing that takes the most time out of any other task is compiling a production build). Flutter uses Dart which almost reads like vanilla JavaScript, and instead of dealing with the native UIs they just used Skia[1] to draw pixel-perfect equivalents for each platform (as opposed to React Native, which attempts to use the actual UI components and make them available in JS).

[1] https://skia.org/docs/dev/flutter/

[Cloudef]

Ironically for hobby projects I've been using react-native as well, because it really makes developing a app faster, even though it will be bloated as hell. It's funny how even flutter decided to go with "new language" route. I guess NIH is strong in Android and iOS ecosystems.. I miss maemo/meego ...

[pabs3]

Maemo is still around in the form of Maemo Leste. There are also various other open source mobile projects, notably postmarketOS. In terms of hardware, the PinePhone and Purism Librem 5 are projects aimed at non-Android open source operating systems like Linux/BSD.

https://maemo-leste.github.io/ https://postmarketos.org/ https://wiki.debian.org/Mobile#software-distros https://www.pine64.org/ https://puri.sm/

[Cloudef]

It exists, but sadly the market share is for ios/android and thats what i get paid for. Pine also seems interesting.

[pabs3]

I guess it is pretty unlikely for any new mobile company to take much market share from iOS/Android, not without billions in marketing anyway.

[FlashBlaze]

Can you elaborate on the bloated part? I created a simple HN clone in React Native (without expo) and after publishing to Play Store, the app size was under 10MB.

[Cloudef]

Simple color picker app I made is 25MB. Even 10MB sounds pretty large for a simple app. But what I'm trying to say is more that I don't feel very hygienic considering using all these abstractions to develop a simple app, if I could just use the same C codebase to deploy for both platforms. Latter is technically possible, but nobody has created a framework around it similar to flutter or react-native. Flutter seems like the better option for the hygiene now though.

[novok]

Funny enough there has been a long standing issue (as in years) with metal shaders that make the first minute or so of animations in flutter stuttery as the shaders compile.

[exikyut]

Presumably (asking out of curiosity, completely naive) there's no way to AOT compile them?

[novok]

Kind of? But there seems to be a bunch of barriers in making it happen:

  SkSL warm-up doesn’t help newer iPhones using Metal.

  Flutter recently migrated from OpenGL to Metal for all newer iOS devices. (Please reference Metal on iOS FAQ on which iOS devices are considered new enough to use Metal.) However, Skia currently only implemented the SkSL warm-up for OpenGL. So the SkSL warm-up would only speed up older iOS devices by default. If you find shader compilation jank to be an issue for your app on newer iPhones, please let us know by filing a GitHub issue. In the longer term, we have a plan to use test-based shader warm-up to mitigate this. If there’s an urgent need for fixing shader compilation jank on newer iPhones, please leave feedback on Issue 61045, and we can help you turn on OpenGL for your app.

https://flutter.dev/docs/perf/rendering/shader

https://github.com/flutter/flutter/issues/61045

[sebe]

Two weeks ago on reddit "Shader precompilation for Metal has landed in Skia:" https://www.reddit.com/r/FlutterDev/comments/mq1ouu/advices_...

and comment from last week on a flutter issue say it's working for them on the master channel. https://github.com/flutter/flutter/issues/79298#issuecomment...

[smoldesu]

Honestly, that's why switching back to good old Linux feels so good for developers. If you know what you're doing, tossing up a C workspace takes 30 seconds, if you're slow. Using an honest-to-god free operating system is so much more liberating than bending your current setup to meet your needs.

[OnlyMortal]

I’m with you. The original applications of Project Builder, Interface Builder and TextEdit were better because they were focused.

Feature creep is never a good thing.

It’d have been better to build tools for Swift in its own right, allowing those tools to integrate - probably by using distributed objects.

But, it isn’t that way so such is life.

[azinman2]

I strongly disagree. I don’t want to have to open multiple tools when it should all interoperate together for the same effective high-level task. Unifying it all just allows for better (hypothetical) integration between all the parts.

Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).

[adrusi]

Multiple tools doesn't mean that they can't interoperate. It's just that Apple (and everyone else) has given up on graphical IPC.

[nexuist]

+1 for the term "graphical IPC." It is a huge pet peeve of mine that native apps choose to push new views onto navigation controllers instead of just opening a new window. They're looking to invent browsing history when there shouldn't be any (and if you need browsing history - use a browser!).

[adrusi]

Ah, but if you open a new window, then users will have too many windows open and get confused or frustrated! You would need some kind of innovation in window management beyond the 1990s for that to be feasible.

But desktop OS vendors seem to still be operating under the paradigm of making their desktop environments as approachable by computer novices as possible. Maybe still a good business decision, but the future for desktop OSs is clearly with professionals and enthusiasts, and it's my hope more advanced human/computer interface approaches will follow.

You can have better window management facilities on Linux, but you have to choose between software that copies the mainstream paradigm of, as you say, pushing new views onto navigation controllers (and I'd add using tabs/split-panes built into the window itself instead of being offloaded to a more sophisticated window manager), or software that's quite rough around the edges.

[colejohnson66]

What’s a graphical IPC? How would processes communicate graphically?

[nexuist]

Not OP but my layman's understanding is that it would just be two GUI windows communicating over standard IPC. The current trend is for the entire application to be represented as a singular window, using navigation or tab controllers to switch between views rather than popping them out into their own windows.

[adrusi]

Better window management paradigms aren't quite what I was referring to, but would also be great for mainstream software vendors to not have given up on. I use the Sway compositor on my personal machines to get some sort of reasonable window management tooling, which is lovely to the limited extent that even Linux software embraces composability in graphical environments. Would be nice to have similar tools on my work macbook.

[adrusi]

More precise would be to say "graphical IPC control" or "graphical IPC initiation." I'm trying to point to the ability for users in a graphical environment to coordinate intricate communication between processes. Copy/paste and drag-n-drop are canonical examples, but I'd say that macOS tools like Alfred should also count.

[nexuist]

> Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).

How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?

Doesn't this signal that the market prefers lightweight IDEs over heavier ones?

Me personally, I would love to have a text editor on the left and the iOS simulator on the right and that's all you need to ship. Xcode Playgrounds attempted to execute this shift, but they still need much more attention until they can function as well as the regular workflow does (which is sad, 'cause the regular workflow sucks).

[jcelerier]

> How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?

I only know extremely few people who'd use VS Code for C++, so "popular" is really ecosystem-dependent

[BearOso]

I use it. VS Code+clangd intellisense makes it easy to enumerate available classes, functions, and members, and because you don’t have to remember excessively verbose objects, writing self-documenting C++ is simple. Plus, you get automatic syntax checking as you go. That you can get these in a less-than-IDE nowadays is wonderful.

[plorkyeran]

Visual Studio does not do a superset of what VS Code does. There's the very obvious difference in that VS is Windows-only while VSC is not (there is a Visual Studio for Mac, but it's a third unrelated program and not a Mac version of Visual Studio). Even if you are running Windows, VSC has more functionality than VS for non-C/C++/.NET development.

[yashap]

I’m a primarily backend dev who works on mobile apps sometimes, and I strongly agree. It’s a truly terrible and frustrating piece of software. It tries to do way too many things, and does them all poorly.

Even doing something as simple as upgrading Xcode via the App Store is painful, often progressing insanely slowly and taking hours or even tens of hours on an otherwise fast connection. It has been like this for years and years and Apple has done nothing to fix it, like most Xcode issues.

[_mlxl]

I want people who haven't used Xcode to understand that this isn't a connection issue, there is something specifically weird happening with Xcode when you try to upgrade it.

It has to be wed to the OS in such a way that makes the propensity for this vague failure state to occur, because I've never had it happen with anything else.

Upgrading from the App Store sometimes will hang at 99% and no matter what you do save some weird incantations to remove stuff from this secret App Store cache to remove the download to begin its excruciatingly slow download again, only with the hope in your heart this impenetrable and silent error doesn't happen again.

And of course none of this is addressed by Apple. You think you can just download versions from the developer site? Well enjoy, and I am not joking, a 30+ minute unzipping of the .xip file (yep that's right, it's not a .zip).

Apple does not care about it's developer ecosystem, even though you are such a huge part of it's success. It's apparent in their thread bare documentation, their terrible tools, their greedy practises.

I get it. They are a business. But they do not deserve their halo.

[akmarinov]

It used to be a zip, there’s a reason why they changed it to xip

[AJRF]

That reason being digital signatures. You can get the same confidence from posting an MD5 hash to check. Xips are an awful solution to fix a solved problem.

[akmarinov]

Absolutely no one will bother to do the check.

[saagarjha]

The reason is stupid for the problem it solves.

[MobileVet]

I started downloading the dmg manually quite a few years back... and have never adopted the AppStore version. So painful.

This SO post is continually updated with the latest builds and is a bookmark for me. https://stackoverflow.com/questions/10335747/how-to-download...

[anaerobicover]

You might also like https://xcodereleases.com/ which is updated automatically.

[saagarjha]

I believe it is actually updated manually.

[smoldesu]

Xcode is ludicrously large. Most installs will clock in 50-60 gigs, but I've seen more full setups exceed 100gb.

Why is this the current paradigm of developing on a platform that notoriously "just works"?

[saagarjha]

Xcode is nowhere near that large, unless you never clear out its caches.

[domano]

And they tax the CPU pretty hard too.

[MobileVet]

This, so much this.

I have a fully loaded MBP 16” w/ i9, 32GB RAM and the fan starts very quickly due to indexing and whatever else it is doing.

[josephg]

I have a 2016 MacBook Pro which has gradually become completely useless for swift development in Xcode. The computer sometimes randomly reindexes while I type, which can lag Xcode so much that it drops keystrokes. And as a result if I’m not watching closely, sometimes method names will come out garbled. To reiterate, Xcode makes my $3000 computer from a few years ago so slow that I can’t type the name of a function.

A few months ago I moved to a ryzen development machine running Linux mint to code rust using IntelliJ. Responsiveness and stability is night and day. It’s a shame, too - swift is a lovely language and I’d love to use it more. But life is too short to put up with Xcode.

[MobileVet]

Crazy right? $3.5k and it can’t handle indexing / compiling Swift?!

Some other devs on the team just got M1s. They are backend though... so I haven’t seen an M1 running Xcode yet. Very curious but I am guessing it is night and day... for half the cost or less.

[wsc981]

> Xcode unironically made me try to change career from iOS developer to pen tester. I've spent way too much time in its guts and I think its left a little bit of taint on my soul. It is unfathomably bad.

I've been a mobile dev for many many years and most of my time was spent focused on iOS.

I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.

Last few years more of my time was spent with Xamarin and the macOS version of Visual Studio (rebranded Xamarin Studio) and it's quite a bit worse than Xcode. Xamarin Studio has the tendency to get really slow after extended usage and I pretty much never had such issues with Xcode. Few things are more frustrating to me (not to mention a huge productivity killer) than writing code in a slow, laggy editor. At least Xcode doesn't have that issue (most of the time).

However, what I really like is to be able to just use a simple text editor for my work. Lately, as a hobby and for side-projects, I've been using Sublime Text with LÖVE 2D (Lua) and this has been really fun to me. No project files to deal with, no complicated UI stuff (visual editors and the like), no more downloading of gigabytes of simulators after an update (as long as I focus on macOS & Windows that is), etc...

With MAUI, Microsoft will make the default Xamarin project structure also really simple, just a few lines of code. That should make it a lot easier to use a simple text editor for Xamarin dev work, instead of the slow Visual Studio for macOS IDE. Perhaps Apple should follow suit with Xcode.

[kitsunesoba]

As another primarly-iOS developer I agree. Xcode was better back when Interface Builder was separate (that merge never should've happened) but as a whole I don't find Xcode any more irritating than I find Android Studio (which has found some truly unique ways to be frustrating).

It will be interesting to see where things go in the coming years though, because between SwiftPM, SwiftUI, SourceKit, and the SourceKit LSP I think many of us may be shifting toward a workflow more centered around a light editor. A few days ago I was toying around with SourceKit LSP in Sublime Text 4 and it's surprisingly servicable - most of my projects have abandoned xibs/storyboards already so I could probably make that setup work if I put some time into getting Sublime's build system set up.

[jamil7]

Did you manage to get SourceKit LSP picking up SPM dependencies? I tried it out with neovim last year and that was one issue I had. I’d probably do most of my editing in there if I could.

[void_mint]

> I've been a mobile dev for many many years and most of my time was spent focused on iOS.

> I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.

In my experience, iOS/macOS devs have just kind of "got used to it" with regard to Apple's developer tooling. Once you know how to work with all of it at an advanced level it doesn't seem that bad.

I think the issue is when developers that haven't spent considerable amounts of time acclimating have to work with Apple's dev tools. If you haven't been hazed into being productive with Apple's tools, they won't work how you expect and it won't be obvious why.

[akmarinov]

Isn’t that pretty much all IDEs if you come over from whatever you’re used to?

[void_mint]

No, I would say most languages and IDEs are not as complex/bloated/unpredictable as Apple developer tools.

[josephg]

I’m a polyglot and love trying new languages and platforms. I’ve spent serious time with eclipse (Java), IntelliJ (rust), vscode (rust, javascript, typescript, C), vim (all), visual studio (C++, c#). I have lots of Apple devices, I care about platform-native software and I love the swift programming language. And call me crazy but I loved Xcode with Obj-C back when it was 3.x.

So I can say with confidence that writing swift using modern Xcode is the worst experience with an IDE I’ve ever had. Dropped keystrokes, random crashing, device-dependent compiler errors (“Error: this method spent too long type checking”). And so on. It’s an obvious, avoidable disaster zone. Dear Apple, fixing the bugs in your software is more important than adding new features!

In comparison, VSCode+Typescript and Visual Studio+C# are the best IDE experiences I’ve had. Fast, stable, smooth, reliable and easy to set up. And little things work well - like inline documentation, autocomplete, project wide renaming and integrated debugging. Microsoft nails it. IntelliJ+Rust is close but it has a few obvious rough edges.

[ASalazarMX]

It's the only IDE I've used where I couldn't trust it not to crash. IDEs should not crash, even if rarely.

[josephg]

No software should crash; and if it does, you figure out why it crashes and fix the problem.

The fact that Xcode crashes reliably, and has done so for years without being fixed is a stain on apple’s reputation for making otherwise good products.

[fishywang]

My own Xcode horror story:

It was the end of 2009. I was working for a small startup doing some Twitter clone. We decided that we want to provide an iPhone app, and since we already provided Twitter like API, the easiest way is to just fork an open source iOS Twitter app to replace all the API endpoints to ours.

I was doing that, using Xcode. One day the compiler complained something like "unexpected `\`". Looking at the code in Xcode, I don't see any \ around the position compiler pointing to.

After stared at the code for an hour, I finally decided to open that file in vim, and sure there's an \ added before a double quotation mark I believe, while in that context an escape is not needed (and doing that is wrong, thus the complaint from the compiler).

So Xcode's editor, trying to be smart, auto escaped a double quotation mark at the wrong place, and don't show it in the editor at all. Their compiler caught the error.

[cageface]

My base stress level improved tremendously when I gave up iOS development and went back to the web. I don't have to deal with frustratingly broken tools every day or hold my breath every time I publish an update in case some random app store reviewer is having a bad day. Never again.

[smoldesu]

I would almost be compelled to use and develop for Apple products if Xcode wasn't so comedically bad.

[wlesieutre]

> Canvas for SwiftUI previews for example

Automatic preview updating paused [Resume]