AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features

Hi everyone,

With summer right here, we couldn’t wait any longer. The Early Access Program for AppCode 3.2 has launched!

It’s been six months since we released AppCode 3.1, which was mostly dedicated to Swift. Our top priority hasn’t changed, but there are quite a few other things on the plate, too! Read on to learn what’s inside AppCode 3.2 EAP and download the first build from our confluence page.

Mixing languages

We delivered basic Swift support in June 2014, soon after WWDC 2014. We then took a big step forward in October 2014 with AppCode 3.1 EAP, offering deeper Swift support. Since v3.1, AppCode supports resolving Swift symbols in Objective-C code. We’ve grown up and can now resolve in the opposite direction, too: Objective-C symbols in Swift code.

What does that mean from a practical point of view? Benefit from code completion, navigation, Find Usages and Rename refactoring now throughout your whole codebase, no matter what programming language you are using: Objective-C, Swift, C or C++. Some limitations and issues are still there, we’ll share them below and continue our work in that direction in the next EAP builds.

As far as Objective-C symbols are now resolved in Swift code, completion for Objective-C code in Swift is available and shows the corresponding Swift type:

Go to declaration (⌘B) / definitions (⌥⌘B) as usual jumps to the symbol declaration/definition for all mixed cases (Objective-C symbols in Swift, and vice versa), while Find Usages (⌥F7) lists all usages of the current symbol. However, Find Usages for Swift methods used in Objective-C code is not ready yet.

The Rename refactoring automatically corrects all references in the code for you, even those found in comments, strings and non-code files:
Feel free to rename Objective-C or Swift classes, no matter where you use them. As for methods, Objective-C methods used in Swift rename invokes change signature refactoring, while Swift methods in Objective-C code rename is still in development.

In case you feel lost in main Swift features supported in this AppCode EAP, check this table. It gives a short list of main features like Completion, Find Usages, Rename refactoring and some navigation features as applied to Swift and mixed Objective-C and Swift code.

Interpolation of Swift strings

String interpolation is a nice feature that is used to combine strings in Swift. AppCode now highlights the symbols used in such strings and helps you complete symbol names:
And of course, when you Rename, all symbol usages will be corrected automatically by AppCode for you.

Navigation in Swift

The left-hand gutter can be very helpful while navigating through the code. If a function overrides / implements or is overridden / implemented by some function, it is marked with an icon in the editor gutter:
Previously this worked in Objective-C, C and C++ code, and is now available in Swift. From now on, navigate to the derived class more easily:
This also works while navigating from Swift to Objective-C super/inherited methods and classes.

Show usages for the declaration

As you know, navigating to the declaration/definition is easy with AppCode. You just use special icons in the left-hand gutter to jump to the declaration of a symbol (⌘B) or its definition (⌥⌘B). And now, if standing on a declaration, Go to declaration serves as Show usages:

VCS improvements

Sometimes the default side-by-side diff view is not very easy to use. The more compact one-side view is here to help, showing the difference between revisions on one page:
If you switch between files, the viewer remembers your caret position in the file.

The Log viewer for Git and Mercurial now can filter by repository. For better clarity, each repository is indicated with its own color. Commits by the current user are now highlighted.

Synchronous HTML tag editing

If you need to edit HTML and XML code in AppCode, this new feature makes it easier. Edit any tag in your code, and AppCode will fix the corresponding opening/closing tag for you. It’s on by default, but can be switched off in Preferences/Settings | Editor | General | Smart Keys. Watch this small demo to see how this works.

Distraction-free mode

If you prefer minimalism, a brand-new Distraction-Free mode is now available in AppCode. Toolbars, tool windows and editor tabs are all hidden, the code is center-aligned on your screen, and now nothing prevents you from pure coding. To turn it on, click View | Enter Distraction Free Mode.

Other notable changes

A long list of fixes and improvements can be found in our tracker. Here are a few worth mentioning:

  • The File Structure view in Swift now has an option to show inherited members.
  • The performance of Swift editor has improved greatly. If you are developing in Swift regularly, please check it and report any problems you may find.
  • We’ve also fixed the problem with build locations – AppCode now respects the output directories hierarchy specified in the target build settings (some more changes are on the way).
  • Thanks to CLion, our newest member in the IntelliJ-based family of IDEs, many goodies for C and C++ code borrowed from CLion are included in AppCode as well.

UI Designer moved into plugin

As you probably know, AppCode has had its own built-in UI Designer since v3.0. We’ve put quite a lot of effort in it. However, because of our focus on supporting Swift language, we are currently unable to give UI Designer features the attention they deserve. We understand that you are missing many important features such as support for Xcode 6 universal storyboard format. We’ve decided to set the default UI tool to Xcode’s Interface Builder, and to make our UI Designer an optional plugin instead, which you can install from our plugin repository. From now on, when the plugin is not installed, .xib and .storyboard files are automatically opened in Xcode, while AppCode provides you the xml representation. If you would like to open these files in UI Designer by default, install the plugin, and AppCode will behave the same way as it does in v3.1.
Our plans for the UI Designer plugin are undecided. We will be focusing primarily on Swift, smart editor support, refactorings and other features that make AppCode unique to our users. We may prioritize UI Designer in the future, but cannot promise anything concrete. Thanks for your understanding and continued support of AppCode.

OS X and Xcode supported versions

One more important thing to mention here – the supported OS X/Xcode versions have changed a bit. For OS X 10.9 use Xcode 6.2 in AppCode, and for OS X 10.10, please, select Xcode 6.3+.

Build with custom JDK

You probably know that we do recommend Apple JDK 1.6 because of the critical issues with JDK 1.7 and JDK 1.8. But with the update to OS X 10.10, users have noticed a very annoying graphics glitches. Recently we’ve started our work on a custom build of JDK 1.8 with fixes by the JetBrains team. Finally we have a new distribution package targeting those OS X Yosemite users who experience graphical glitches with Apple JDK! If you’re already used to JDK 1.8, you can try this as well. Some font anti-aliasing problems have been addressed there. Please note this non-default option may contain some issues and performance problems. As this is still a work in progress, we – as always – greatly appreciate your feedback, comments and issue reports here.

This is just the beginning for AppCode 3.2, and we’ve got lots more interesting features coming! Check this EAP build, follow the updates and report any problems found to our tracker. Your feedback is more than welcome!

P.S. In line with our code-naming tradition, this version is code-named Tascalate. Tascalate is a Mexican drink made from a mixture of chocolate, ground pine nuts, achiote, vanilla and sugar. How do you feel about this one? On the practical side, it’s another tag in our blog to find information on specific AppCode versions: Just search for Tascalate to find posts about v3.2.

Develop with pleasure,
The AppCode Team

This entry was posted in Announcement, Early Access Preview and tagged , . Bookmark the permalink.

66 Responses to AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features

  1. Tomas says:

    How is it with support nullable/nonnull for Objective-C in EAP? In latest stable build it breaks auto completion.

  2. Pingback: AppCode 3.2 доступна для загрузки в рамках программы раннего доступа | Cocoa Developers Club

  3. Raphael says:

    Thanks for the EAP!
    Actually the IDE runs very slow. It takes pretty long until the auto complete dialog pops up. And even writing code lags.. The 3.1 release runs fine.
    Do you have an idea what I can do?

    Thank you!

    • Anastasia Kazakova says:

      Is it Swift or Objective-C code? Are you trying build with default JDK or our custom one?

    • Matt says:

      After trying both yesterday and today, the version without the bundled JDK 1.8 seems to run faster than the one with. Which are you running?

      • Anastasia Kazakova says:

        Actually we are currently aware of some performance problems with custom JDK and working on them now. They are not stably reproducible in every environment, but looks like you are among those who met them. Will try to update the JDK with the next EAP build.

        • Matt says:

          I’m actually seeing faster response times with 3.2 (without bundled JDK) over 3.1, I think because more stuff is parallelized. With 3.1 AppCode would only max out a single thread, but now it seems to be using more than one thread for doing work. Good job!

          • Bill A says:

            Agreed – I switched from the custom JDK to the non-bundled DMG and AppCode is significantly more responsive.

  4. Petr says:

    Hooray! Jetbrains, I love you! :)

  5. Bill A says:

    Great to hear. According to the announcement, I thought that AppCode would be able to resolve my Swift symbols in Objective-C code. However, all references to project Swift symbols in my Objective-C code are underlined red, and AppCode appears to be unable to find the auto generated “Project-Swift.h” header.

    Here are the problems I ran into:

    • Anastasia Kazakova says:

      There are some issues like and Could you try to clean and re-build the project? Will it help?

      • Bill A says:

        I did try that. I tried clearing the caches and restarting. Unfortunately, no luck.

        I can reproduce with a new project, too:

        1. Create an Objective-C project in Xcode.
        2. Create a Swift class called “MyClass” that inherits from NSObject and has at least one property.
        3. Create an Objective-C class that imports “ProjectName-Swift.h” and have one of its methods create an instance of MyClass and access a property on this instance.
        4. Compile successfully in Xcode and confirm that there are no warnings or errors.
        5. Open in AppCode.
        6. The “MyClass” symbol as well as the property symbol will highlight red and won’t resolve. Cmd-clicking into “ProjectName-Swift.h” will take you to an empty file.

        • Bill A says:

          Whoa, I got it to work! The problem is that I was importing “ProjectName-Swift.h” instead of . Although this works in Xcode, it doesn’t in AppCode. I will file a bug for this specific issue, but after making this change, cleaning the project, invalidating caches, restarting and rebuilding, Objective C-to-Swift resolution looks like it’s finally working.

          This is great!

  6. Antoni says:

    Great to see a progress :)
    There are though some issues that would be great if addressed, as AppCode experience with Swift is still very sub-par compared with ObjC:

    – autocomplete for ObjC classes (or ObjC derived classes) shows suggestions sorted alphabetically, with flattened hierarchy. For ObjC AppCode works much smarter, suggesting methods from top level class first – which of course makes much more sense. In general AppCode (and other IntelliJ) products have very smart ways of sorting suggestions, which is completely missing in this case

    Would be also great if user defined functions would get more priority over build in functions and constructs – currently when I press Cmd-Space in a new line I just get a lots of gibberish

    – AppCode will suggest non-static methods and properties when used in static context (eg. UIView. will show all possible methods and properties, not only class methods)

    – there’s no easy way to determine a type of variable/constant. Eg. I write let x = functionX() – I can only click on functionX to go to it’s definition. (In XCode you get this information from “Quick Help”)
    Some ideas – add a shortcut that would display some popup / mouse over popup / some smart way to show inline (something like you do with debugging) derived type

    – I type in UIView.animate – AppCode shows me different methods to choose from. I choose duration, animation – but I only get UIView.animateWithDuration()
    Then I can press Cmd+P and see again all different possibilities, but no real support with filling in parameters. No support to auto declare a closure (adding animations in ObjC is a breeze with AppCode, 2 keystrokes and I have the method call and block ready)

    – compilation errors are still not displayed in editor (I need to build a project, and check them from messages view, even after compilations I don’t see problems in editor)

    – as code is not checked in real time in any way, of course all nice features like create missing method etc. are not available as well

    – implement/override still not working

    Probably there are more issues, it’s just a quick list of things I’ve checked for.
    Please AppCode, make it at least not worse than XCode 😉

    • Anastasia Kazakova says:

      Thank you for the detailed feedback.

      – implement/override still not working
      Is not yet implemented: We’ll announce for sure, when it’s done.

      – compilation errors are still not displayed in editor (I need to build a project, and check them from messages view, even after compilations I don’t see problems in editor)
      – as code is not checked in real time in any way, of course all nice features like create missing method etc. are not available as well
      We haven’t yet worked on this. There is some top level ticket you can find here:

      – compilation errors are still not displayed in editor (I need to build a project, and check them from messages view, even after compilations I don’t see problems in editor)
      – as code is not checked in real time in any way, of course all nice features like create missing method etc. are not available as well
      Yes, it will come later with inspections and intention actions for Swift:

      – there’s no easy way to determine a type of variable/constant.
      It’s actually a part of Quick Documentation feature, not implemented for Swift yet –

      AppCode now shows the parameter info, as you’ve noticed. I suppose the assistance you mean here is parameter placeholders:

      We also have plans for code generation in Swift: And completion sorting in Swift is here:

      We’ll do our best to cover as much as we can before the 3.2 release, but the resources are limited, so sorry in advance if we won’t be able to get smth ready before it.

      • Antoni says:

        Btw. when we are talking about bugs/changes, some issues from previous versions of AppCode :

        – when I have in a method for example [super viewDidLoad], clicking on it will show me a popup with all possible implementations of viewDidLoad in the app – but AppCode knows exactly which one it should be, as there’s this small blue arrow next to method name that works properly

        – I have a declaration: __weak __typeof(self) weakSelf = self; AppCode will treat weakSelf as id type and is not able to give any suggestions

        – .xcassets with subfolders will display nothing when expanded (and still Universal 3x is treated as some wrong entry)

        Feature that would be really cool to have:
        – some way to mark my own methods to be treated in similar way as some special methods from Cocoa. For example, lets say I have method – showImageNamed:(NSString *) imageName – I’d love to mark it (it would probably need to be saved in some metadata) so that AppCode would suggest me image names in the same way it does for “UIImage imageNamed:”

        Same would be nice for target: selector: pair etc.

  7. Barney says:

    “We’ll do our best to cover as much as we can before the 3.2 release, but the resources are limited…”

    I hope you get more resources because AppCode was, and is close to again being, a wonderful product. But it’s clear you guys are short on resources. It’s taken a full year to get this far, and while a lot of fantastic progress has been made, essential functionality is still missing (like seeing errors in-line as you type). Apple will undoubtedly announce lots of new Swift and Xcode features on Monday, so it seems like it’s going to be difficult for you to catch up, given the current pace. I’m also worried that lots of people are not going to upgrade AppCode this year due to these problems, and I really hope JetBrains does not see a decline in AppCode profits and decide to reduce investment. I hope you guys get more resources in order to continue and advance beyond the brilliant work you have done so far.

    • Terence says:

      Agreed. I am starting to regret this years renewal. I am yearning to use AppCode as it makes iOS development so much better. But since I have switched to Swift development I find myself spending more and more time back in Xcode.

      Can’t wait for the updates so I can escape Xcode again! Please keep pushing forwards as I know myself and many other developers think you do an outstanding job!

      • Anastasia Kazakova says:

        Thanks for you support! Your words inspire us for more.

      • Raphael says:

        Same here! Could have been my words Terence and Barney.

        I really wish that AppCode becomes as good for Swift as it was for Objective-C!

        • Frank says:

          I second this, as both a Java and iOS engineer I spend all day in both IntelliJ and AppCode. Switching back to xcode for swift support sounds like a nightmare.

          • Tony M says:

            Unfortunately I’d have to agree. I understand that trying to support Swift in its infancy is tough but you have a product that people are buying and renewing. You guys need more resources. Period. I don’t regret my renewal mostly because I support Jetbrains but also because I’m curious to see how AppCode as a product can evolve. For me AppCode is unusable. So for now, I’ll keep working in Xcode and open AppCode once a day to see if by miracle you guys have resolved my swift issues and not blundered resources building stupid Storyboard Editors. Sorry I’m a bit passive aggressive 😉

          • Anastasia Kazakova says:

            What are the most annoying issues preventing you from using AppCode?

      • Craig says:

        I love AppCode and I have faith that given continuing resources, it will evolve to be as powerful with Swift as everyone expects from JetBrains. It’s fantastic with Objective-C, and I can’t wait until it catches up with Swift.

        It offers a lot of functionality that I frankly never expect to see from Xcode, and I’m happy to renew every year to help ensure it can get there – even if I can’t use it as much as I’d like in the meantime for Swift work.

    • Antoni says:

      Well, let’s hope that with Swift being OpenSource, it will get some more love and attention from JetBrains :)

  8. Pingback: AppCode starts 3.2 EAP with hot mix of Swift support improvements and new platform features | Dinesh Ram Kali.

  9. Soulstorm says:

    Great to see a new update in the works.

    However, even with this update, as with AppCode 3.1, it seems that AppCode is incapable of autocompleting / regognizing code installed with cocoapods, even in the simplest of Swift projects. I was hoping that this problem would be resolved by now in this build.


    Create a single-view iOS Swift project, then use the following Podfile

    platform :ios, '8.0'

    pod 'Alamofire'

    Open the .xcworkspace . Go to any file, import Alamofire, and notice that whatever method you call, Appcode cannot autocomplete or recognise it. Even command-clicking on the ‘import’ doesn’t work. Native frameworks (like Core Data) work.

    Xcode works flawlessly in this respect, which makes me think it’s probably a problem with AppCode. It’s really a showstopper for me, and the only reason I switched over to Xcode when developing for Swift.

    For Objective C, however, I don’t even open Xcode anymore, I use AppCode.

    Keep up the good work!

  10. Alex says:

    As an avid and long time user of JetBrains product (intellij), I am a little bit disappointed in the direction taken by appcode team in regards to the ui builder. Yes, I am a beginner in iOS development, and yes, I start my journey with swift.
    I understand that experienced user probably won’t do interface design in story board, but that’s a different problem.
    Maybe once I have enough experience with iOS Dev, I won’t need storyboard anymore, and do ui Dev purely in code. But that will take a long time – and by that time, I might be too ‘attached’ to xcode. Anyway, that’s my 2c. For now, with deepest regret, I am sticking to xcode.

    • Anastasia Kazakova says:

      We are sorry to disappoint you. But how about using AppCode for code editing, generation, refactoring and switching to Xcode for IB? Does this look acceptable for you? You’ll need Xcode for some other tasks as well, like uploading the app to App Store, etc.

      • Alex says:


        Thanks for your prompt response. Unfortunately no. That would be counter productive. Editing UI happens a lot, especially for one man team. Using xcode just for uploading to iTunes connect is fine. But for UI dev ?Constant switching between different apps is just inefficient.



      • Raphael says:

        Actually I like the idea of focussing on code editing only in AppCode. Apple does a great job at Interface Builder but sucks at the editor. I think it would be a waste of time building a separate Interface Builder when there is a good one.

        You have to switch to Xcode anyway when it comes to compiler settings and all that stuff.. so I think switching to Xcode is OK for editing storyboards.

        I would rather see the team focussing on Swift support! 😉

        • Juraj says:

          I absolutely agree with Raphael that Apple does a great job at IB but their ObjC / Swift editor is only better notepad :) Focussing on alternative UI designer is wasting of time and resources.

          I have done just about 10 apps with Xcode+AppCode but switching between them was never counter productive for me. Moreover when sync between changes in Xcode and AppCode was always flawless (how do you do it, Anastasia :-)

          Swift support in AppCode, comparable with ObjC, is the only reason why I’m still waiting with renewal.

          Thanks for outstanding work, JetBrains!

        • Frank says:

          I agree as well, I appreciate the effort your team put into building IB into AppCode but I found myself editing storyboards/nibs in Xcode. As long as code to storyboard refactoring still works from AppCode I’m totally ok with switching to Xcode for IB

      • Stewart says:

        I always thought adding UI builder to AppCode was a bad idea.
        Its a moving target and changes regularly. IMO AppCode should be about coding – this is where AppCode excels. Leave the UI Builder to XCode.

        UI Builder is a resource sink. JetBrains are better off focusing on Coding aspect.

        AppCode is falling behind – its extremely disappointing to see – 1 year later and still poor support for Swift.

        I suppose CLion didn’t help AppCode – I got the impression resources were pulled on to CLion from AppCode.

        • Thomas Condon says:

          I completely agree with Stewart. With all that is being introduced at WWDC, Keeping AppCode’s focus on coding make the most sense to me.

        • Antoni says:

          What I think would be the best solution (but I’m not sure if it’s even possible) is if AppCode was a plugin to XCode (in same way as Resharper works with VisualStudio), instead of separate product (or best if it was both) – but I guess it’s not possible :(

  11. Mellie says:

    Hey there, You’ve done a fantastic job. I will definitely digg it and in my opinion suggest to my friends. I’m confident they’ll be benefited from this web site.

  12. Lee says:

    Build fails immediately with the following error with xcode7-beta

    Error:/Applications/ can’t open file: /Applications/ (No such file or directory)

  13. Adhi Ravishankar says:

    I remember seeing somewhere that AppCode had a lot of its resources taken by CLion, which I must admit is a great addition to an already fantastic lineup. But now, that CLion has reached its 1.0 release, will there be a devotion of resources to AppCode once again to get it back on track? Because Apple has already released Swift 2.0 and I would hate to see AppCode in a cycle of trying to constantly get back on track.

    • Adhi Ravishankar says:

      Also, will Swift 2.0 be supported? If not now, but in time for its fall release?

    • Anastasia Kazakova says:

      AppCode and CLion has now two nearly separated teams. So CLion doesn’t affect AppCode too much.
      We are working on bringing more intellisense for Swift to AppCode to help you with refactorings, code generation, and more.

      Swift 2.0 of course is in our roadmap as well ( But we are going first to finish with some smart features.

  14. Chris Hatton says:

    Huge love and thanks from the Bluedot team… AppCode makes our lives better! Thanks for your dedication to the updates. Can’t wait to start using the new Swift features.

Leave a Reply

Your email address will not be published. Required fields are marked *