I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.
In a project with code-only UIKit, only a smattering of SwiftUI for small components, and minimal dependencies, Xcode isn’t too bad of an experience and I’d say comparable to and in some ways better than Android Studio (that localization XML editor, not mention Gradle… ugh).
I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points. They are definitely fixing bugs. I make software for iOS, macOS, car play, and apple watch.
Sure sometimes I've got to reset or clear a cache, but this has never stopped my day.
What is so horrible about XCode?
Starting a 'cold' debug session into a UI application may take 10-ish seconds until applicationDidFinishLaunching is reached, and most of that time seems to be spent with loading the symbols for hundreds of framework DLLs which are loaded during application start (which I never even need because I can't step into system frameworks anyway) - and seriously, why are there even hundreds of system DLLs in a more or less hello-world-style Metal application with minimal UI? This problem seems to go back to the ancient times, but it gets worse and worse the bloatier macOS UI processes become (e.g. the more system frameworks they load at start).
The debugger variable view panel is so bare bones that it looks like it's ripped out straight from an 80's home computer monitor program.
When debug-stepping, the debugger frontend is quite often stuck for 10s of seconds at completely unpredictable places waiting for the debugger to respond (it feels like a timeout).
Step-debugging in general feels sluggish even compared to VSCode with lldb.
For comparison, VS2026 isn't exactly a lightweight IDE either, but debugging sessions start instantly, debug-stepping is immediate, and the CPU debugger is much more feature rich than Xcode's. While in Xcode, everything feels like it's been added as a checklist item, but then never actually used by the Xcode team (I do wonder what they're using to develop Xcode, I doubt that they are dogfooding their own work).
The one good and useful thing about Xcode is the Metal debugger though.
Claude code 8 hours later: It's done, mate!
A lot of refactoring work across both platforms ends up being manual one way or another.
Ever attempted this before at a large company and had success with it? I think I can count four times so far in ~15 years where people attempted to rewrite something medium/large-scale from scratch around me, was a success once, although scope was drastically cut at the end so almost a stretch to call it a success.
First, the performance is just bad. The responsiveness compared to apps like VSC or Panic’s Nova is night-and-day.
The attention given to the design of new features is piss-poor. Placing the AI functionality on the left sidebar makes no sense; all the other tools on the left are project management; the "let me run weird functions and interact with stuff" UIs like terminal, debug and logs are in the bottom panel. Or maybe a new tab in the main workspace area?
The SwiftUI preview canvas can't be floated as a separate window, making it all but useless on anything smaller than a 16" MBP (and only barely usable there). In fact, I think it might be impossible to use Xcode in multiple screens altogether…?
Old simulator versions and cache files hang around forever, you need a third-party app like DevCleaner just to keep your storage from filling with nonsense. Cryptic messages like "copying symbols to device"… clear-cache that doesn't seem to clear-cache, that stupid list UI for info.plist…
I never thought I'd have anything nice to say about PNPM package management, but you can always just delete `node_modules` and reinstall and count on things working. Swift package management is a cryptic mess, and their insistence on using a GUI instead of a basic JSON manifest just compounds it. Like the info.plist thing, a lot of Xcode is based on a developer UI philosophy from the Mac Classic days that has mostly been abandoned by the rest of the world.
Mostly, I think the vitriol surrounding Xcode is that Apple seems to think they're doing a good job; meanwhile their most ardent and adept users are insisting that they are not. Same boat as MacOS, really.
- Interface Builder is stuck in early 2010s. Not only is the property panel missing half of options we now take for granted everywhere else (like corner radius), it also randomly won't read fonts in the current project, will crash the entire IDE if you Cmd-Z a big change (things like unembedding a view) and half the UI is still not rendered the way it will be on the phone. Yes, Swift UI exists, but most bigger apps are still XIBs and Storyboards and it's going to remain that way for quite some time.
- Autocomplete is a hit or miss. Very much like the mid-90s Microsoft IDEs where you'd get totally useless results until you've typed the whole line out already. It can be done well, look at AppCode.
- Syntax highlighting feels pretty much the same. Randomly flashes on and off, often doesn't highlight until return is pressed, takes a long time to load on large files etc.
- Git integration is by far the worst I've seen out of any IDE and I've seen many. I'd go as far as to say that SourceSafe integration in VB6 was done better. Just the whole layout, modal-on-modal returning to the first modal on an error in the second and so on. It's crashed when rebasing a few times too, I don't trust it with larger operations since.
- Documentation browser is this annoying little window with semi-useful search. But don't worry, the docs in there are useless anyways. I could go on and on about their approach to docs but maybe next time.
Don't even get me started on performance. Things like switching file tabs should be instant by now but there are still noticeable delays for larger files and IB screens. Plus there's now two kinds of tabs (app-level and file-level) to add to the mess.
XCode is just terrible compared to Visual Studio.
As you said, there are weird beachballs all the time both while stepping and while waiting for the application to stop at a breakpoint (in cases where it happens instantly running under VS on Windows).
The Jump to Definition seems to have gotten flakier. Or maybe it's always been terrible relative to Visual Studio, IDK. But regardless a lot of times I'm just going by memory and Cmd+F on XCode - Jump to Definition and Cmd+Shift+o are just not getting there.
The Variables pane in the Debugger often just fails to actually ... display anything for any of the variables when stopped at a breakpoint. Sometimes it will appear after stepping a couple lines, sometimes it won't.
The Debugger is even flakier than usual when Lambdas are involved.
I am an emacs guy so it's not like I'm disposed to like Visual Studio. Visual Studio's quality has slipped a little too. But XCode feels straight-up amateurish in comparison to it. That said, at least Apple is actually exposing the capabilities of the IDE to their LLM integration offering. This is an improvement over the abortion that is Copilot integration in Visual Studio.
Boom! emacs is the IDE now. Bonuses all around.
This means you've learned to work around its shortcomings. A decade ago I used to develop in PyCharm for websites, and Visual Studio .Net for desktop apps. Then I had to learn XCode for a mobile app.
It was a surreal experience, like going back ten years in UX, while at the same time dealing with a myriad of modern but artificial limitations and breaking changes that meant the app needed frequent housekeeping even when its features remained unchanged.
For a company that gets a huge part of its revenue on its oversized App Store tax, developers, and their tooling, should be one of their highest priorities IMO. Instead, we get Kafkaesque situations like "my app doesn't compile today... oh, I need to open my Apple Developer account in the browser and accept a new little change in their kilometric EULA that I always pretend I've read carefully". Things like this could be handled better.
Edit: I also had to learn Android Studio for another app, and the experience had less friction overall, but that could mean that I've also learned to work around the shortcomings of JetBrains IDEs. Google is undeniably more developer-friendly than Apple IMO, though.
For the last ~15 years or so I only use Xcode on the command line sporadically. Prior to that I had to endure the full Xcode experience. I actually liked it between crashes!
Ask Microsoft, they have much more experience with that.
> Did you think that SwiftUI was shoved down your throat?
On a scale of 1 to 10, it has been shoved down our throats at level 1 or maybe 2. Thankfully it's optional.
> Did you think that CoreData was shoved down your throat
No.
> Perhaps develop a more nuanced critique.
I believe most people who used Xcode perfectly know what I'm talking about.
This is a very strange question. It more correct to ask "In what way is AI NOT being shoved down your throat".
> Did you think that SwiftUI was shoved down your throat?
Yes
> Did you think that CoreData was shoved down your throat.
No
Single files in our codebase already blow the Copilot query token limit.
Great, Anthropic taught Claude to grep. On our project, it's still useless because it can't use the semantic search in the IDE.
There is no perfect IDE. They all have problems / are inadequate / get in the way. I absolutely loathe IntelliJ IDEA for example, and think Eclipse is needlessly complex (though I'd like their code-indentation/formatting UI to replace the one in Xcode).
Honestly, Xcode gets a lot of bad comments, but it works pretty well for me and the debugging tools are pretty much top-notch if you take the time to learn them.
I started a project on January 5th. Running sloc right now I see:
---------- Result ------------
Physical : 44454
Source : 31019
Comment : 7284
Single-line comment : 2622
Block comment : 4662
Mixed : 210
Empty block comment : 2
Empty : 6363
To Do : 0
----------------------------
That's a lot of code in just under a month (and none of it from AI tools), I don't think the IDE is getting in my way.
It most certainly is not, lol. That's the hype that the parent was referring to. Most people have found AI to be a detriment, not a benefit, to their work.
This tells more about your code quality that about copilot, and I'm not a fan of copilot
I think the bigger issue is contributing to OSS for putting Linux on a Macbook for example could be considered leaking company secrets since you would have access to internals. I find it hard to believe that Apple would go after someone for making a open source calculator app.
Apple internally has structured their projects to not run into all of the debugger performance cliffs, but don’t provide any guidance on how to do the same thing and don’t proactively fix the problems they’ve avoided.
Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree.
It sounds like OP doesn't like the way Xcode does things differently to other IDE's.
Sure, it's a dumpster fire. But human engineers work on it just fine without investing man-decades into refactoring it into some shrine to the software engineer's craft.
The whole point of AI, in our parent company's eyes, is for no one to mention "code quality" as something impeding the delivery of features, yesterday, ever.
It's not even rotting away. It was never completed.
It's XCode 26, and you still can't have the navigator and tabs work like in all other software on all other operation system, also including MacOS.
It's absolutely bonkers, and one of the reason's I decided to use Emacs if possible when working on "XCode projects".
XCode is good for project-reconfiguration and step-by-step debugging, but as an editor it's absolutely unusable.
You can’t step into a lambda stored in a std::function
Absolute nightmare if you don’t know which lambda it might be so you can set a breakpoint in it.
Honestly, compared to Visual Studio, Xcode is 20 years behind.
Not doing so while senior management demands the use of AI augmentation seems odd.
Perhaps it's just the setup you (the generic "you") are used to or something. I've got 3 4k screens connected to a Mac Studio here, and plenty of space for a terminal or four to be running on-screen at the same time and in windows that don't obscure the things I want to look at. I guess if you code on an MBP and space is limited, it might be easier to switch to ? But I generally want that space for my debugger and console-app i/o. I think it'd just get in the way...
I expect others do things differently for different reasons as much as much as I expect an IDE to support more than one type of user.
No, it isn’t. There are irresponsible voices in the community who claim that it is, but they always find convenient ways to omit the downsides (on both the tech and effects on society as a whole).
But I agree that Xcode runs fine on small projects and recent version feel stable compare to past releases.
Sometimes I'll use Ghostty at the same time and switch between the two. Just depends on what I'm trying to do at the moment.
Nothing wrong with maintaining all the context you need in a single window instead of alt+tabbing to different apps, especially for those not engulfed by three 4K displays.
Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at.
> Because I like to get project-aware completions, or run pre-configured tools from the IDE in an actual shell, for example. > Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at.
Window switching is bad enough on MacOS, especially if you have multiple projects open at the same time.
Stepping through the debugger too fast will sometimes put the debugger in a weird state where step never breaks again and all other breakpoints stop working.
Git pull through the UI with stash and merge can blow away your local changes if there is a conflict. The changes aren't stashed. They're just gone.
Xcode likes to sometimes recompile files that haven't changed slowing everything down, sometimes significantly depending on the file. No idea why.
It can get very confused if you're missing a parenthesis in the wrong place in a SwiftUI View leading to opaque swift compiler errors about code being too complex.
Even mildly complex use of a swift #Predicate will cause an error about it being too complex forcing you to break them down into smaller pieces and even then it takes far too long to build even on a brand new machine.
The simulators are quite slow to start/update/run and xcode sometimes fails to shut them down completely when quitting leading to them just continually running eating memory unless you kill the processes manually.
The simulators also are really limited in their functionality. No background processes, spotlight, network degradation simulation, out of memory killer, etc.
The profiler sometimes just fails to start an app correctly, immediately ending a run forcing you to close the profiler and reopen it again before it'll start working.
Symbol refactor (rename) can be painfully slow where the UI just locks up until it can find all the references.
Xcode likes to duplicate package dependencies in xcodeproj. It just creates new hashes for the same library and adds it as a dependency over and over again, so when the link phase happens, it adds libraries repeatedly over and over and over again unless you manually clear them out. Not sure what causes this, perhaps updating the version or merges between users.
MacOS has very very slow slow window- and desktop- switching (over one FULL second to switch from one desktop to another - this is not a joke!) so having a terminal integrated into the same application is very useful for maintaining flow for users developing on a single-screen Macbook.
This is so you can see function names for system frameworks. You can step into them if you want too even if Xcode tries to stop you doing it by default.
Window switching is instantaneous though, and I do that a lot
For your use case, imagine if the Window switcher, instead of being instantaneous, was a ~1200ms animation which blocked all key presses during the animation.
I just checked with a screen recording. Switching desktops takes 15 frames (250 ms). If you turn reduce motion on, it takes 13 frames (216 ms).
it constantly disconnects, requires restarts and other nonsense techniques. i legit do not know how you can not be running into these problems if you are developing on those platforms.
Turns out, for me, the terminal emulator embedded in the IDE has been a big plus.
(only half joking)
> functionality on the left sidebar makes no sense
> converted it to obj-c’s short lived garbage collection
From a screen recording, I count 53 screen-recorded frames from the apparent start of the animation (which occurs after it's invoked) to desktop widgets becoming transparent (which appears to be the point input is no longer blocked). IINA says the video is 50.582 fps (very strange frame rate?) so that would be ~1050ms.
Of course, that doesn't include any input latency or the display latency, so I also took a video with my phone. I took two trials and I recorded a full 1.08 seconds from key depression to transparent widgets. I did two more with Reduce Motion on and got the exact same time.
I am very curious what your set up is, because I am invested in getting this as close to 8.3 ms as possible.
edit: For comparison, my Linux desktop with a similar experimental set up, this takes about 24ms from key depression to the next desktop becoming visible. The only experimental difference is that I had to switch to the "slow mo" camera to record the difference, and I have a 240hz monitor. The desktop is also considered one of the slower ones (GNOME).
TLDR: It takes 1.08 seconds, on my Macbook, to complete a desktop transition.
When I used it in a team, I had to write a build step that would fail the build if the pbxproj file wasn’t sorted. (Plus a custom target that would sort it for you.) It was the only way to make sure it never got unsorted in the first place.
Not sure why yours is so much slower than mine. Mine is definitely 250 ms long or 15 frames from the time I hit the shortcut.
I used the onscreen keyboard viewer to get visual feedback when the shortcut was pressed and recorded audio so I could hear it being pressed. I even recorded it a second time using OBS to ensure I was at 60 fps and trimmed the whole segment down to just the animation and sure enough, the video is exactly 250 ms long according to IINA.
Also, I don't have any visible delay between pressing the key and the animation starting. The animation starts on the same frame as when the shortcut is recognized by the onscreen keyboard viewer (which is the same time as I hear it being pressed) in the recording. The keyboard delay must be < 16.6 ms.
when your IDE crashes (inevitably), you lose the entire console context and all running processes within it. There is also no way to detach the terminal from the IDE, say when the IDE needs to be updated (constantly).
IDE terminals also tend to be buggy.
I assumed it came from Windows users who have a habit of running everything in full-screen.
I invite you to back up your claim by researching the following (as a starting point).
Visual Studio, Visual Studio Code, VSCodium, IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, CLion, GoLand, Rider, RubyMine, DataGrip, AppCode, RustRover, DataSpell, JetBrains Fleet, JetBrains Air, JetBrains MPS, Eclipse, NetBeans, Xcode, Android Studio, Sublime Text, Emacs, Spacemacs, Vim, Neovim, Theia, Code::Blocks, Dev-C++, Neil deGrasse Tyson’s Seemingly Limitless Trove of Knowledge, Turbo C++, Borland Delphi, RAD Studio, Lazarus, Qt Creator, KDevelop, Anjuta, GNOME Builder, MonoDevelop, SharpDevelop, BlueJ, Greenfoot, DrJava, Son of DrJava, Evil Bizarro Son of DrJava, jGRASP, Barely Beyond Your jGrasp, JDeveloper, JBuilder, JCreator, Aptana Studio, Komodo IDE, Komodo Edit, Geany, Light Table (may it rest in peace), Brackets, Zed, Cursor, Windsurf, Trae, Google Antigravity, Void, VoidedBowels, Kiro, Qoder, Cline, OpenCode, Spyder, IDLE, Thonny, Wing IDE, Eric, PyDev, PyScripter, Pyzo, Jupyter, RStudio, Zasper, MATLAB IDE, Scilab, Octave GUI, LabVIEW, Arduino IDE, PlatformIO, MPLAB X, Keil µVision, IAR Embedded Workbench, Atmel Studio, Other FPGA Tooling That No One Has Heard Of, Microchip Studio, Code Composer Studio, STM32CubeIDE, Segger Embedded Studio, AvalonStudio, ElectronIDE, Replit, Gitpod, GitHub Codespaces, AWS Cloud9, Google Cloud Shell Editor, Firebase Studio, Codenvy, Eclipse Che, CodeSandbox, StackBlitz, Glitch, If you have read this far, I am very impressed, Codeanywhere, CodeTasty, CodeTasty+, CodeTasty++, SourceLair, JSFiddle, CodePen, JDoodle, ShiftEdit, AppJet, PowerShell ISE, Embarcadero C++Builder, some IDE that I began coding 10 years ago but never finished, PureBasic IDE, GameMaker Studio, Unity, Unreal Editor, Godot, Redot Engine, Construct, RPG Maker, Defold, CryEngine, Roblox Studio, Stride, Open 3D Engine, HaxeDevelop, FlashDevelop, Leksah, Pharo, Squeak, DrRacket, LispWorks, Allegro CL, SLIME, some IDE invented inside some company you’ve never heard of, CIDER, Calva, Cursive, Smalltalk/X, Visual Works, IBM Rational Application Developer, IBM Rational Software Architect, SAP ABAP Workbench, Oracle SQL Developer, Toad, DBeaver, HeidiSQL, pgAdmin, SQL Server Management Studio, Xojo, LiveCode, HCL Domino Designer, Clarion, Progress OpenEdge, 4D, FileMaker, OutSystems, Mendix, Salesforce Developer Console, placeholder for some truly hideous Semantic Web monstrosity, Oracle APEX, Oracle Forms Builder, some random side project that Stephen Wolfram commissioned an intern to build, PowerBuilder, WinDev, PrimalScript, SlickEdit, UltraEdit, CodeLite, Source Insight, Pelles C, Open Watcom IDE, LiteIDE, Nova, BBEdit, TextMate (not everything in this list is actually an IDE, apparently), CotEditor, CodeWarrior, Turbo Pascal, Borland C++, Visual Age, Visual Cafe, Forte for Java, Sun ONE Studio, Zeus IDE, SciTE, Programmer’s Notepad, Ultimate++, Cevelop, Zinjai, JCppEdit, WeBuilder, Bluefish, CudaText, Kate, gedit, Notepad++, PSPad, EmEditor, Textadept, Leafpad, Graviton, Lite XL, Lapce, Helix, Micro, Cosmic IDE, Squircle IDE, CppDroid, Pydroid 3, Squiggle, SapphireSteel, Codelobster, CodeWright, The Reverend Thomas Bayes’s Glorious Probabilistic Workspace, CSPro, Adobe ColdFusion Builder, yikes that last one gives me nightmares, Adobe Flash Builder, Basic4ppc, BlackBox Component Builder, Bricx Command Center, CA-Telon, Maestro I, Absoft, ANTLR Studio, Apple Dylan, Stardraw, DbVisualizer, Mule IDE, v0, Coder, Data Display Debugger, Softbench, Visual Basic IDE, Dartmouth BASIC IDE, Athas, Fresh Editor, PlayCode, MyEclipse
(Thanks Claude, once again you have been more helpful than a human, which is more than a little concerning.)
I don’t know if all of these are real or qualify as IDE’s, but I hope I’ve made my point: it turns out using the word “every” is a broad and bold claim.
And please don’t simply backpedal and say that you meant “most” unless you’ve actually done the research.
Certainly I have tried to accomplish tasks giving Claude guidance far outstripping "a modicum".
People just like to complain
You should be careful making such statements to an audience in which many have been around when IDEs were invented.
It's certainly a useful thing to have, and yes, these days many IDEs do have it. But Xcode itself is from the time long before that feature became the default. And, unfortunately, it is mostly still stuck there.
There is some input display on Macbook Pros, but that'd account for easily <100ms of the difference we're seeing (I'm holding `control` and measuring from depression of the arrow key).
I tried changing screen resolution, quitting apps like Rectangle, etc. No dice.
In digging more deeply than I had before, I did find some things which were rumored to speed it up. Disabling multi-color preview, and disabling "displays have separate spaces". (I am using only one display). This shaves off some time (taking about 950ms)! (!!!)
There is also a four-finger gesture which, if done fast enough, appears to speed things up. But it's difficult to reproduce and often "overshoots" to other spaces.
I have a few questions, if you'd oblige:
- Are you also using ProMotion (120hz)? (The biggest thing I can find to speed this up is switching to 60hz, but this does not quite get to 250ms).
- Are you also switching using ctrl+arrowkey(left/right)? (Ctrl+number is notably faster, but not what I'm looking for.)
- Were you using MacOS before this M1 Pro? (This is my first MacOS machine, I'm wondering if there might be some hidden configuration carried over from a previous install with faster transitions).
Typically I have 3-4 different projects open at a time and probably 30-40 terminal windows across them and other places (in Ghostty).
Honestly it had never really crossed my mind that people used the built-in terminal for anything!
If I'd do anything to Xcode or Android Studio, it'd be to split more things out of them and make them excellent at their core tasks.
From using Apple products, I get the impression that the same is true for many other things.
Wow.
I won't say Xcode is anywhere near the worst IDE I've ever used (Eclipse) but I wouldn't say it's anywhere near best in class either.
Whether it was successful or not is up for debate. It certainly was nowhere near as performant as the old system but probably 99% of features came across.
This is the dumbest response anyone can ever have to being presented with the answer to their own question of "what's wrong".
Ok you don't think this is important but your customer (or whatever) just to told you it's important to them. Surprise surprise this is literally why xcode sucks (because Apple seeks to dictate instead of accommodating).
Zed's ACP seems to be a good solution to this - when using it, claude code has access to the IDE's diagnostics and tools, just like the human operator. https://zed.dev/acp
And, this isn’t strictly XCode, but my least favorite thing about writing apps for apples platforms is all the admin overhead. You need an Apple development account, signing certificates, app groups, entitlements… just let me compile my code man.
Since when terminal is "the most basic feature"?
Reading threads in HN and seeing mild "wars" how Kitty/Alacritty/Ghostty/iTerm/Konsole/you-name-it are worse/better than Kitty/Alacritty/Ghostty/iTerm/Konsole/you-name-it, because they are slower/faster, (in)compatible with some ancient niche protocols/standards, etc.
Does not seem that basic to me?
Also it's personal preference, but I somehow used to have my editors and my terminals separate. I guess something about having a tool that does one thing best and all.
All software of comparable size and complexity have shortcomings that everyone learns to work around. And a great many of those shortcomings are actually just highly subjective personal preferences. More than half of the complaints in this thread are, to me, a terrible idea.
Often autocomplete is hopeless and doesn't help you with the most simple things like picking from multiple initializers, or changing to a different signature of a function call.
the project setup is this mystery Xcode project file, instead of a standardized yml or something that anyone can modify and understand.
I have to say provisioning has improved a lot. I remember back in 2008, it was really a pain to get anything working.
This is not necessarily about Xcode, but maybe it should be: screen shots for your app. they need screenshots for 454 device types, and zero automation in their own tooling.
the layout is also very inflexible. they dictate a couple of panels and that's how you _must_ use them. that's unlike any other modern IDE.
Window tabs are weird but powerful. You can even name them and then have the preferences > behaviors show or hide these named ones at certain times.
By your logic (that many people discuss) web browsers are "basic", IDEs are "basic", programming languages are the most "basic" thing (how many of them! discussions are limitless!!).
EDIT: have the gut to explain yourself instead of downvoting ;) , I am not discussing in bad faith , but you do you.
Perhaps I'm doing something wrong, but whatever it is, it works for me. I still don't see any advantage to putting a second-rate (they're never as good as the real thing) terminal into an IDE. Someone mentioned project-specific completions, but I can't say I've ever needed the terminal to do that, and I generally don't run IDE-specific tools (also mentioned) from the terminal either.
Maybe my natural workflow gels better with how Apple envisioned people using the IDE, perhaps I happen to be on the "golden path", but ... again shrug. Works for me.
This is part of the issue IMO. Is this size and complexity warranted?
Rust for example; its a complex language, can target pretty much all platforms under the sun, and yet it's configured with just text files, builds with just terminal commands, and works great with any text editor.
I've seen people in big tech work on codebases millions of files big with everything from VSCode to a russian text editor from the 90s. Linus Trovalds is building Linux with MicroEMACS. Why do I need a behemoth like Xcode to build a To Do app? Why does it have to be this "big and complex"?
Debugging is integrated, profiling is integrated, script-running as part of the build is integrated. Application output is integrated. What do you actually use it for ? Genuine question.
I guess the AI tools might be something - I don't know about that, I don't use them.
In either case that's less than 1/3 of a second. It's nowhere near what you're seeing. I'd be tempted to take the machine to an Apple Store and say "this is broken, please fix it".
I think this is a big part of the problem. Apple owns the IDE and the programming languages; in theory this should lead to a great experience. In practice, because they insist you only use their languages with their ide, and their ide with their languages, it leads to lousy tool design.
Features that would be best implemented as part of the compiler suite are instead be implemented in the GUI. File formats that could be simplified live on, because everyone is using GUIs in the IDE to edit them anyway.
Fixes that should be prioritized in the IDE get punted because the IDE is not competing with any other IDE, it's the only way to develop the language, people will use it anyway, etc.
In other words, I don't care about the memory use.
I think I commented earlier that there's not that much I use the terminal for during development - mainly git. Keeping a terminal open, mainly hidden, in the bottom-left corner with the tab set to the top-level directory isn't really a burden.
The whole conversation came from someone claiming the most basic feature of an IDE is to include a terminal - that's why people are discussing terminals.
Don't get me wrong, I live in the terminal when using the computer, but I don't see a need for one when using Xcode.
The original comment was aimed at Xcode though, and it's in that context that I'm (still) struggling to see why you need a terminal.
Example: Right now I have a project with a main application, a launch agent, and a framework. I can fit 3 columns of text with the font at a size I can easily read across one window in Xcode. I generally work for a period of time in one of the app/agent/framework areas, so I have 3 Xcode windows open on the same project, each having ~90% of the screen with a little overlap.
Sometimes I'll have another similar window, for out-of-context work. If I'm creating a class, and suddenly realise I want to re-factor some other class to make it work, I'll open another window (again with the 3 columns) for the re-factor work, leaving the state of where I was ready to come back to at the click of a mouse.
I personally find it easier to mouse-click to change context than any other way, so keeping the screen 'mostly' used works better for me.
The point about Xcode being complex, I disagree with. Honestly I could think of so many additional features to make my workflow easier.
Visual Studio does treat C++ as a first class language (I suspect because that was the first non C language it supported and Windows apps used C++ in the 1990s)
I would try Clion for C++ if you can't use VS. Eclipse was reasonable 15 years ago when Apple used gcc.
To put it in a language Apple understands, it's like forcing music producers to use GarageBand when everyone else is on Logic.
If you were able to use a magical, fast, bug-fixed, version where everything 'just worked' at pace, I imagine you would begin to realise just how much you have been putting up with!
Yeah, I love editing XML files to build my app
Depending on what I'm doing, I need these processes either run alongside the project while I'm working on it (like watching source files), execute them automatically when something happens (like setting up a Stripe webhook proxy when I start the debug build), start them with environment configuration from the IDE (for example a database console), or really just have them close to the code (like a linter).
IntelliJ has a task runner built-in that can do all of this very easily, in a way that I can share it with the rest of my team, and don't have to bother with remembering specific commands.
Ultimately, my complaints only really apply to coding for work. For personal projects I find emacs / LSP / dap more than sufficient.
But to be honest this is still something I should maybe bring up with our tools team. If it works well with .xcodeproj files it might be a good fit for our team.
I've set up tasks to run at build-time in Xcode - the 'Build Phases' tab can add tasks to be run automatically, which are just shell-scripts and Xcode sets up just about every variable under the sun for you in the environment, so you can navigate to the right directory, add the current-target as part of a name etc. They're saved as part of the project so everyone gets them.
But that doesn't cope with the interactive side of what you're talking about. In truth, I've always just done that from the command line 'pqsl -d <database>' (or 'sqlite3 database') has always been sufficient - though if your interactive session shares the database context that the application is also using (so you're not waiting for a flush to get updates) that would be interesting.
Quality checking I tend to integrate with git rather than the IDE, setting up a hook on pre-commit to run unit tests and so on. In a previous life different teams used different IDEs, but we always wanted the tests to run :)
Still have no idea what it actually means, or why it takes so crazy long.
If they have to update symbols upon every OS version bump, are they cleaning out the old ones? It's so frustratingly opaque.
Most of the problems I encounter now resulted from the fiasco that is SwiftUI. I used to really enjoy development, and built a few mobile apps singlehandedly... even at a well-known company or two. But now I'm struggling to get one chunk of functionality at a time done on a from-scratch app, because SwiftUI and the underlying "reactive" paradigm were so poorly conceived and defectively implemented. Development is now miserable drudgery, and I never feel confident about the result. The absurd gymnastics to trick the UI into doing what you want; and the hypocritical, conflicting edicts for Swift and SwiftUI... it all barely hangs together.
The fact that Apple rolled out a new UI toolkit that didn't support the most fundamental paradigm in mobile applications, a stack of progressive views for the user to proceed through, tells you how far off the rails they went since introducing the original and solid SDK.
And testing is going to be a nightmare... or simply futile.
- Control-Left/Right takes about 1 second.
- Four-finger swipe left/right takes about 1 second.
- Alt-Tab to an app on another desktop takes about 0.25 seconds.
I'm using Sonoma 14.8.3, but from the comments it sounds like the timing distinction is similar on other versions.
For example, Apple Developer costs 99 USD a year, and you are forced to develop on a physical Mac. Google Developer has a free tier, and lets you develop on Windows/Linux/MacOS/VM.
This is just one of the little ways where Google products prioritize developers, while Apple products prioritize market share and consumers. Both companies have abusive practices, can't argue that, but Apple has more needless friction for developers.
Are you using software like Rectangle, Better Touch Tool, etc?
All of that is in Xcode (and a hell of a lot more besides). That makes it integrated, at least IMHO.
You commented above, and I replied, about some of the tasks you use an integrated terminal for, and I'm not trying to say you shouldn't or that that's not useful to you - you obviously know your own workflows and what works best for you :) I just don't see it as "the most basic feature you could integrate into an IDE" (which was the original claim).
I'd probably put 'text editor' up as the most basic, closely followed by compiler integration and then debugger. Static analysis would probably come next, then unit-testing support, doc-comments, and tools like refactoring, good multi-file search/replace etc.
A terminal app is way, way down the list. For me. I realise everyone is different and YMMV :)
When reduce motion is turned on in the control panel though, the ctrl-arrow and ctrl-# animations take the same time on my machine (216.6 ms)
I'm doing the same thing you are, holding control and measuring from when I tap the next key.
No ProMotion and only using the internal display. I was running other Macs before this, so there is a chance some configuration crossed over.
Nobody is saying not to use Xcode if you like it, but there should be a choice like there is for almost every other modern platform.
> into floating utility panels