AppCode 2019.3 Roadmap

Stanislav Dombrovsky

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
JetBrains
The Drive to Develop

Comments below can no longer be edited.

23 Responses to AppCode 2019.3 Roadmap

  1. Steve says:

    August 20, 2019

    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:

      August 20, 2019

      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:

    August 21, 2019

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

    • Stanislav Dombrovsky says:

      August 21, 2019

      Hi Alek, your issues were mostly related to the general one – performance problems with module maps. This one has a highest priority, cause it’s a general reason for many other performance issues.

      • Alek Zubala says:

        August 21, 2019

        Thanks for the info Stanislav!

  3. Joost says:

    August 21, 2019

    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:

      August 21, 2019

      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:

        August 24, 2019

        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:

          August 27, 2019

          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:

        August 27, 2019

        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:

          August 27, 2019

          Thanks for the explanation, now it’s clear. We’ve extracted several issues with SPM projects in Xcode projects / workspaces here https://youtrack.jetbrains.com/issue/OC-19012. 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.

      • Rafał Bugajewski says:

        December 6, 2019

        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:

          December 6, 2019

          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:

    August 21, 2019

    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:

    August 22, 2019

    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:

      August 27, 2019

      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. Marcel Bradea says:

    August 22, 2019

    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:

    August 30, 2019

    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:

      September 12, 2019

      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:

    September 12, 2019

    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:

      September 12, 2019

      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.

  9. Louis Pontoise says:

    March 31, 2020

    Hi!

    Could you guys expand a bit on what you have been doing. For instance, I checked the release note of 2019.3.7 and it only says:

    > Xcode 11.4 caches (faster “Processing Swift Modules” caching phase)

    This is a bit short. I’m curious to learn if there are steps I can take to help the build be faster. For instance, currently, AppCode doesn’t respect the DerivedData XCode configuration, and does its builds in a different place un-configurable. Is there any way I can changed paths and make builds reuse build artifacts more?

    Outside of these performance shortcomings, I’m loving the product. Lots of love to the team!

    Louis Pontoise

    • Stanislav Dombrovsky says:

      March 31, 2020

      Could you guys expand a bit on what you have been doing.

      We need to build the code tree, and for that we need to process all the standard frameworks. For Objective-C we have headers that are pure text. For Swift Apple ships .swiftmodule files that are binary. We need to first read them using the SourceKit to be able to build the code assistance for Swift. SourceKit requests for reading Swift interfaces are slow, so we decided to bundle the Swift module cache in our installer. This message means that caches for Xcode 11.4 are now bundled and because of that “Processing Swift Modules” phase should be much faster than without them.

      I’m curious to learn if there are steps I can take to help the build be faster.

      Currently we don’t see any way to optimize builds in AppCode. We already have the same speed as Xcode for regular and incremental builds. The difference is with the DerivedData directory, and another directory is “by design”. Xcode build system does not allow to run several builds of the same project using the same DerivedData directory – it will lead to conflicts. One of the general use-cases for our users is to test in AppCode and build in Xcode, or run tests in Xcode and debug the application in AppCode. In case you run several builds in the same DerivedData directory, each build fails, sometimes even wrong results are reported for the build (successfull build when you have compile errors) etc. So, technically we can setup the same DerivedData directory in AppCode, there is no problem, but we cannot solve problems of Xcode build system here, we just use it. That’s why AppCode uses a separate DerivedData directory. As soon as Xcode team solve this problem, we will switch to the same DerivedData directory.

Subscribe

Subscribe to product updates