Hacker News Reader

Comment by JohnBooty | Hacker News Reader

    That's also why (forcing more people to use XCode
    and thus the official APIs, BitCode, and so on), 
    they can introduce a whole new architecture like AS
    and have macOS apps support it from day one, or old 
    x86 apps running smoothly translated.

It's a failure of HN culture that posts like this get downvoted. You can like it, loathe it, or feel somewhere in the middle. However, this is factually true, and it is a relevant and legitimate response to issues raised by the parent poster.

View on HN

Yeah but there's nothing that says the Xcode experience has to be so painful[1] or that people have to pay Apple or that software has to be approved by Apple in order to preserve this flexibility. Purchasers should have options, including the option to write software (for themselves) that works on the computer they paid for but might not work if Apple introduces computers based on a new architecture, which the existing Apple customer may or may not choose to buy in the future.

1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.

>Yeah but there's nothing that says the Xcode experience has to be so painful

Well, who says it is objectively painful (as opposed to just not what the grandparent is used to or prefers)?

Its pretty bad.

XCode (with swift) seems to crash on me regularly just with normal usage. The last time I used it occasionally it would lag so badly that it sometimes lost characters I was typing, and my code would come out completely garbled (what!?). A few weeks ago I tried to do a local build of Signal's iOS app and the swift compiler errored out on some random function. Apparently it spent so long doing type inference that it decided to just generate a compilation error instead. I guess I'm not wealthy enough to even compile swift code slowly. (For reference, this on a $3000 (AUD) macbook pro from 2016 with 16 gigs ram, the latest xcode and nothing else open).

Back in the objective-C days I used to really like XCode and loved interface builder. The documentation and ecosystem seemed top notch. But in the last few years its gotten much, much worse. Its like the old guard have left and a young generation have come in to develop the swift ecosystem - and they just don't have good judgement yet. The documentation is halfbaked at best. The whole environment is an overcomplicated, buggy, laggy mess. Its a pity too, because I think Swift is a lovely language and I love what they're doing with SwiftUI.

In comparison I find microsoft's tooling around their languages to be excellent. Visual studio + vs code are fast, stable, feature rich and responsive. Particularly with microsoft's own languages: C# and typescript.

Xcode with Swift is a bit odd in that its performance varies greatly depending on project structure and as nonintuitive as it may be, the way the developer writes code.

For instance a sprawling project with an even split of Objective-C and Swift that constantly call into each other can bring SourceKit to its knees, as can some CocoaPods setups. Going Swift-only or even just reducing the surface between Objective-C and Swift to the absolute bare minimum can speed things up a lot.

As for writing style, there's a few things that can trip SourceKit up but I've found that the main things to avoid are chaining optionals too deeply and nesting closures too deeply (recommend keeping both to 2-3 tops) as well as casting to/from Any too often.

To summarize, this is the most Apple of arguments, that you're making:

"You're holding it wrong."

I think the parent was just trying to help. I’ve had similar problems with IngelliJ when I had the wrong project view open.

Yeah its 2021. There's no excuse for shipping software you know crashes every few hours of normal use. Or lags so badly you can't type sometimes. I doubt XCode in its current form would make it through Apple's own app store review process. Fix your software or replace your staff with people who can.

I choose to abandon programming for Apple's devices entirely rather than put up with xcode.

Not quite - the origin of "You're holding it wrong" was a response to someone who was quite literally trying to illustrate the cellular signal attenuation issue by pressing down with their fingers on the gap between the two antennas.

I believe the parent was saying that the performance of xcode varies based on the project. This is true - breaking projects up into more modular setups has long optimized project build speeds. The quality you get out of your tools is in many cases based on how you use them.

"You're holding it wrong" would apply if you were deliberately using the tools in a sub-optimal way to try to prove a point.

I’ve noticed similar issues, it’s especially a problem with SwiftUI as nesting closures often feels natural there, my brand new M1 mini will still give me the “expression too complex” error on larger SwiftUI components.

I haven't used Xcode much, so it's not for me to say if it's good or bad. However, I would assume that Apple uses Xcode internally, if it was a pain to use, in general, would Apple fix it? At least to save on development cost internally.

Of cause it could be that Xcode is very finely tuned to Apples needs, which may be radically different from those of 3. party developers.

They do use it internally and a lot of teams do complain about it. I hope there is some real work going on to improve some parts of it (how about shipping patches rather than an entire 11gb binary every version). I think a lot of devs also pin certain issues on Xcode that are actually issues with the Swift compiler (slow or missing autocomplete, unhelpful error messages or slow compilation times for example) ObjC is far far quicker to compile.

Apple uses Xcode internally very heavily, and it's less about it being tuned to Apple's needs (which it is, but as an app developer your needs and Apple's match pretty closely) but that Xcode tends to not scale very well.

... Or maybe it is not factually true?

You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.

Given that Apple has explicitly stated this benefit and given that Apple has explicitly utilised these exact benefits in the real world on multiple occasions, it's rather bold to propose that it might not be factually true.

Obviously it's not the only reason that Apple does things the way they do. It's probably not even the number one reason. But it's certainly one significant reason which seems to fit the objective criteria of being factually true.

(To be clear, I am stating no personal opinion about whether Apple's approach is "good" by any criteria.)

>You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.

That's neither here, nor there though. You can still beat the biggest part of fragmentation by "forcing more people to use official API".

Doesn't have to be perfect, just good enough to make moving forward, porting to your new architectures and APIs, etc, easier.

In fact, Apple just showcased it works with the move to M1 (and to a lesser degree earlier with the move to x64 and the move to 64bits).

Linux with gcc supported plenty of architectures without much fanfare.

is downvoting even a thing in HN?

Reply on news.ycombinator.com