6 ms·

At first I was excited that Xcode had some competition, so I downloaded this as soon as it was available. Unfortunately, it has a crappy Java-generic GUI. For

At first I was excited that Xcode had some competition, so I downloaded this as soon as it was available. Unfortunately, it has a crappy Java-generic GUI. For an IDE for a platform that makes a big deal out of user experience, it really looks awful. (And it manages to be slower than Xcode 4!) I understand that tools don't have to be pretty to be functional, but I draw the line here.

frou_dh 16y ago
Same deal with MonoDevelop. These alien GUIs look absolutely miserable in OS X alongside the system and all the tastefully done third party native apps you have running.
- jasonlotito 16y ago
  Unfortunately, outside of xcode, their is no other competition. No other IDE comes close. Considering this release is a pre-beta (and not some faux-beta popular with web two point oh startups these days). Having used other Jetbrains products, I'm fairly certain that when all is said and done, the final product will be solid IDE.
  - msbarnett 16y ago
    > Having used other Jetbrains products, I'm fairly certain that when all is said and done, the final product will be solid IDE. It probably will be solid, but having used their other products on the Mac (RubyMine, IntelliJ), it's probably never going to get any less java-ugly or feel any more native. And I think that's likely to be more of a problem for potential users of AppCode vs RubyMine or IntelliJ users on the Mac. Because its target market is either established Mac developers who care about the conventions and tastes prevalent in Mac software, and thus find AppCode ugly and alien in function, or users of other JetBrains products getting started with Mac development, for whom AppCode might feel familiar but will be a barrier to learning about the conventions and tastes prevalent in Mac software, leading them to produce sub-par experiences with the product.
    - chrismsnz 16y ago
      Meh - it's not for those us who like everything in its place, fully native "oh my god it's so elegant" software. It's for those of us who want something that does everything we want (plus some more) without being too hard on the system resources and has the ability to stay out of our way when we need it to. It's true, Jetbrains products are not the most beautiful, and yes they're mostly written in java. However, they do make incredibly functional products with a slim learning curve with some amazing features. Jetbrains products (from Python to Ruby to PHP, and I'm sure their new AppCode) have consistently shown the best understanding of the code being developed which contributes to the best code sense and refactoring support I've ever seen in any IDE.
- extension 16y ago
  Funny, "alien GUI" is how I was going to describe Xcode. If the final version of this looks and runs as well as iDEA, it will do just fine, and will hopefully bring OSX/iOS dev back down to earth.
  - _frog 16y ago
    I can't say I share your dissatisfaction wot the new XCode UI, initially I disliked it but now I have no idea how I ever lived without it. Just give it a chance is all I'm saying.
    - lemming 16y ago
      I might say the same about AppCode (edit - aimed more at the folk bashing the UI than the parent).
spullara 16y ago
In the worst case scenario you should keep it around for refactoring. The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around.
- msbarnett 16y ago
  > The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around. Assuming AppCode's refactoring support ends up being even as good as Xcode 3's hit-or-miss heuristics, which remains to be seen. "AppCode is from JetBrains and ReSharper/IntelliJ IDEA have great refactoring, so AppCode will too" isn't a valid line of reasoning, because the limiting factor here isn't the author of the tool, it's how much a priori reasoning you can actually do about the target language in question. C# and Java are both, by design, highly amenable to the kinds of static analysis that make refactoring support simple. Objective-C, by design, is not. Xcode 3 and below did a lot of pattern matching to try to make a decent go of autocompletion and refactoring, and it fell down a lot of the time. With Xcode 4, Apple has turned the new compiler, LLVM, into a shared library and hooked into it for refactoring and autocompletion, so they're working with the same parse trees the compiler is, and they have as much information to reason with at compile time as can be hoped for in an extremely late binding, weakly typed language like Objective-C. How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't. In short, I'm extremely skeptical of the claim that AppCode is going to be leaps and bounds better at statically analyzing Objective-C than Xcode 4, given the constraints of the target language.
  - Zev 16y ago
    How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't. You can have symbols available to you from the compile that you're not interested in using. How do you filter them out smartly? There is plenty of room for improvement, even with a LLVM-based parser for determining possible autocompletions. Also, Xcode 4 has a tendency to forget it has to show me any completions at all. At that point, Xcode 3's autocompletion is preferable to, well, nothing.
i386 16y ago
I have a few disagreements with what you have said here. AppCode is in Beta - it's going to be slow and its going to crash. Even though you have stated that "tools don't have to be pretty to be functional" I think you have contradicted your point here by writing off AppCode on that basis entirely. As a software developer, fair criticism of a tool should never rely on its aesthetics but rather on its ability to solve problems and solve them productivity. Eclipse, Emacs, Hudson, et al are tools I wouldn't say are aesthetically pleasing but they are very successful at solving the problems they were designed to solve. Thus I believe aesthetics should logically be placed secondary to utility.
- stevejohnson 16y ago
  I really did want to expand on the point you disagreed with, but I had to leave. Here's a bit more. What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use. So far, reading and testing, I have not seen any reason to prefer appCode to Xcode. If appCode had some sort of killer feature, then I would put less emphasis on the way it looks. In addition, this sort of interface displays a fundamental misunderstanding of OS X and iOS by Jetbrains. Integrating with an OS is about more than getting your code to run and do stuff. I am a user as much as any iPhone owner is a user.
  - lemming 16y ago
    What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use. This is the crux, for me. After years of becoming accustomed to the million and one tiny points of attention to detail about the development experience (as opposed to the user experience) that JetBrains are known for, this announcement is fantastic news. XCode is painful by comparison.
- masklinn 16y ago
  It's not even in beta, it's in EAP.

frou_dh 16y ago

Same deal with MonoDevelop. These alien GUIs look absolutely miserable in OS X alongside the system and all the tastefully done third party native apps you have running.

jasonlotito 16y ago
Unfortunately, outside of xcode, their is no other competition. No other IDE comes close. Considering this release is a pre-beta (and not some faux-beta popular with web two point oh startups these days). Having used other Jetbrains products, I'm fairly certain that when all is said and done, the final product will be solid IDE.
- msbarnett 16y ago
  > Having used other Jetbrains products, I'm fairly certain that when all is said and done, the final product will be solid IDE. It probably will be solid, but having used their other products on the Mac (RubyMine, IntelliJ), it's probably never going to get any less java-ugly or feel any more native. And I think that's likely to be more of a problem for potential users of AppCode vs RubyMine or IntelliJ users on the Mac. Because its target market is either established Mac developers who care about the conventions and tastes prevalent in Mac software, and thus find AppCode ugly and alien in function, or users of other JetBrains products getting started with Mac development, for whom AppCode might feel familiar but will be a barrier to learning about the conventions and tastes prevalent in Mac software, leading them to produce sub-par experiences with the product.
  - chrismsnz 16y ago
    Meh - it's not for those us who like everything in its place, fully native "oh my god it's so elegant" software. It's for those of us who want something that does everything we want (plus some more) without being too hard on the system resources and has the ability to stay out of our way when we need it to. It's true, Jetbrains products are not the most beautiful, and yes they're mostly written in java. However, they do make incredibly functional products with a slim learning curve with some amazing features. Jetbrains products (from Python to Ruby to PHP, and I'm sure their new AppCode) have consistently shown the best understanding of the code being developed which contributes to the best code sense and refactoring support I've ever seen in any IDE.
extension 16y ago
Funny, "alien GUI" is how I was going to describe Xcode. If the final version of this looks and runs as well as iDEA, it will do just fine, and will hopefully bring OSX/iOS dev back down to earth.
- _frog 16y ago
  I can't say I share your dissatisfaction wot the new XCode UI, initially I disliked it but now I have no idea how I ever lived without it. Just give it a chance is all I'm saying.
  - lemming 16y ago
    I might say the same about AppCode (edit - aimed more at the folk bashing the UI than the parent).

spullara 16y ago

In the worst case scenario you should keep it around for refactoring. The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around.

msbarnett 16y ago
> The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around. Assuming AppCode's refactoring support ends up being even as good as Xcode 3's hit-or-miss heuristics, which remains to be seen. "AppCode is from JetBrains and ReSharper/IntelliJ IDEA have great refactoring, so AppCode will too" isn't a valid line of reasoning, because the limiting factor here isn't the author of the tool, it's how much a priori reasoning you can actually do about the target language in question. C# and Java are both, by design, highly amenable to the kinds of static analysis that make refactoring support simple. Objective-C, by design, is not. Xcode 3 and below did a lot of pattern matching to try to make a decent go of autocompletion and refactoring, and it fell down a lot of the time. With Xcode 4, Apple has turned the new compiler, LLVM, into a shared library and hooked into it for refactoring and autocompletion, so they're working with the same parse trees the compiler is, and they have as much information to reason with at compile time as can be hoped for in an extremely late binding, weakly typed language like Objective-C. How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't. In short, I'm extremely skeptical of the claim that AppCode is going to be leaps and bounds better at statically analyzing Objective-C than Xcode 4, given the constraints of the target language.
- Zev 16y ago
  How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't. You can have symbols available to you from the compile that you're not interested in using. How do you filter them out smartly? There is plenty of room for improvement, even with a LLVM-based parser for determining possible autocompletions. Also, Xcode 4 has a tendency to forget it has to show me any completions at all. At that point, Xcode 3's autocompletion is preferable to, well, nothing.

i386 16y ago

I have a few disagreements with what you have said here. AppCode is in Beta - it's going to be slow and its going to crash. Even though you have stated that "tools don't have to be pretty to be functional" I think you have contradicted your point here by writing off AppCode on that basis entirely. As a software developer, fair criticism of a tool should never rely on its aesthetics but rather on its ability to solve problems and solve them productivity. Eclipse, Emacs, Hudson, et al are tools I wouldn't say are aesthetically pleasing but they are very successful at solving the problems they were designed to solve. Thus I believe aesthetics should logically be placed secondary to utility.

stevejohnson 16y ago
I really did want to expand on the point you disagreed with, but I had to leave. Here's a bit more. What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use. So far, reading and testing, I have not seen any reason to prefer appCode to Xcode. If appCode had some sort of killer feature, then I would put less emphasis on the way it looks. In addition, this sort of interface displays a fundamental misunderstanding of OS X and iOS by Jetbrains. Integrating with an OS is about more than getting your code to run and do stuff. I am a user as much as any iPhone owner is a user.
- lemming 16y ago
  What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use. This is the crux, for me. After years of becoming accustomed to the million and one tiny points of attention to detail about the development experience (as opposed to the user experience) that JetBrains are known for, this announcement is fantastic news. XCode is painful by comparison.
masklinn 16y ago
It's not even in beta, it's in EAP.