#Cocoa frameworks in appcode full#
#Cocoa frameworks in appcode code#
#Cocoa frameworks in appcode mac#

You probably don’t want to touch production code with appCode yet. It’s got some bugs (yes, I have filed bug reports) particularly with managing Xcode projects and integrating with the underlying SDKs and tools. Well, that’s not my decision to make, but I definitely wouldn’t recommend using it for production yet. Well, it turns out that in appCode, you can do that: I wanted to change the return type and add a new parameter to an existing method, effectively going from -(void)frobulate: to -(BOOL)frobulate:error. Xcode’s refactoring tools can’t support that, although I want to do it fairly frequently: in fact the last time was this morning.

But what about when you want to change a method signature? Xcode has long had a refactoring capability that only has a little more syntax awareness than sed, and I’ve previously talked about tops as a command-line equivalent. Design your class’s header, then use the Override Methods, Implement Methods and Generate… items in appCode’s Code menu to automatically fill in the boilerplate bits in the implementation.Īnother improvement appCode brings over Xcode is in its refactoring support. This is a great feature for saving a boatload of typing (or even flipping between multiple views with copy and paste). One feature that every other IDE I’ve used has which is missing from Xcode is the ability to automatically stub out methods defined in the class interface (or the superclass interface, or a category, or a protocol…) in the implementation. It’s quite pleasing that in some cases, appCode does indeed come through. I don’t mind (or at least, can deal with) a nonstandard interface if it provides a better experience. Maybe it’s partly because I’ve used so many cross-platform IDEs, but I’ve become inured to the look of the products. As people who know that user experience is the first most important factor of any app, it’s easy to be distracted by an obviously alien user interface. That’s enough to put some of you off, I’m sure. It therefore doesn’t look like a Cocoa app, it looks like this: appCode-though not itself a cross-platform app-is a Java app based on the same framework as IntelliJ. Now, before we get too far into details, let’s get this out of the way. There’s a lot of competition in the Java world for IDEs, so they all have a boatload of features timesaving devices that are missing from Xcode. Now I’ve never used IntelliJ, but I have used Eclipse and NetBeans (and even Xcode!) for Java development, and that’s kindof the point. Unlike Xcode, appCode was written by JetBrains, the company who make the IntelliJ IDEA environment for Java.

#Cocoa frameworks in appcode mac#

Just like Xcode, appCode works with Objective-C projects on Mac and iOS: in fact, under the hood it’s using xcodebuild, llvm and all of the same tools that Xcode uses.

#Cocoa frameworks in appcode full#

It’s been almost a full rotation of this great rock about its axis since JetBrains announced the start of its appCode Early Access Program.ĪppCode is an Integrated Development Environment, just the same as Xcode.