AppCode 2019.3 Roadmap

Hi everyone,

Our roadmap for AppCode 2019.3 will be the shortest we’ve ever shared: this release will be focused on performance improvements without launching any new features. The goal is to eliminate as many freezes and slow-downs as possible.

To do this as well as we can, we’ll need your help! The best place to share any performance problem is our tracker. You don’t have to understand what causes the problem, as most issues are difficult to analyze when it comes to IDE functionality. If you see a problem, just try to describe it briefly, and our engineers and QAs will take care of the rest.

If you’d like to dedicate more time to help us, we appreciate the following artifacts submitted to performance tickets:

  1. CPU Snapshots. We need them if some IDE action is slow but does not cause a freeze, in order to identify the specific part of our code responsible for the performance problem.
  2. Thread dumps and logs. You can gather them by clicking Help | Compress Logs and Show In Finder. We’ll need thread dumps when you have a freeze: they will show us which particular part in our code causes it.
  3. Test projects that allow us to clearly reproduce the issue are one of the best sources for solving problems.
  4. Screencasts are nice and usually reduce the time needed for initial issue analysis. Make screencasts if you have time :)

And last but not least: if you work in a team that uses AppCode and has performance issues that are hard to analyze – get in touch with us. We are ready to schedule a call, take a look at your project, and collect the information to sort the issues out.

Or if you’ve just started with AppCode – get in touch with us. We will help make the process easier, and what’s also important, we will collect additional feedback that is very important for making the IDE better for everyone.

Let’s join forces and speed up AppCode – together!

Your AppCode Team
The Drive to Develop

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

21 Responses to AppCode 2019.3 Roadmap

  1. Steve says:

    Are there plans for bringing some of the refactorings that worked in Objective C (extract method, extract class, change signature, etc) to Swift?

    • Stanislav Dombrovsky says:

      No, in this release we won’t add them. None of them will be beneficial for our users until performance problems are fixed.

  2. Alek Zubala says:

    I appreciate that the focus was moved to resolve this performance issues we face lately ❤️

  3. Joost says:

    Curious about the roadmap for Xcode 11 support (and especially about supporting the way Xcode handles Swift Package Manager). Any thoughts on that?

    • Stanislav Dombrovsky says:

      We already support Xcode 11 with AppCode 2019.2. What features do you miss specifically for Swift Package Manager? We have it already fully supported in the CLion, even better than in Xcode. At some step we will include the same support in AppCode for macOS, but not in 2019.3. 2019.3 is focused on the performance only.

      • Mike Schnaser says:

        I seem to not be able to use XCode 11 with my 2019.2 AppCode:

        AppCode 2019.2.1
        Build #OC-192.6262.61, built on August 21, 2019

        XCode: Version 11.0 beta 6 (11M392q)

        • Stanislav Dombrovsky says:

          Could you please tell if you mean a warning shown in AppCode or some specific issues when using AppCode together with Xcode 11?

      • Joost says:

        Maybe I’m not doing it the right way, but I’m running into a few issues regarding Xcode / SPM:

        I have setup a workspace that contains a mobile app and a SPM project. The mobile app has also some cocoa pods dependencies and it also uses the SPM project. The SPM project also has its dependencies.

        In Xcode 11 I’m able to work on the app and the SPM project. Code is committed to the right git project and the project builds and runs without a problem.

        When I open the workspace in App Code 2019.2.1 the SPM project does not open (it is showed as a gray-ish icon). As a workaround I’m working on the SPM project in separate window.

        When Xcode 11 beta 6 is open the project fails to build without any details. Closing Xcode seems to solve this.

        Would be awesome to get this working in 2019.4 or something.

        • Stanislav Dombrovsky says:

          Thanks for the explanation, now it’s clear. We’ve extracted several issues with SPM projects in Xcode projects / workspaces here Initially I was wrong – in fact, they are really not supported yet.

          Hard to say if we will be able to add their support soon, because we haven’t expected such a way of integrating SPM packages on macOS. Most probably because of the number of performance problems we are going to address we won’t be able to work on this integration during the next release.

      • In Xcode 11 you can just drag & drop a SPM “project” onto the application icon, it will be recognized as a project, integrate into Run / Debug, and automatically fetch any dependencies. This is something I wish would be present in AppCode. As you already said I’ve only seen this in CLion so far (which is kind of confusing to be honest, because I always though of CLion as an IDE geared more towards backend & low-level C(++) developers).

        Or to rephrase it: I would expect for CLion to have first class CMake support. I would also expect for AppCode to have first class SPM support. I wouldn’t necessarily expect it the other way around.

        • Stanislav Dombrovsky says:

          This issue needs an explanation. A year ago we’ve changed CLion Swift plugin so that it works directly with SPM project model and loads the project purely based on Package.swift. It required quite a bit of effort from us. Xcode team integrated SPM projects in a different way: instead of direct loading of SPM projects, they just add it to the Xcode project via hidden .xcproject file in .swiftpm directory. So, now SPM integrations in Xcode and CLion use two different project models.

          Initially we planned to integrate the same support for SPM projects as in CLion. Now we need to write the same part again, for the Xcode project model in AppCode. So, we understand users’ expectations, but from the technical side it’s a complex task.

          We plan to analyze possible ways of SPM integration in AppCode during the 2020.1 release, but until the initial investigation is not finished it’s hard to give any ETA.

  4. Alex says:

    This is great news! I’ve learnt to live with it, but definitely miss the speed of the IDE pre-swift.

  5. A Developer says:

    Appcode 2019.2 is an absolute memory hog. A few version before it used around 2Gs dealing with my above average project. Now its 4.5Gs. The fans are constant spinning, hot keyboard, etc.

    The dev team should focus on optimizing, reducing memory usage. It doesn’t help with macbooks 16GB memory limit. As a professional those memories are precious, it nots simply for Appcode to use up as many possible. Other tools require memory tool.

    Its lazy to solve performance issues by allocating more memory.

    • Stanislav Dombrovsky says:

      Appcode 2019.2 is an absolute memory hog. A few version before it used around 2Gs dealing with my above average project. Now its 4.5Gs

      AppCode uses JVM, JVM allocates it’s memory on the startup and after it this memory does not grow. The maximum amount of RAM for the IDE is specified via the Xmx setting. So, the actual amount of memory used by AppCode is the amount of memory that show the memory indicator inside IDE (Preferences | Appearance & Behavior | Appearance | Window Options | Show memory indicator), not the amount of memory shown in the Process Monitor. Some projects can indeed require a lot of memory, and here the project size itself can be small, but the size of frameworks can be big. Could you please share your project with us, so we could check memory issue on our side?

      The fans are constant spinning, hot keyboard, etc.

      If it happens after the initial indexing and caching, we need a CPU snapshot to understand what happens.

      Its lazy to solve performance issues by allocating more memory.

      We don’t solve them this way, because it’s not possible to solve them this way.

  6. Thank you guys for stepping up to this and treating it with the full all-in focus it requires/deserves.

    AppCode has become effectively useless for us – we don’t even use Open Type anymore since everything is hoggie/undependable. Will do our best to submit any perf logs to help out!

  7. Alex says:

    I appreciate the focus on performance as 2019.2 is much slower than 2019.1 for me (mainly around any type of autocomplete or cmd-click on a variable/method name).

    Also, there are times where the Activity Monitor shows that AppCode is eating over 100% CPU when there are no tasks showing in the UI. Usually, it’s a prebuild or something, but not always.

    I’ve been trying to get information on both of these, but have not really been successful.

    • Vyacheslav Karpukhin says:

      Prebuild is required to generate the swift modules for the targets in your project, some autogenerated files (like CoreData models) and some other things required to correctly work with a project in the IDE. Usually it takes a lot of time only the first time and should be pretty fast after that (unless there have been significant changes to the project since last time). Also, Xcode does this too.

      Another background activity could be building index for the tests. The progress isn’t shown because this activity does not prevent you from using any IDE feature. Again, usually it takes a long time only on the first run.

      You can check what IDE is currently doing by using the Help -> Activity Monitor menu.

  8. Tom Condon says:

    Curious that I just installed Xcode 11 GM Seed (11A419)and AppCode tells me in preferences/tools that it does not support this version. Is that message correct?

    • Vyacheslav Karpukhin says:

      At the moment there aren’t any known issues with Xcode 11. Soon we’re planning to publish an update that disables this warning for Xcode 11.

Leave a Reply

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