AppCode starts 2016.2 EAP: Swift inspections and Live Templates, improved Rename for the mixed code and more!

Hi everyone,

Today we are starting the Early Access Program for AppCode 2016.2 EAP, with a huge number of changes available in the very first build. You’ve waited for some of them for a long time, so check it out right now!


SourceKit inspections and intentions

This build brings one of the long-awaited features from our roadmap – initial implementation of inspections and intentions in Swift. Now AppCode shows warnings and errors for Swift code in the editor right as you write it!
Swift warnings and errors in editor

To display these warnings and errors, AppCode uses SourceKit engine bundled in the Xcode version selected in AppCode settings. Moreover, most quick-fixes available for Swift in Xcode can now be used in AppCode. Just press ⌥Enter on a warning or error and select Apply Fix-it:
Swift quick-fixes
In case of several fix-its suggested for a particular code block, AppCode will display their descriptions, allowing you to select the necessary action:
Multiple Swift quick-fixes
Inspection settings are available under Preferences | Editor | Inspections | Swift | SourceKit inspections, where you can turn it on or off at any time:
Intention settings
SourceKit inspections are also available in batch mode, and here you can fix every problem step by step. For now it’s even easier with improved UI for code inspections available in this version:
Batch mode

Live Templates

Live Templates in AppCode are similar to Xcode snippets. They contain predefined code fragments so that you can use them to insert frequently-used or custom code constructs into source code quickly. Starting with this build, Live Templates are also available for Swift language:

  • Invoke a Live Template by typing its abbreviation, or use ⌘J and select it from the list:
    Live template calls
  • Quickly iterate collections with the smart for template:
    For template

You can also add your own custom Live Templates for Swift under Preferences | Editor | Live Templates | Swift. Select predefined code context to make your live templates available only for Swift declarations, statements or any code construction:
Live templates context

Spelling inspection

In addition to the SourceKit inspections mentioned above, we decided to make the Spelling inspection available for Swift language. If you happen to mistype something in your comments or code constructs, AppCode will underline the misspelled word. Then you can fix the problem simply by pressing ⌥Enter:

Recursive resolve for shorthand arguments in closures

This feature had one of the shortest descriptions in our tracker, one simple line:

let a = {$0 + 1}

Nevertheless, it was a huge task we needed to finish as part of preparation for creating Introduce Variable and Inline Variable refactorings for Swift. This build contains an initial implementation of recursive resolve for closures in Swift, including correct resolve for shorthand arguments. This change brings the following features:

  • Now you can benefit from completion for shorthand arguments:
    Shorthand completion
  • In case the closure contains tuple as parameter, you can navigate to the actual declaration of the tuple item:

Please note that some issues with closure resolve still exist; most of them are added as sub-tickets to the base task. We will continue to work on them and will try to resolve the most important ones before the 2016.2 release.

Mixed code improvements

It’s been awhile since we implemented the Rename refactoring for pure Swift code and Objective-C declarations used from Swift. Now we add the ability to rename Swift methods and method parameters used from Objective-C code! Let’s take a quick look at it:

  • If using Swift methods from Objective-C, you now can invoke Rename on the method name:
    Rename Swift from Objective-C
  • To rename external or local parameters, invoke Rename from Swift code:
    Rename Swift parameters
    Notice how Objective-C representation was correctly updated in Objective-C code.

Another great addition in this build is improved Find Usages (⌘F7) functionality, which now also finds occurrences of Swift methods used from Objective-C, including initializers.

There are also lots of fixes for code declarations annotated with @objc attribute, bringing improved parsing and highlighting for classes, protocols and enums, and correct resolution for properties, subscripts, getter and setter names.


Doxygen support

You may know that AppCode and CLion teams work together to bring you first-class C++ support in both products. But sometimes C++-related features also intersect with Objective-C, and one such feature recently implemented by the CLion team is initial support for Doxygen. For now, the same features are available for C++ support in AppCode and some of them have already been added for Objective-C as well:

  • You can now benefit from completion for Doxygen-style commands in Objective-C comments:
    Doxygen commands
  • The formatting for Quick Documentation (F1) is significantly improved with proper rendering for all Doxygen-style comments:
    Quick documentation

Please note that because of some issues, automatic comment generation for Objective-C is not yet included into this build, but we will try to deliver this feature before the 2016.2 release.

Complete statement

With Complete Statement (⇧⌘Enter) feature added in this build for Objective-C and C++, AppCode inserts parentheses, braces, semicolons, quotes, etc. for you where necessary, and then moves the caret in position where you can start typing the next statement automatically. The simplest example can be just adding a semicolon, but even this small feature can be helpful in case of complex code constructions:
Complete statements

Read this blog post to learn more about it.


In debugger tool window, the Watches and Variables modes are now merged so you don’t need to switch between them. If you still prefer the old style, a new button is available in the watches toolbar to switch between the modes (new mode is on by default):

VCS improvements

The following changes are available for VCS support in AppCode:

  • To make navigation through the VCS log easier, we’ve added tooltips with target commit information for arrows:
    Tooltips for commits
  • Commit dialog now also shows unversioned files:
    Unversioned files
  • Support for Apply somehow interactive mode for applying patches.
  • Git/Hg log shows commit details for several selected commits.

Phew, that does it! Full release notes for this build are available here. This being an EAP for a major update, the build does not require an active license so you can use it free for 30 days.

Download AppCode 2016.2 EAP, give it a try and let us know what you think!

Your AppCode Team
The Drive to Develop

Comments below can no longer be edited.

25 Responses to AppCode starts 2016.2 EAP: Swift inspections and Live Templates, improved Rename for the mixed code and more!

  1. Tropper says:

    June 2, 2016

    Yay! Can’t wait to test it!

  2. Michał says:

    June 2, 2016

    Great job, guys! Waiting for even more Swifty goodness!

  3. Bill A says:

    June 2, 2016


  4. Dev says:

    June 2, 2016

    The shorthand closure argument feature doesn’t seem to be working, even in a simple example like this:

    var test = [“”, “”, “”]
    test.forEach {
    $0.^no suggestions^

    • Stanislav Dombrovsky says:

      June 3, 2016

      Looks like the same problem as here. We are working on it.

  5. David Whetstone says:

    June 2, 2016

    Hmm, with SourceKit still being extremely crash prone, I’m not so crazy about this idea.

    • Vyacheslav Karpukhin says:

      June 3, 2016

      SourceKit analysis is performed out of process (both in AppCode and Xcode), so the crashes will not affect the IDE itself.

      • Chris Hatton says:

        July 8, 2016

        Out of keen interest, is SourceKit the long-term solution for real-time inspections in AppCode; or do you intend to switch back to your own parser (which I believe could be even better) once your language model is stable and complete?

        • Vyacheslav Karpukhin says:

          August 22, 2016

          I apologize for a late reply.

          Currently SourceKit and our own parser work side by side. SourceKit is used only for the error reporting, the same way as clang-annotator is used for Objective-C.

          Our own inspections and refactorings do not depend on SourceKit.

  6. Rick says:

    June 5, 2016

    is intenseness that bad?

    something as simple as
    let x =5
    x = 6

    why doesn’t it show any error or even
    var x =5

    nothing, is this normal or something missing.


    • Stanislav Dombrovsky says:

      June 5, 2016

      Hm, it can happen if syntax analysis is in progress. After it warnings and errors should be displayed. Could you please give us a screenshot of top-right corner of the editor area?

    • Dev says:

      June 6, 2016

      I agree that this is totally broken in the EAP. I can see in the SourceKit logs that the errors are being reported, so AppKit’s SourceKit requests are correct, so either there’s a bug in how those are being processed by AppCode, or – more likely – all the internal errors that I can see AppCode generating on each editor keypress are getting in the way. I’ve reported these errors through the in-app mechanism, but I’ll include them here for reference:

      [ 387874] ERROR – aemon.impl.PassExecutorService – @NotNull method com/jetbrains/cidr/lang/symbols/objc/OCProtocolSymbolImpl.getType must not return null
      java.lang.IllegalStateException: @NotNull method com/jetbrains/cidr/lang/symbols/objc/OCProtocolSymbolImpl.getType must not return null
      at com.jetbrains.cidr.lang.symbols.objc.OCProtocolSymbolImpl.getType(
      at com.jetbrains.cidr.lang.symbols.objc.OCMethodSymbolImpl.getReturnType(
      at com.jetbrains.cidr.lang.symbols.objc.OCMethodSymbolImpl.getReturnType(
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter.convertMethodSymbol(
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter.doConvertMember(
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter.access$100(
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter$
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter$

      • Stanislav Dombrovsky says:

        June 6, 2016

        This error is not caused by SourceKit response processing, it’s known issue, most probably caused by mixed code changes. Could you please describe how it affect the parsing/highlighting/displaying errors in your case? Is it possible for you to give some code sample (except mentioned in the issue description) to show may be some other side-effects?

        • Dev says:

          June 6, 2016

          Ah I see. I created a new project and I didn’t get the above stack trace on every keypress, and I can see now that the SourceKit diagnostics are showing correctly, including in Rick’s example. So perhaps it is the case that the above stack trace is indirectly the cause of the SK diagnostics not showing up in my regular project.

          Unfortunately I can’t send my regular project, but if I identify code that causes the issue, I’ll let you know.

          Until I created a new project just now, the EAP seemed very buggy, but I can see now that the new features are working well, it’s just that this bug is getting in the way. I hope you treat this as a high priority as it does totally break the editor.

          • Stanislav Dombrovsky says:

            June 6, 2016

            Thanks for additional information, we will.

  7. Tadeas Kriz says:

    June 6, 2016

    I’m looking forward more Code Style features. Right now I’m not able to use AppCode as I can’t setup the Code Style to match our team’s style. For example, there doesn’t seem to be a way to have closures look this way:

    { param in
    // executed code

    and instead they look like this:

    param in
    // executed code

    Are there any plans to improve this? Thanks!

    • Stanislav Dombrovsky says:

      June 6, 2016

      Most probably we will not be able to deliver code-style formatting features in the 2016.2 release, but we will consider code-style features for the next. Please, upvote this issue

  8. Pikor says:

    June 6, 2016

    This is really great news!
    However after opening project (100% Swift) AppCode is “Indexing” for infinite amount of time. Any ideas? :/

    • Stanislav Dombrovsky says:

      June 6, 2016

      Could you please submit a ticket to our tracker with idea.log attached (Help->Show log in Finder)? Brief explanation/screencast will also help a lot.

      • Lukasz says:

        June 8, 2016

        Sure, done! Note, files are added with visibility to “appcode-developers” group only.

        • Stanislav Dombrovsky says:

          June 8, 2016

          Thanks! We identified the reason for this problem and will try to fix as soon as possible.

          • Lukasz says:

            June 8, 2016

            Happy to help! 🙂

  9. Talles says:

    June 6, 2016

    Love you guys <3

  10. Talles Borges says:

    June 8, 2016

    I have a typealias:
    typealias CompletionBlockAPI = ((Result) -> ())?

    and a method that use this typealias:
    static func delete(creditCard: CreditCard, completionHandler: CompletionBlockAPI) { … }

    When I call this func the type of completionHandler is not recognized

    API.Users.CreditCards.delete(crediCard, completionHandler: { (result) in


    Are there any plans to improve this? Thanks!

    • Stanislav Dombrovsky says:

      June 8, 2016

      Could you please give a screenshot of how it isn’t recognized? Do you mean type in the completion popup for result when using it inside the closure or smth else?


Subscribe to product updates