AppCode 2016.3 EAP: improvements in Swift resolution performance, Swift 3 support in debugger and more

Posted on by Stanislav Dombrovsky

New AppCode 2016.3 EAP (build 163.7743.19) is available for download on our confluence page. If you are using previous 2016.3 EAP build, the patch update is also available.

Resolution performance

This build contains significant improvements in Swift resolution performance implemented as a first part of this task. It means that highlighting in Swift files should become faster and AppCode should use less CPU when editing Swift files in general. If you experienced any of the problems mentioned above before, we encourage you to try this build and share your feedback with us.

Note that we are still working on completion performance (OC-14065).

Swift 3 support

The following Swift 3 support features are included into this build:

  • Debugger fixes (OC-14432) related to Swift 3 collections rendering
  • SE-0077: Improved operator declarations (OC-14162)
  • SE-0040: Replacing equal signs with colons for attribute arguments (OC-14370)

Swift semantic highlighting

Another feature included into this EAP build is the semantic highlighting support for Swift language (OC-13894):

Swift semantic highlighting

You can turn it on in Preferences | Editor | Colors & Fonts | Language defaults | Semantic highlighting.

For the full list of fixes please see the release notes.

Your AppCode team
JetBrains
The Drive to Develop

Comments below can no longer be edited.

12 Responses to AppCode 2016.3 EAP: improvements in Swift resolution performance, Swift 3 support in debugger and more

  1. Tropper says:

    November 10, 2016

    Semantic highlighting is pretty useless IMHO. My parameter have already a different color then locale variables, “semantic highlighting” just fucks it up.

    What I would like to be able to is to give locale “let” variables a different style than locale “var” variables. In IDEA you can give “final” var a different style. But again, just my opinion.

  2. Dev says:

    November 10, 2016

    SourceKit inspections seem to be working better on this build. They’ve never worked for me on this project. They didn’t work with this build either at first, but after using it for a while they started to show up. It does take a few seconds for them to appear after writing bad code, but they do seem to be there now. I had enabled SourceKit logging in the AppCode process and noticed that when I first used this build, and they weren’t appearing, there were two behaviours:

    – SourceKit logging wasn’t returning anything (not sure if the xcodebuild subprocess starting did something there, but it seemed to coincide with that.)
    – The SourceKit responses contained no errors. The source text in the SourceKit request contained the bad code, but the response didn’t list it as an error. Xcode showed an error for the same code. I couldn’t compare the Xcode and AppCode requests and responses because Xcode makes a crazy number of SourceKit requests and responses and I didn’t have time to sift through that.

    • Dev says:

      November 10, 2016

      My uneducated gut feeling on the flakiness is that it’s related to the SourceKit index command, and that it doesn’t work reliably until the relevant files have been indexed.

      • Stanislav Dombrovsky says:

        November 10, 2016

        Finally we found the performance issue with SourceKit (https://youtrack.jetbrains.com/issue/OC-14402) and we are working on it right now. Hopefully after the fix it should work faster.

    • Stanislav Dombrovsky says:

      November 17, 2016

      Please, try this build and let us know if it shows warnings/errors faster.

  3. Dev says:

    November 10, 2016

    Completion inside a closure seems a lot better, too, and is now usable. https://youtrack.jetbrains.com/issue/OC-14065 will hopefully bring the speed inline with (or exceed!) Xcode’s.

  4. Geoff Rimmer says:

    November 11, 2016

    In “Swift Semantic Highlighting” on

    https://blog.jetbrains.com/objc/2016/11/appcode-2016-3-eap-resolve/

    this comment is NOT correct:

    You can turn it on in Preferences | Editor | Language defaults | Semantic highlighting.

    The correct comment should be:

    You can turn it on in Preferences | Editor | Colors & Fonts | Language defaults | Semantic highlighting.

    (in other words add “Colors & Fonts |” to the description)

    • Stanislav Dombrovsky says:

      November 11, 2016

      Thanks for the correction.

  5. Pier says:

    November 16, 2016

    I would like for the overall performance to be better rather than more features. I use CLion at work, and it is smooth. Maybe AppCode has to deal with more things, I don’t know. Opening AppCode side by side with XCode really slows the computer down.

    • Stanislav Dombrovsky says:

      November 16, 2016

      Could you please tell, which particular languages do you use in AppCode and in case you’re using Swift – wasn’t the overall performance improved by this build? Changes in resolution are quire heavy and in general speed of resolution should become much faster, especially on complicated projects.

      • Francis says:

        November 17, 2016

        I second this, new features are great but AppCode, at least for me, is currently too slow to make use of any of them. I think the crux of my performance issues stem from OC-14065. Without this fix I’m not really able to see the benefits of OC-13714.

        I am excited at the progress and attention the AppCode team has been placing on performance recently. I’m really looking forward to coming back to AppCode once these issues are fixed.

        • Stanislav Dombrovsky says:

          November 17, 2016

          We are still working on the issue you’ve mentioned, for the moment it would be great if you try this build and let us know if it’s faster for you.

Subscribe

Subscribe to product updates