I thought I was "holding it wrong"... like really badly wrong! and all I was trying to do was clone my repo and compile it for the store, that's it. took me nights and nights to get over each subsequent hurdle and false peak and missing import and then at the end, oh please upgrade and start again.
Thank goodness I only need it for that 1 step and I can do everything else on computers and software that is normal for me. As a first time app maker, I've had a super experience with Flutter in VScode.
Everything in this article is a reason to stay away from everything proprietary about Apple development. If there is some software that can't be delivered with open web technology or an existing game engine, I'd like to know what it is.
I've never trued developing for windows so I could easily imagine it's better across the board.
It also helps if you don't need to go through their app stores, which is a hell of its own.
If you develop on a weak laptop then that is on you / your company, should get a proper machine.
Its good if tools are fast, but in general developers are expected to have fast machines so the tools are made with that in mind.
As for being serious, most of the world being a developer is an office job like any other clerk, many companies have the same computers for everyone, regardless of what they do at their desk, assuming that they still get classical desktops instead of random brand laptops.
Obviously the compiler and emulator (yes, emulator) are slow, but as an IDE it's perfectly functional.
But yeah, if I have the choice between Xcode and Android Studio (and generally iOS vs Android development), Xcode+iOS easily wins, and that's not because Xcode is particularly great.
Now Google has decided to make theirs even worse than Apple at least when it comes to publishing in the play store.
Microsoft is leaps and bounds more open than Google and Apple when it comes to development tooling.
It doesn’t excuse Apple’s behavior, but imo they still have a long way to go to challenge the track record of MS and Intel.
I even advocated for a previous company to try and find someone from the .NET project to help lead a similar but smaller tech transition.
This is better than the story from Apple and Google, who are just terrible consistently, but there is room for improvement.
I've had to make a couple of side projects for my company and I've tried WPF, Blazor, MAUI, and Winforms.
Blazor is the best out of all of these but even it has tedious boilerplate and unintuitive state handling.
MVVM makes WPF and Winforms a hassle, and customizing the looks of components is a nightmare, where some seemingly universal attributes will either get misapplied or outright ignored.
MAUI is a nightmare to work with. Cross compilation is both slow and opaque which makes it impossible to debug and since you are interfacing with the xcode compiler as well you are forced to debug using divine inspiration and hoping it works. We tried to make an RTC AR POC app a while back and it took me 2 weeks of trying different ways to make iirc arkit or webrtc to compile with dotnet and the result was us giving up and just making the iOS version in swift/using xcode instead. I think this is why I still have fond memories of xcode because despite all of its flaws it was noticeably better than trying to cross compile an iOS app from dotnet
Every boxed Mac OS X came with a second disc containing the SDK (Xcode has always been an unstable cow, tho). They used to publish tech notes that explained how the OS works, rather than WWDC videos with high-level overviews that feel more like advertisements.
Back then they've at least made attempts to use some open standards, and allowed 3rd parties to fill gaps in the OS, instead of acting like a Smaug of APIs.
My graduation thesis was porting a visualisation framework from NeXTSTEP into Windows, Objective-C => C++, because my supervisor saw no future on keeping the NeXT hardware in our campus, if he only knew what would happen a few years later.
Still don't have a contact there. Would have thought I would at least get someone there to talk with if issues come up.
So in this great duopoly, these two tech giants constantly compete to become more and more hostile and pathetic to both the users and the developers.
> Apple apologist will respond rudely or with some unhelpful generic tips
Aha. The "you are holding it wrong", "this is how the Lord intended it to behave", "buy a new .." … fruit company fan base phenomena.
Apple's majority of buyers aren't their users or consumers; they are Apple fans and supporters. If Apple had consumers like Android, Linux, or Windows, either they would have fixed their act or been in the ground by now.
Companies who develop these fandoms live life on easy mode. You can do anything you want, abuse customers, raise prices, make promises and never deliver on them, lock people into your ecosystem, and there will always be an army of white knights out there ready-at-the-keyboards, defending the company. I honestly don't know how people get to the point where their identity is so wrapped up in a single company that they wake up in the morning and say to themselves, I'm going to be a company apologist for free and respond rudely to people, even though the company doesn't and will never even know who I am!
Being a rude apologist for NixOS isn't actually morally superior to being a rude apologist for Apple.
no, but it is cheaper and feels morally superior!
The superiority is through the roof (along with the time it takes to update and rebuild-switch).
Seriously though, I just never figured out the first one because I can't figure out where to start and the latter I don't really need as my home area is disposable - the data lives in a data/ partition and the dot files I care about are simply ln -s into a git repo in data/.
Typically, the functionality for managing home configs provided by raw Nix isn't good enough.
On the other hand, the functionality provided by HomeManager basically requires knowing both the package's config language and HomeManager's take on it.
There's also the fact that adding HomeManager basically gives you two ways of doing a lot of the same things. I don't find that great.
My ultimate goal is to have a single source of intent for my laptop setup, so having to manage configs separately (even as raw files) goes counter to that. I'd (very personally for this one use case) prefer my entire config to be in a single nix file without any manually composed dot files.
Flakes... I only started using because it was one of two paths to get secure boot working and I liked it better than the alternative.
Overall, I'm also very conflicted about NixOS. I liked the promises, but in practice, it falls short for me.
for me, I've learnt to live with the limitations - anything I can't get to run on nixos I just won't bother with. anything that does run will probably run forever.
in a way it's similar to switching to a completely different OS - the benefits (e.g. stability, enormous package repo and documentation, etc) far outweigh the issues. I couldn't live with systems that can be broken anymore. well I do on a server, but that's more of a toy than something that needs to be reliable.
Even Symbian C++ across Metrowerks and Caride, felt a much developer friendly experiece than NDK has ever been.
> lock people into your ecosystem
There's no real alternative to Xcode, if you're going to develop for Apple, you pretty much just have to take the dive, buy Apple hardware, and use Xcode. You don't really know what you're getting into before you get there, and by then you've got sunk cost and just have to trudge through. Somebody a while back had a comment that kind of epitomized it (paraphrased from bad memory): "I thought I was their target customer. I'm not. I'm not sure who their target customer is. Who is this even written for?"
_mlxl had a pretty funny one from 4 years ago also: https://news.ycombinator.com/item?id=26932848
> (...) I think its left a little bit of taint on my soul. It is unfathomably bad. Apple keep bolting stuff on to it. 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.
Maybe as an Xcode user you have a better perspective, yet Android was actually better personally than most of the development ecosystems from my own perspective. Actually managed to at least publish three apps. Never went anywhere, yet that's a different issue.Had a comment on another thread's Switch 2 development complaints, re. the few I have tried - Nintendo, Steam, and Google.
Nintendo - The process itself is opaque, confusing, and difficult to determine your status or progress, even large companies have difficulty.
Steam - Signing up and putting launch title info was difficult, yet Wayyyyy easier and clearer to navigate. Tools are kind of a mess, and figuring out everything you need is a challenge. (comments on the SDK are at least funny sometimes)
// This is really, really bad. We're sorry. But it's been this way for
// a long time now and it's scary to change it, as there may be others that
// depend on it.
// Recommended amount
// Quite a bit
// Practically everything
// Wall of text, detailed packet contents breakdown, etc
/* Prefer user version of the interface. But if it isn't found, then use gameserver one. Yes, this is a completely terrible hack */
// This totally sucks, but this information can't be gleaned any
// other way
// (200 lines later) actually no way to do this yet.
// um, yeah, clipping is enabled (?)
// (500 lines later) ???? is clipping ever turned off ??
// hush for now, less spew
Google Play - Dramatically easier to sign up. Much clearer steps, progress, and timeline for release. Inclusions to actually release, much clearer. Actually managed to release three products. Nintendo "How do I even sign up?" Steam "Great, signed up, how do I release something?" Google "Easy sign-up, somewhat easy release of products, eventually got three out the door. Your products have been removed for (mumble mumble legalese)"Imagine an AppCode successor that was designed in full partnership with the XCode team? Tantalizing.
Or you just wanted to be dramatic?
No one wants that.
I'm sure Apple's Dev Tools team reads HN, and it's baffling they just don't care that the product has such a bad reputation. Or if the team cares, some layer of adjacent management clearly doesn't.
> or maybe even better, sizeable investment in them so they maintain autonomy and build a warchest to survive the current AI wave.
Just wow, like trying to talk to an LLM that poluted its context window with the wrong idea then hyperfixated on it ad infinitum, Jesus Christ.
> or maybe even better, sizeable investment in them so they maintain autonomy and build a warchest to survive the current AI wave.
Somehow harms Jetbrains.
Ideally they’d do what Google did with Android Studio. Of course Apple would never openly admit that their product is inferior to that of any of their competitors..
but please don't let that stop you from being the 4th comment to repeat itself.
The other part might be OK, but it's just too hard for me to imagine, I suppose. :-)
I bet these issues are caused by Swift though, because C, C++ and ObjC don't have those problems in Xcode (it's still far from perfect, but it's not slow or crashing).
Actual native macOS/iOS development got beaten senseless when the App Store made it clear that "unsustainably low" was the expected price point for third party developers; and that Apple were treating the store more or less as a market research exercise and good ideas absolutely would be stolen.
So it's an internal tool, really. And we're I-guess-lucky that they document it and release it for the proles.
It is an amazing piece of engineering. It's not perfect, it has it's share of bugs and quirks, but still, it's a wonder to behold :D
But the friction of needing to keep around Xcode anyway whenever you wanted to run your code meant it was just easier to stick with Xcode.
When it did understand my code, it was much better than Xcode for navigating and refactoring.
Also, AppCode couldn't edit or even display XIBs so I often had to keep Xcode running alongside it anyway to edit XIBs and make connections between XIB and code, and that was a hassle.
There is a lot of interest as IntelliJ is a good IDE, but AppCode just wasn't reaching the bare minimum required to have me not use or worry about Xcode.
Once it took Vivado 40 minutes just to add one small Verilog file to a project. Not to compile it. Just to add it to the list of project source files, for which it scanned the file for definitions. Each time I edited the file, Vivado stalled for another 40 minutes. Same file compiled and ran all its simulation tests in Verilator (an open source tool) in a couple of seconds.
For my compiles, Vivado routinely took hours for sparse designs and over 24 hours for dense (but still conceptually small) ones. This made iteration impossible on the timescales my last FPGA project required, so I had to stop using Xilinx.
I accept that dense P&R compiles may take a long time, as it's algorithmically complex. But Vivado's occasional extremely slow and janky process for minor things left my wondering if the full P&R compile time was more due to similar bad coding issues on their side, not any real need to take that long.
Even when you think you're immune to it, Stockholm syndrome is real.
A similar article I wrote on the 'Dark Side' of Apple Development, brings up many additional issues:
[1] For a very limited version of 'free'.
The compile command was basically:
gcc -o foo foo.m -framework Foundation
I think everything developers do in apple's ecosystem is needlessly complicated.I do think Xcode has very rough edges but if we’re criticizing it, we have to criticize the right points.
iOS Safari was a landmine environment to navigate when attempting to shim the native features, but we eventually got 100% coverage. The worst part was 2D barcode scanning and getting the appropriate camera and resolution. After a few hundred hours we had something that was indistinguishable from native.
If you're a B2B vendor working with Apple tech, I would seriously consider the power of the open web. Breaking out of Apple tooling prison is like a 100x+ uplift in productivity if you have expert level familiarity in any other ecosystem.
Is there any way to avoid Apple technologies (that isn't React native, and obviously you still need to build on a Mac) when developing software?
It could be done but I wouldn't want to ever do that again.....
(Didn't read the article, basing this on the subject alone)
The integrated Metal debugger is actually quite spectacular, unfortunately that's countered by the CPU debugger being extremely bare bones and slow.
I got into apple development to publish a unity game to iDevice. To publish unity game to iDevice, you need a mac. You also need yearly apple developer membership. Where they make you jump through hoops which provides them entertainment. Just like you being an animal in a circus which they control.
I learnt apple doesn't care. Now I also don't care. (but yeah that got my money. I didn't get any money)
Microsoft DX has me spoiled.
Maybe only a minority of iOS developers will be using SwiftUI and XCode within a few more years ?
Ballmer's "developers developers developers" moment will forever be burned into my brain, but that wasn't wrong on a strategy level.
I also felt like I had to install the latest iOS emulators almost every week, and everything lagged on the 8GB RAM base model MacBook Air.
Besides, the article reads like a noob using xcode for the first time.
apples_oranges•4mo ago
They will also silently stop supporting some piece of library you rely on, leave it broken in some way or another, and just leave you on your own.
However, it has its good sides. The profiling tools are great for example. And I would rather work on 10 difficult problems with Xcode than on 1 with Visual Studio..
deeznuttynutz•4mo ago
jdjrbrjrbrh•4mo ago
dcrazy•4mo ago
jdjrbrjrbrh•4mo ago