New AppCode 2017.1 EAP: support for #keyPath in Swift and important fixes

AppCode 2017.1 EAP (build 171.3780.31) is available for download on our confluence page (if using previous 2017.1 EAP build, the patch update is also available).

The highlights of this update include:

  • SE-0062: Referencing Objective-C key-paths (OC-14598), which brings correct highlighting and completion for the #keyPath() expression together with the correct resolution and navigation for its arguments
  • SE-0060: Enforcing order of defaulted parameters (OC-14231)
  • Fixes for completion regressions in Objective-C (OC-15030), Swift (OC-15092) and mixed code (OC-15008)

The full list of fixes and improvements can be found here.

Your AppCode team
JetBrains
The Drive to Develop

banner
This entry was posted in Announcement and tagged , . Bookmark the permalink.

3 Responses to New AppCode 2017.1 EAP: support for #keyPath in Swift and important fixes

  1. Florent says:

    Guys, it’s cool to see new EAPs but I’m a bit concerned by the slow improvements on the Swift front. There is a LOT to do here:

    – type inference barely works
    – IDE has become extremely slow, consumes a lot of CPU at times (latest EAPs)
    – I’m now feeling lucky when completion works at all
    – constructs like flatMap and do / catch are still spuriously highlighting code as incomplete / incorrect, where it actually compiles fine and doesn’t miss anything
    – we’re still waiting on all of the great refactorings that made AppCode a kickass IDE
    – Now Find Usages won’t find all usages in many cases (if at all), I have to use text search to make sure I catch every use
    – Refactoring names still don’t play well with protocols, and won’t rename methods in structs / classes inheriting from protocols

    And the list goes on and on. When are you going to assign enough resources to AppCode to make sure it keeps up with the language? The situation is a bit desperating… AppCode is now not much more than a better editor than Xcode. I even find myself building and running code in Xcode, because I found cases where the debugger goes south and enters endless loops. Not mentioning the slower builds, not sure why.

    I’m a huge, huge fan of AppCode and I know what you guys are capable of. But it seems the product is given a low priority and you’re just doing the bare minimum with every release.

    Please, make AppCode great again. Please.

    • Stanislav Dombrovsky says:

      IDE has become extremely slow, consumes a lot of CPU at times (latest EAPs)

      As I understand, it’s OC-14772. Could you please capture a CPU snapshot and attach it to this ticket? Cause it’s the only way for us to clearly reproduce this issue and fix it faster.

      type inference barely works

      Could you please share some code example in a ticket? There could be completely different reasons for such behaviour, and here we can analyze and it fix it only when we have a concrete context.

      I’m now feeling lucky when completion works at all

      This EAP fixes some issues, but you may need to Invalidate Caches and restart. If it does not help – again, we need a concrete example to understand, why doesn’t the completion work in your case. So the ticket will help us a lot.

      constructs like flatMap and do / catch are still spuriously highlighting code as incomplete / incorrect, where it actually compiles fine and doesn’t miss anything

      If you mean OC-12898, we’ll try to fix it.

      Now Find Usages won’t find all usages in many cases (if at all), I have to use text search to make sure I catch every use

      If you mean OC-13248, we are working on it.

      Refactoring names still don’t play well with protocols, and won’t rename methods in structs / classes inheriting from protocols

      Could be related to OC-13248, cause if there is a problem with finding usages, any refactoring will miss the same usages. But anyway, a ticket with the problem will help a lot.

      cases where the debugger goes south and enters endless loops

      Is it possible for you to provide some information about it (e.g. is it possible to share such case)?

      Not mentioning the slower builds, not sure why.

      Unfortunately this one is not clear for a long time. We invoke xcodebuild, so the speed of the build should be the same as xcodebuild has. And xcodebuild should behave the same as Xcode itself.

      But it seems the product is given a low priority and you’re just doing the bare minimum with every release.

      TL;DR
      Some tasks are not that simple inside as they look from the user perspective. They could look quite simple and simultaneously require a lot of time to be implemented. Same as in mobile development, cause I’m personally remember same situations from my experience.

      About priorities. There is a single priority for each JetBrains product starting from the first day of the first public EAP – we love it as much as we love any other our product and it has the same importance for us :) Just because it’s already published. And it won’t be ever changed. Because it’s a JetBrains product :)

      Please, make AppCode great again.

      We are working on it right now :)

  2. Pingback: AppCode 2017.1 EAP 更新 在 Swift 中支持 #keyPath | News Pod

Leave a Reply to Florent Cancel reply

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