4 ms·

Xcode is a decent tool for new programmers. Also, features like Cmd+Click (go to definition) can be a huge boon when dealing with an unfamiliar codebase. That

Xcode is a decent tool for new programmers. Also, features like Cmd+Click (go to definition) can be a huge boon when dealing with an unfamiliar codebase. That said, for anyone used to using "text editors" (Sublime, Vim, Emacs, etc) it is sorely lacking. I'm not afraid to say that text editing in Xcode is barely more tolerable than a standard web textarea in that respect. It's sluggish, prone to crashing (or losing syntax highlighting), and often displays errors in the middle of typing an expression (which linger for a bit until the inline parsing catches up with the entered text, a process that may take several seconds). This, coupled with the limited text-editing ability, make it very painful to use coming from a text editor. In my personal opinion, the worst part of the iOS development experience is the fact that one is forced to use Xcode to get any clear preview what the app will look like, or to set up connections between a view and the viewcontroller code. One can of course lay out views programmatically, but that process is hilarious verbose and the slow build times make the workflow infinitely more painful than say, HTML+CSS (where one can get sub-second feedback on code changes). This makes any sort of visual/UX work on iOS incredibly painful. P.S. If anyone has any tips on how to mitigate either of these pain points, I'd greatly appreciate it! I fully admit that I'm not an expert and may be overlooking some critical feature that would erase these pains.

quesera 12y ago
I agree completely with your criticisms of Xcode, but I don't find those problems all that bothersome. I like to think of Xcode's syntax checking and highlighting as "eventually consistent". The text navigation aspect does foul me up at times. There's an Xcode plugin for vi-style navigation, which I've used and removed several times. It's OK but incomplete, of course. Xcode as a package includes IB and the debugger and profiler, etc. I'm not convinced they need to be so conjoined, but switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement over the current workflow. Xcode does a much harder job than an editor plus a web browser. I do miss the round trip efficiency sometimes.
- MichaelCrawford 12y ago
  Interface Builder was a standalone application for quite a long time. I don't clearly remember when it became built-in but I think it was around the time of Xcode 5, but it may have been Xcode 4. It would be easy to find out by reading the release notes; Apple has the notes for each release on its developer site. I liked Interface Builder quite a lot more when it was a standalone application. In general, I like a lot of things a lot more when they are separate programs. A gripe I have about Xcode is that I don't readily see a way to have text editing-only windows, and then some other window where I have the project settings. That's how CodeWarrior worked. While Xcode does strictly speaking permit you to open separate text windows, it doesn't really work when you do that. Finally, Apple has never documented any way to add plugins to Xcode. I expect one could reverse-engineer it however that method would not be supported by Apple, and so likely would break in new releases. There is quite a lot of Classic Mac OS code written in Pascal. I see no reason whatsoever that that Pascal couldn't be ported into OS X. There are lots of people who do just that - but they don't do it with Xcode. Even Apple has tons of Pascal code. Pascal code that would be useful on OS X, that would save Apple a lot of money, make life easy for everyone, increase AAPL shareholder value, but no, Steve Jobs for some reason didn't want Pascal on OS X. I really don't have a clue as to why. Consider that while in principle C strings can be of arbitrary length, it is uncommon for them to be very long. To find the length of a C string you have to count all the characters until you find the NUL terminator. To find the length of a Pascal string you just look at the first byte. While that limits the length to 255 characters, that's completely cool with the vast majority of uses of strings of any sort. If you wanted a string-like object of arbitrary length you could define some other type such as a BigString that had a size_t then a character array with no terminator. I don't really know but assertively conjecture that nothing other than converting all your C strings to Pascal strings would make your C/C++/Objective-C programs significantly faster, possibly smaller as well. Consider that strlen takes up the space of pushing the string pointer than calling the function, whereas finding the length of a Pascal string only involves addressing the first byte of an array.
- notduncansmith 12y ago
  > I like to think of Xcode's syntax checking and highlighting as "eventually consistent". This made me laugh, but I suppose I've been spoiled by the responsiveness of text editors. Honestly I wish there were a way to turn off the error checking without losing autocomplete as well. > switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement Agreed - I tried both Sublime and vi alongside Xcode, it's just as (if not more) cumbersome than Xcode alone. I wouldn't even really mind the sluggishness of Xcode if it offered the same text editing capabilities (multi-cursor support, etc) as Sublime. At least then the problem can be reduced to buying a beefier machine.

quesera 12y ago

I agree completely with your criticisms of Xcode, but I don't find those problems all that bothersome. I like to think of Xcode's syntax checking and highlighting as "eventually consistent". The text navigation aspect does foul me up at times. There's an Xcode plugin for vi-style navigation, which I've used and removed several times. It's OK but incomplete, of course. Xcode as a package includes IB and the debugger and profiler, etc. I'm not convinced they need to be so conjoined, but switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement over the current workflow. Xcode does a much harder job than an editor plus a web browser. I do miss the round trip efficiency sometimes.

MichaelCrawford 12y ago
Interface Builder was a standalone application for quite a long time. I don't clearly remember when it became built-in but I think it was around the time of Xcode 5, but it may have been Xcode 4. It would be easy to find out by reading the release notes; Apple has the notes for each release on its developer site. I liked Interface Builder quite a lot more when it was a standalone application. In general, I like a lot of things a lot more when they are separate programs. A gripe I have about Xcode is that I don't readily see a way to have text editing-only windows, and then some other window where I have the project settings. That's how CodeWarrior worked. While Xcode does strictly speaking permit you to open separate text windows, it doesn't really work when you do that. Finally, Apple has never documented any way to add plugins to Xcode. I expect one could reverse-engineer it however that method would not be supported by Apple, and so likely would break in new releases. There is quite a lot of Classic Mac OS code written in Pascal. I see no reason whatsoever that that Pascal couldn't be ported into OS X. There are lots of people who do just that - but they don't do it with Xcode. Even Apple has tons of Pascal code. Pascal code that would be useful on OS X, that would save Apple a lot of money, make life easy for everyone, increase AAPL shareholder value, but no, Steve Jobs for some reason didn't want Pascal on OS X. I really don't have a clue as to why. Consider that while in principle C strings can be of arbitrary length, it is uncommon for them to be very long. To find the length of a C string you have to count all the characters until you find the NUL terminator. To find the length of a Pascal string you just look at the first byte. While that limits the length to 255 characters, that's completely cool with the vast majority of uses of strings of any sort. If you wanted a string-like object of arbitrary length you could define some other type such as a BigString that had a size_t then a character array with no terminator. I don't really know but assertively conjecture that nothing other than converting all your C strings to Pascal strings would make your C/C++/Objective-C programs significantly faster, possibly smaller as well. Consider that strlen takes up the space of pushing the string pointer than calling the function, whereas finding the length of a Pascal string only involves addressing the first byte of an array.
notduncansmith 12y ago
> I like to think of Xcode's syntax checking and highlighting as "eventually consistent". This made me laugh, but I suppose I've been spoiled by the responsiveness of text editors. Honestly I wish there were a way to turn off the error checking without losing autocomplete as well. > switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement Agreed - I tried both Sublime and vi alongside Xcode, it's just as (if not more) cumbersome than Xcode alone. I wouldn't even really mind the sluggishness of Xcode if it offered the same text editing capabilities (multi-cursor support, etc) as Sublime. At least then the problem can be reduced to buying a beefier machine.