Possibly hairbrained suggestion (Xcode ReSharper-ish assistant/plugin) Follow
I'm sure you (Jetbrains guys) must have considered this, but it's a thought that cropped up so I thought I'd mention it.
I've been using AppCode for some time, pretty much exclusively (forays into core data modelling and IB aside). Recently I (unusually) started a project in Xcode 5, expecting myself to pop over to AppCode for refactoring and testing, but I found that I preferred to stay within one IDE, even though I prefer (and had become more fluent with) AppCode. Something (attentional switching costs?) acted as a disincentive.
This gave me a bit of insight into the reluctance of many 'Apple ecosystem' devs to even look at AppCode, despite acknowledging its evident superiority for many purposes. Xcode is where these guys live, every day. It's a home, not just one tool amongst others (love or hate it). Most are going to stay there.
But many clearly acknowlege Xcode's weaknesses as an editor and refactorer. I am sure very many would part with good money for an add-on of some kind that would obviate these. A Resharper equivalent might do well. I realise Xcode might not have the necessary hooks available, but a reasonably compact standalone refactoring editor might work: something with AppCode's editing and refactoring features, but which worked well with Xcode as the primary IDE.
I haven't thought this through, and obviously there are a thousand complexities (and Xcode might be a hard partner to work with) but there it is.
Please sign in to leave a comment.
A recent bit of supporting evidence: http://cocoaheads.tv/appcode-lightning-talk-by-rob-napier/
In this video, Rob Napier (of Cocoaphony and iosptl fame) outlines some of AppCode's distinguishing code-editing features. He outlines how clearly superior these are to what Xcode offers. Then he admits that he doesn't live in AppCode daily, offering two main reasons: (1) AppCode, being based on the java platform, doesn't look or feel like a native Mac app, (2) AppCode can't yet do everything (notably Interface Builder and some project management), so you need to use Xcode anyway. He jumps into AppCode a couple of times a week to make use of its particular facilities.
Note the order -- look and feel first! An apparently-trivial concern matters so much to one of the sharpest tacks in the Apple dev world (check out some of his SO contributions). This is a common reaction amongst Apple devs (see also, for example, this Edge Cases podcast). Having only half a foot immersed in the Apple world myself, this has always seemed oddly irrational to me. But I'm coming around, at least to understanding what's going on. Apple stuff appeals in large part on a visceral experience level. Developers are likely to be attracted to it in part because it combines visceral appeal with geek-friendly infrastructure. And devs who want to create ordinary end-user software sever themselves from experiences of ordinary (Apple) users at their peril. This is, I think, why so many Apple devs choose nicely-designed developer tools even over well-functioning command line utilities at times. It's not because they're too thick to read manpages. It's because only people immersed in the Apple-like GUI world are likely to come up with apps that appeal to typical Apple customers.
For these reasons, I don't think Apple devs will use AppCode in droves. Obviously, having no idea how well it's doing right now, I may be entirely mistaken. But I suspect a tool which more readily afforded living in Xcode, while enhancing it with AppCode's superior code intelligence, could do very well indeed.
Not sure I Concur Crispin,
I think Rob's talk and comments about java look and feel only demonstrate that he doesn't know how to change Appcode's view settings. My Appcode looks and feels nothing like a java app after using the darkula theme.
I think a lot of the old school will religiously cling to xcode's look and feel : I've never thought appcode is for those people. People who:
Don't use and don't particularly want tabbed editing,
Are happy to type boilerplate code (I've had many arguments with old-schoolers who feel that typing import statements is important kata.. [which is clearly utter tosh]),
Like coding by clicking there mouses, or using their track-pads constantly.
I sincerely think those guys are just from a different paradigm, where they are happy to work at a much slower pace.. maybe they never experienced the large workshop dev environments that java, c# guys had to, in teams of 50-100 people knocking out code like the world depends on it.. perhaps it's for that reason that they don't quite "get" the benefit's of appcodes finger friendlyness (which is not just in the code editing and refactoring, but for anything one would want to do with it).
As for making a plugin.. I wouldn't bother personally - resharper is a veneer of polish on a turd (visual studio). I wrote to jetbrains personally to tell them so and beg them to do a stand alone app. The difference in experience between appcode, and resharper on visual studio is stark - and it's not for Jetbrain's lack of trying.
Point being : Perhaps they can bring a few things here and there, but xcode is what xcode is.. it's a fischer price toy of an IDE for people in small teams with oodles of time to click around on things to their heart's content. If the result will be similar to resharper then there's simply no point.. polishing a poo (visual studio) or polishing a toy (xcode) still has the same result.. it's just polish and the haters gonna hate any how.
I'd rather their team focus their attention to the people who appreicate appcode - guys from other disciplines who want to write, refactor and test code super quickly, with minimum distraction and maximum coding comfort. I don't believe for one second those are guys in the xcode camp : typing import statements, and rewriting method signatures as kata, is about as far away from my school of thought as you can get.
my 2c.
And to underscore my point about visual studio..
This is the visual studio panel for editing key shortcuts:
Notice you can only see 4 at a time,
Notice it can't be resized,
Worse than this there are millions of collisions with the resharper ones that sotp them working properly,
There is no way to remove the colliding keyboard shortcuts,
And like about 60% of visual studio outside of the editor window, it looks and acts like utter crap.
This is just one example of how the IDE makes for a painful and crappy experience. While xcode is miles better than visual studio in terms of UI; I would expect the same kind of limitations which would cripple an appcode plugin for xcode.
I guess that makes it 4 cents now. Hope you don't mind ;)
@George: thanks for your comments. A very different perspective from mine! Actually there's quite a bit there I don't agree with, but I won't bore our (probably non-existent) audience with the gory details.
One comment though. We're really addressing different issues. You're concerned with the quality of the tool available for "the people who appreicate appcode". Fair enough. I was just raising the suggestion that, from outside of JetBrains, it looks like that group is pretty small, because AppCode is a slighly awkward fit with Apple dev culture. If that's a commercial problem for JetBrains (and obviously I can only guess at the truth or otherwise of that), then they need to address a larger segment of the great majority who do their coding in Xcode.
(Oh, I can't resist one aside -- I use Darkula, and it doesn't even slighly detract from AppCode's very obvious java-ness. That isn't remotely a problem for me: AppCode's my choice of daily IDE for iOS work because of the facilities it offers, and I don't care a jot what framework it's based on. But, I can assure you, the reaction time for a java VS native app discrimination test for an average mac developer/geek would be measured in milliseconds, with 90%+ accuracy).
Your 90% accuracy comment made me lol.
I agree a lenghty discussion is not of interest to all and sundry: however, it may interest you to know that I have a mac mini with 1tb fusion drive and 16gb of ram.. I can honestly say appcode is as fast as xcode in every single possible way and much faster for some things - referring entirely to responsiveness of UI here, not features.
Crispin, George, thanks for sharing your thoughs, we appreciate that.
Our positions on this is that, while it is technically possible to create a plugin for Xcode, our users won't get eny benefit from the plugin: it will take much more time to offer same level of code-insight functionality as AppCode does; it will be hard, if possible, to offer anything beyond coding features (e.g. decent VCS support, test runner support etc.), And, good chancec, the plugin will break with every new version of Xcode (as experience shows).
Also, by improving AppCode UI, we improve all our products as well.
Our ultimate goal is to make progrmammers happy. Yes, we want to make as many of programmers happy as possible, but we don't think that a plugin is a way to go.
(This is our opinion, not the unquestionable truth.)
BTW, Java Swing UI is not inherently slow - it is comparably slower than close-to-platform UI, but not to the extent that can be noticed. The problem, as usual, is in the logic behind the UI that is not always efficient.
We are constantly monitoring performance and making optimizations, but the specific reports are very much welcome.
I tend to agree with the direction you're taking.
I know from past discussions here that you're working to bring more project configuration stuff into AppCode.
I also heard Dmitry Jemerov recently mention something about work on a UI designer for AppCode.
So it looks like in the future AppCode will become less dependent on Xcode for most of the daily
tasks we face. That solves the back-and-forth problem the other way.
I personally like the AppCode UI better anyway, especially the Darcula scheme. Then again, I've been
using IntelliJ IDEA since version 3.x, so I've been thoroughly indoctrinated. ;-)
Thanks for commenting. I'm sure you know your own business best, I was just throwing in some random thoughts that come up in my interactions with the Apple dev community.
Personally, I'm very happy with AppCode as it is. I enjoy working with it, and find myself frequently delighted by many of the details.
Btw, I don't have any problems with AppCode's speed - on my modest setup (current-model Mac Mini) all the interactive stuff that matters (refactoring, navigating etc) is instant, and compile/test is pretty quick. My comment was about how long it takes Apple devs to spot that AppCode is based on Java: milliseconds! For reasons of their own, many dislike any app written in Java almost on principle. I don't share that prejudice.