Wednesday, May 25, 2011

Using both Xcode and AppCode on the Mac

I am not a huge fan of Xcode as I find it lacking in a number of areas. You can read my frustrations in various other posts of my blog like http://kevsaidwhat.blogspot.com/2011/04/things-i-dont-like-about-xcode-4.html. I have enjoyed using the JetBrains products in the past for my Java development. JetBrains has an Alpha release of AppCode which is free to download and use for those wishing for something other than Xcode for Objective C on the Mac. I end up using both on nearly a daily basis.

To save me typing XC = Xcode, AC = AppCode and IB = Interface Builder

If XC sucks, and it does, why can't I just switch to AC? Because AC does not have an IB replacement. It is going to fire IB up to do work in that less than optimal tool. It does this automatically for you. If I am doing a lot of IB tweaking or adding new views to my app I use XC so I am in just one tool. If I am doing heavy code development or much of anything with SVN, another area where XC truly blows, I use AC.

Where does AC shine? SVN integration is one place. Where XC can easily get lost if you want to rename a file you have flagged to add to SVN AC handles it just fine. I have had XC screw up SVN so bad I could not even get the SVN command line tools to fix things but AC looked at things and let me fix it with a mouse click.

AC flags a lot more things as warnings in your code than XC. Even if you just used it as a static code analyzer it would be worth the download. It can flag a bit too much at time especially around suspicious memory leaks, but generally it flags real issues. Using the wrong enum in a method call, odd use of objects for static access, unused imports, unused class methods, etc. It will really help you write cleaner code.

You also get real refactoring, not the half-bake attempt in XC. XC can not rename a simple enumeration value, that is plain sad. I have found one instance in AC where it did not complete the refactoring. I was using a static on a class via TheClass.STATIC_VAR but I think it would have done it if I used the longer syntax of [TheClass STATIC_VAR]. As I am learning Objective C I find myself refactoring more and more. I don't want my code to look like Objective C done by a Java coder but to look like Objective C code. I have made a number of mistakes and want to correct them. I also have found inconsistencies in my class naming that I want to clear up. Very easy to do with AC but a manual process in XC.

I did go into the system settings and turn my function keys into actual functions keys instead of dimming my screen and other things I rarely do. AC makes a lot of use of the function keys for shortcuts. Since I am used to what XC uses for shortcuts I wish there was more overlap but I switch back and forth enough it is not a huge issue.

Both AC and XC fire up and shut down quickly enough it is not a big deal to switch between them. I am thinking of dumping IB usage and just creating the layouts in code. Since IB can not help you much when switching between portrait and landscape, an area I want to be friendly in, it is getting to be more of a pain than anything else. I also mistakenly thought I could lay things out in landscape and copy the coordinates into my code to move the controls around but that turned out to be a waste of time making the tool even less usable. Even Apple must have found this all too hard as their calendar app still does not support landscape mode. By default the code generated by XC always tells the OS it is portrait only. Scum. UITables with other controls above and below them must be dealt with in code so IB is not very useful for iOS apps and I will not miss the day I never fire it up again.

I will use XC for memory leak detection, Organizer for screen shots and the like and a few other reasons but the more time I spend in AC the less I even thing of firing up XC to do anything. I would be nice if JetBrains could completely replace XC and IB but that would take a lot of development effort and for now I am very happy to have something to use instead of XC that is much more developer friendly. Nice going JetBrains!

AC is alpha, I have had it crash a couple of times. XC crashed on me more than once too. I have not had it ruin any code or lose anything in SVN. XC does get lost in SVN which is not acceptable for a 4.x product. AC is using the very solid code base from their other language products and it shows. I am not associated to JetBrains in any manner. I have written a free plug-in for IntelliJ for verification of MigLayouts but I don't make any money from that product. Give AC a shot if you get a chance and let me know if I am totally off my rocker on this one.

* Update * You can run the memory leak test and other profile activities just fine from within AC. I have had it crash when I make project level changes AC, use XC then come back to AC (fully shutting each down) but it seems to recover just fine. I do wish AC had the 3 finger swipe to switch between M and H files.

No comments:

Post a Comment