appcode FUD - how do to deal with it
Hi guys,
I'm active on #iphonedev on freenode. Often noobs are there complaining about xcode's limitations, (especially with code completion, crshing, lack of features) and I always send them to this link: http://codesheriff.blogspot.com/2012/02/xcode-vs-appcode.html.
What then usually follows is a load of FUD like swipes from the old guard - who have Helsiniki syndrome and for some reason think the only possible answer to xcode's limitations is to file radar bugs, and wait for apple to magically make a better IDE (which, judging by the latest beta release 4.5, seems is not on their list of priorities at all).
I have no problem countering those arguments.
They also say "well you still need to use xcode for interface builder". I always respond that it's not a drag for me in the slightest, though I must admit.. I imagine if you guys made a storyboard editor, it would also kick ass, well over and beyond xcode's IB. Are there any plans for that up the road (like in 2.0)?
Many time's though, they talk about the fact appcode is outside of apple's control, and can have compatability problems, etc.
I generally answer saying the same is true for using text mate, which some of them revere, and that I've never had problems and that you guys release FAR more frequently than xcode does.
I'm wondering if you guys have any contact with apple, or have had any kind of acknoweldgement from them about what you're doing. I would presume, if anything, Apple love what you guys are doing as you bring more people into their tent, and make them more productive.
Do you have anything to add to this discussion? As I'd like to really meet that particular bit of FUD head on.
I'm a very active evangelist for you guys, and I'd appreciate any help you have at all to help me keep spreading the word.
Please sign in to leave a comment.
I developed several apps for different companies and none of my apps contains a nib file, not even for the window and I never used the interface builder ;), so this is not a valid argument for me.
I still use xcode to edit project settings and stuff like build rules and scripts, and I'm still evaluating appcode but I really like some of the refactor shortcuts and the code completion of blocks. I'm also pycharm and phpstorm owner and I like the editor and interface so that's also a plus for me.
I'd suggest to anyone to evaluate appcode to see if they like it.
Thank you, George,
it is very inspiring to have such a feedback and we are glad to have you on our side! :)
Well, we are planning to make a story-board editor in one of the next major versions, probably not in 2.0, though, since there are lots of other cool stuff to implement.
In the comming update we hope to add build settings and Core Data editors, as well as C++11 support and lots of other small things that will make AppCode even more pleasant to use. We'll soon pubilsh a road map for the comming 1.6 update in our blog.
As for the Apple support, no, we don't have any direct communication with them, but it is obvious that they keep their eyes open on AppCode ;). We simply try to support all the new stuff they announce as quickly as possible and always test AppCode with all announced OS and Xcode versions; so you can be sure, if they announce new Xcode or OS, we'll provide stable support in the official AppCode update shortly - even for early Developer Previews.
We have recently opened the 'Tip and Tricks' section in our blog, that can help new users get an idea of the power AppCode has - it is based on a mature and proved 10-years old IntelliJ IDEA platform, as well as our other products, and has lots for features to discover (VCS integration, Navigation, Code editing, Analysis etc). So you can direct the guys to http://blog.jetbrains.com/objc/.
There is also a discussion in the forum with the feedback from our users - and thank you very much, for writing it - that you can share with your colleagues and friends to persuade them to try AppCode: http://devnet.jetbrains.net/message/5461663#5461663.
We are planning to attend OS X/iOS-related conferences where we can promote AppCode. So, if you know such conferences, let us know, maybe we'll manage to have a booth there.
Develop with Pleasure!
-The AppCode Team
It seems to me that longtime Apple developers are generally rather conservative. They're used to having the main parts of their toolchain being provided by Apple, and don't feel secure stepping outside of that. I've come across *very* experienced devs complaining bitterly about Xcode, but who aren't willing to even try another IDE. I suspect people newish to the Apple dev scene are likely to be more open to AppCode. This isn't so bad, as there are a *lot* of developers experienced on other platforms trying out Mac/iOS development.
One thing worth emphasising is JetBrains' responsiveness. YouTrack is a wonderful thing, and isn't to be compared with bland, anonymous, and indifferent process involved with 'filing radars'. I know of at least one dev who tried, and then bought, AppCode after seeing some YouTrack issues, and just how great the JetBrains guys are at communicating with their users.
Just leave them be, and run circles around them in development speed.
That's all you can do.
Recently talked with some old hands who do everything in Emacs. It works for them, hey, why not. AppCode works for me. Defenders of XCode puzzle me, as it's a wannabe IDE which is really just a glorified text editor. The biggest improvement it has seen where in the backend with Clang.
Every time I accidentally start to write even a small snippet of code in XCode - because it's open,and I am using it for IB and also for git integration - I am reminded of how awful XCode really is. AppCode just works, it now does nearly everything I need it to do, it's super fast, efficient, nice.
So I use XCode for:
- git checkins
- IB
And AppCode for everything else.
The only thing I can criticize in AppCode is the git (SCM/VCS) integration. This blows in comparison to Eclipse, and also XCode. The functionality is all there, but the workflow is tedious in AppCode. I think XCode really does it the nicest, if they had a nice and easy shortcut to simply visit ALL changes in ALL files one after another it would be perfect. In AppCode there's an extra step to see what has changed in the source, and it's a mess. I never want to check in blindly, I always double-check.
Anyway AppCode saves me hours ever day,thank you guys. I don't think it's a big deal at all to have to switch back and forth between AppCode and XCode for IB - it's two windows, so what? I don't need AppCode to integrate IB - it would undoubtedly cause problems with XCode and IB is best used lightly anwyay - it's good for visual layouts, but even Apple hasn't figured out how to make it really efficient. In my mind IB is best used to avoid having to write lots of CGRectMake(x,y,w,h) statements and to be able to change the basic layout easily. Storyboard was a neat idea, but I ended up regretting using it - it doesn't actually save on development time as you inevitably hit spots where point and click is insufficient and then Storyboard creates additional complications that make it not worth your while.
Hi,
Do you mean that where Xcode shows all changes in one pane, you have to visit every file in AppCode and look for changes file-by-file to include them into commit or not? I also do not commit blindly and AppCode always shows me all information I need.
I'm asking because I'm the opposite. I can't use Xcode Git integration and I love how AppCode does it. May be it's because I don't know how to use it effectively in Xcode?
Out of interest, what's the git integration problem? The VCS->Check In Project dialogue (bound to a key), with the 'details' section expanded, seems to show most of what's required (for my modest needs, anyway).
Entirely agree. I do still code in Xcode from time to time, just to keep in touch with it, and I find it incredibly painful to have to so much manually.
Well in XCode there's a filter for "Show only files with source control status" - that already allows me to find groups of files for committing. I then select those files that belong together in one commit and do right-click to commit, which pulls up the view with the changes.
I flip through the changes per keyboard shortcut, and, crucially I am allowed to modify my changes, then commit.
In AppCode - I don't know how to do it to be honest. I can commit a directory, but there's no way to only commmit some of the files, so it's useless.
F7 for next difference doesn't work so I have to scroll through manually. I am not sure if there's away to only show modified files - I don't mean to color modified files, but to just not show any unmodified files at all, like XCode does.
I can also hunt for single files to commit... doesnt make sense. How do I find groups of files that belong in one commit, and then commit those?
Eclipse Synchronize view is even better - it shows only modified files, but optionally shows both incoming and outgoing, and it allows one to select groups and check in a group with a single commit. So far same as XCode, but Eclipse also has that crucial function, the GLOBAL "show me the next difference" button / shortcut so I can just flip through all changes quickly. In XCode, the show the next change only works in the currently selected file which means I have to select files one by one in the commit pane.
Eclipse also allows one to edit files prior to commit, and even to exchange the currently selected difference with the server version, undoing the current difference without reverting the whole file. That's great to remove debugging code prior to commit. XCode doesn't have this, you can modify, but have to delete debugging code manually, and revert changes by copy/pasting them from the server version. Not quite as good.
I am wary of AppCode also because my ex colleague was spending inordinate amounts of time on more complex merging operations in IntelliJ - I could do those same operations in Eclipse in a fraction of the time, thanks to the very clear, simple, and efficient Synchronize view.
So in short I am missing those features in AppCode:
- A way to only see modified files - a synchronize view like in Eclipse would be best. Maybe it's there and I just didn't find it??
- A way to pick groups of files from the modified files for a single commit (ties into the first one)
- A way to flip through all changes in all selected files per keyboard shortcut (BTW I tried the next difference arrow, also doesn't work, so I don't know if this is a global or file-local next difference button. To me it's a do nothing button right now ;))
- A way to modify my files in the commit view, for those last minute changes
- A way to revert single differences without reverting the whole file.
Ok, let's discuss it a little. :) I hope we'll help each other to find out new usage patterns.
Thanks for the filter, didn't know it existed. It is useful, yes.
Well, in AppCode (and Idea) you can see changes in two places: Commit dialog (I use Cmd+K shortcut but there is a menu item: VCS -> Commit Changes) and Changes tool window (Cmd+9 or View -> Tool Windows -> Changes).
Changes tool window allows you to see all changed files. They can be added, removed to the project, staged or not (in terms of Git). You can also have several changelists (something like stashes in Git, but you can see and modify all of them simultaneously). Also there is a Log tab with nice history view.
I want to mention, here are all changes made to the project. Whether they are in VCS or not.
I believe that that is similar to Xcode filter thing.
You can select multiple files there, look at their changes, there are several useful options there.
On the contrary commit dialog shows only changes that will go to VCS. So for example non-staged files wouldn't get there.
Oh, I see. Try this. When in Changes tool window or in Commit dialog, select first file and press "Cmd+D". First of all, te dialog that appeared, allows current file editing. Secondly it has several useful options (for example ignore whitespace-only changes). And, at last, it has Ctrl+Arrows shortcut to go to the next file and F7/Shift+F7 shortcuts to move between changes in current file. It also has standard AppCode gutter to overview all changes made in the file.
In compare view — you can click on icons between versions to apply/remove them. In editor view — click on the green/blue colored stripe to the left from the code, you'll be surprised :)
I tried to answer all questions. Did I miss anything?
You beat me to it. Nice summary. A combination of the Changes tool window with commit and file-diff dialogues is really very functional.
Nikolaus,
we are glad to hear that you get such a productivity boost with AppCode and happy to help you being even more productive!
As Alexander's already pointed - thank for help! - there are many ways to view and work with the versioned files. And we beleive that VCS integration in AppCode is much more powerful and versatile than that in Xcode and we are ready to answer any question you have regarding it.
Cheers!
Oh - Changes Tool. Yeah that's what I was looking for - cool. I guess I am nitpicking now but I need the local file on the left, the repo version on the right, and no line numbers (does any programmer care about line numbers??). I put the Changes View to the left & extended it all the way, with details enabled it's almost like eclipse Synchronize workspace.
The Diff view is more flexible than I thought too, that's cool. Huge step forward, still lacks the clarity of the XCode checkin window. I guess I just dislike separate windows opening. Moving from file to file is an advantage. The shift F7 shortcut - not useful on a MacBook Pro but can be changed easily so no big deal. I've asked for a default MacBook keyboard shortcut layout but so far haven't heard anything. The thing is, iOS developers are on Macs, and most Macs have system functions overlaid on the F-keys...
Anyway thanks for the help, at least I know how how it works in AppCode :)
Very cool, I had not seen this yet. That's awesome! :)
Nikolaus,
what line number do you reference? In the Diff dialog, for instance, line numbers are really important, especially, when you compare the current version with some version in the history.
As for the shortcuts, you can set the Xcode keymap and you can find the default shortcuts list in Help->Default Keymap Reference. Anyway, it is not a big deal to disable Fn keys if you strive for the efficiency.
By the way, you can detach the tool windows and resize them for your taste. You can also save the preferred layout and it will be used for the new projects (Window->Save Current Layout as Default).
Regards,
Anton Makeev
That's just a default. You can set the top key row to act as function keys without needing the fn modifier in System Prefs -> Keyboard.
The following is my humble opinions :)
I strongly suggest that AppCode refrains from trying to be the next XCode but instead focus on its core strength on its intelligent code editing and navigation platform. Not that Jetbrains does not have the talent to create the next Xcode, it just that becoming the next Xcode is not sustainable and perhaps generate more disappointment in the future as developers continue to compare Xcode with Appcode. As Apple continues to innovate on XCode, AppCode can only play catchup. It is much better strategy that AppCode is seen as a complementary development platform rather than as competing rival to Xcode. Yes, there could be some features overlap between the two product but there are some major capabilities that should be exclusive to Xcode, and one of them is the interface builder. It seems to be waste of time and effort if AppCode trying to build its own IB which in my opinion will be hard to compete with that of XCode, after all, Apple set the future direction for its technologies. The time, money and effort are better off channel to improve AppCode rather than build the complex UI layout mechanism. There are something that AppCode can do well that perhaps Xcode will never able to match due to Apple's focus, that is the code editing. XCode4 does not even hold a candle to AppCode in term of Code formatting (anyone try incredible Code Reformatting) and perhaps never will. I basically use Xcode for IB in layout and simple code touchup in code editor, and the actual code development done in AppCode. AppCode better off focus on what it does best.
These are areas worth considering
- Auto import header file (much like what Intellij done for java)
- UML ? class diagram
- refactoring tools
- code documentation
- visualizing diagram of controller, view, model to help understand and document application;
etc
:}
I agree with differentiating the IDE based on developer productivity (which apple will never match in my opinion and wholly justifies the purchase of my appcode license)... But I didn't get your points here:
- Auto import header file (much like what Intellij done for java)
It already does this..
- UML ? class diagram
I think they're going to do this.
- refactoring tools
It already does this
- code documentation
- visualizing diagram of controller, view, model to help understand and document application;
Isn't this what you're saying they should not do? that's interface builder, surely?
Regards,
George
Hi, George,
with as the argument, then use with your data source object as the argument. If you use before , throws an exception.I believe that Intellij can do more to improve its features.
- Auto import header file as in fixing/notifying issue ... Notify if user attempt to use header file and class but yet did not attach the library yet. (eg for example, warning using Webkit classes while its library is not attached yet to the project)
- UML tools , yes I heard they are doing it.
- Refactor tools - I'm sure this area can see much more improvement.
- Code documentation -> I thinking if Jetbrains could come up a better way for user to assist in documenting the application internal working (for example, user can easily a "special" document editor in Appcode to describe how the application work with reference to the code. User can dragNdrop classes & method from the project pane to extract their name to add into the documentation.
Like this type of documentation:
"To specify that combo box uses an external data source, first use
The data source must define these methods. The method logs a warning if its argument doesn’t implement them."
- visualizing diagram of controller, view, model to help understand and document application;
It is not IB or any layout feature, but rather a graphical "UML-like" diagram to depict the relationship of all NIB file, controllers, models, and views in a bird-eye view for the whole application for easy navigation and documentation. This will also help to understand the whole flow of the application.
- More intelligent detection of issues (like KVC path issue related to code) etc ...
- Consolidate NIB properties and settings in a "bird-eye view" detail screen to faciliate troubleshooting (right now Xcode use a series of inspector panel to do that which require more clicking).
hope that helps :}
Guys, we appreciate your suggestions and ideas, and it would be great if you file them in our tracker: http://youtrack.jetbrains.net/issues/OC#newissue=yes.
Once filed, they will not be lost and we will gain the feedback and opinions.
Cheers,
Anton Makeev
Just found this thread and .... THANK YOU! Wow. Very nice explanation. Like Nikolaus I wasn't a fan of the VCS integration in the IDEA-based tools (in my case for Hg). Very used to the Eclipse sync view for my day-job Java development and Source Tree from Atlassian for my personal development stuff. I will take a better look now.
Thanks again!
> In the Diff dialog, for instance, line numbers are really important, especially, when you compare the current version with some version in the history.
Not on my planet. In over 10 years of coding and using SCM systems, I've never needed, or wanted, line numbers.
They're just more clutter on the screen. A visual compare tool obviates the need for line numbers IMO.
I still think the way Eclipse does it is by far the best. As much as IntelliJ is better in nearly all regards when it comes to user interface and user friendliness, the Team / Syncronize view in Eclipse is unrivaled. I use it even for projects where I don't use Eclipse for coding. It's much better than any desktop SCM client (Tortoise SVN and so on).
XCode has a nice visual style - it makes it very clear, and very obvious, what's going on. But some features missing and don't even try to do anything more complicated than comparing the current with the latest.
I just find AppCode confusing. I'd probably learn it and get used to it, but since XCode does it reasonably well there's kind of no need to ;)
Huh. I always have line numbers turned on (in SCM views or otherwise). Inevitably I need to communicate something to someone and I can just say look at line <whatever> in file <whatever>. Have always had them on in any editor I've ever used in 25 years of programming. Just goes to show that everyone is different ;)
Nikolaus,
does presence of line numbers make AppCode's VCS support confusing, or there is something else we can improve, in your opinion?