AppCode 2017.2 Roadmap

Hi everyone,

Today we are ready to share our future plans for AppCode 2017.2.

Please note this is a preliminary plan, so not all features listed below may be included in AppCode 2017.2.

We are going to work on the following areas:

  • Swift:
    • Swift 3 and upcoming Swift 3.x support tasks
    • Resolution improvements
    • Override/Implement via completion (OC-13342)
    • Access modifiers in resolution (OC-10954)
    • Extract method/function (OC-12049)
  • Objective-C and mixed code:
  • Xcode 8.x support tasks (OC-13906, OC-14170)
  • Navigation improvements for projects with multiple targets (OC-9050 and related)

We are planning to open 2017.2 EAP at the end of April. If you have any suggestions or questions, feel free to share them in the comments below.

Your AppCode team
JetBrains
The Drive to Develop

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

12 Responses to AppCode 2017.2 Roadmap

  1. Paul says:

    I’ve recently started using AppCode again, having given it a few months to mature. I’m now using it for some work, switching back to Xcode in areas where AppCode is broken. If it’s useful to share, here are the issues that are still preventing me from using AppCode full time:

    https://youtrack.jetbrains.com/issue/OC-15046
    https://youtrack.jetbrains.com/issue/OC-15338
    https://youtrack.jetbrains.com/issue/OC-15339
    https://youtrack.jetbrains.com/issue/OC-13434

    I’m hoping most of those fall under “Resolution Improvements” for 2017.2. And perhaps improvements to the displaying of errors in the editor might make it into 2017.3.

  2. User says:

    I really hope for a quick solution to the “national keyboard layouts support” disaster. https://youtrack.jetbrains.com/issue/IDEA-165950

    • Stanislav Dombrovsky says:

      It’s the platform issue, so if IntelliJ platform team will be able to do it during the next release, AppCode will have it automatically without even working on it. Our team cannot fix this issue.

  3. hauwei.zheng says:

    Please improve compile speed

    • Stanislav Dombrovsky says:

      We use xcodebuild for building the project, it’s utility created by Apple, and we cannot improve it’s performance.

    • Raphael says:

      You can put this line “-Xfrontend -warn-long-function-bodies=200” in other swift flags in your compiler settings in xcode, which will find methods that take longer than 200 ms to compile.

      I found a method that took 30 seconds (!) to compile and with explicit typing this method compiles in less than 50 ms now.

      • Pawel Kata says:

        This is very important, IMHO. I, too, experienced long swift compile times in AppCode, when the sam code compiled 4-5 times faster in Xcode. My hack is to edit in AppCode and Buid&Run in Xcode, but that’s pretty inconvenient.

        • Stanislav Dombrovsky says:

          Actually, there is an issue, with some similar tickets linked, but all of them are really not clear for us. To have clear measurements, you need to perform them in the following way:

          1. Only Xcode and AppCode running and no other heavy applications, because CPU time eventually consumed by such applications can affect the measurement.

          2. As Xcode and AppCode use different DerivedData folders, it means that incremental compilation if you build in Xcode only, will be significantly affected when you try building in AppCode, because DerivedData folder used by AppCode does not contain any build artifacts, which DerivedData in Xcode already has. And it can cause the difference.

          3. To measure build times, it’s better to have a big project, clean it before building, then build and measure. And here to get the results which will be ±representable, you need minimum 20 iterations in AppCode and the same amount of full builds in Xcode – the more you have them, the less probability of various things that affect the compilation time you have.

          4. From our testing, if you try measuring build times this way, there is no such significant difference like “3-4 times”, but there is some not clear delay depending on the project size – 1-2 seconds during incremental compilation after the small change, 5-6 seconds (unstable) during the full build. It could be delay caused by xcodebuild, which seems to read the project structure before building, it can be an issue on AppCode side.

          To investigate it, we need relevant measurements + 5-6 full build iterations with CPU snapshot profiling started. All current CPU snapshots do not show anything related to the issue itself and all current measurements were made in some way when it’s impossible to analyze them and rely on them. We tried to clearly reproduce this problem for a long time, with lots of big real projects, and we do not see such problems with any of them. So, if somebody can catch this issue and give some open-source project to reproduce it together with some build statistics – it could help us a lot to reproduce it and fix. For now we cannot reproduce it in our environment – and because of it, we cannot fix it.

  4. Bruce says:

    I am still running into a number of issues related to using both Obj-C and Swift in a project (all reported in YouTrack). I am hoping you will continue to work through these.

    Before I started using Swift, I used to be able to get my projects pretty much error-free in terms of AppCode inspections. The number of errors I now have to ignore is still way too high and that is both unsettling and time consuming. I have tried to be patient, but this really should be a priority.

    Thanks…

  5. Pingback: AppCode 2017.2 Roadmap 发布 | News Pod

Leave a Reply

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