AppCode is the slowest paid software product I've ever used

Completed

So I embarked upon the journey of applying refactor > move on a member variable.

The member variable has one getter, and that getter has only one caller in another class.

AppCode worked on this refactoring project for 14 minutes.

During that entire time, CPU usage was at 150% and the entire UI was locked up.

After the 14 minutes finished, I saw that AppCode moved the member variable and its getter to another class, but it did not even refactor the caller from the other class!! 

 

Granted, the project I am working on uses a library that is somewhat large, and I've been told that this can cause AppCode to work slowly.  That really isn't an acceptable excuse though since XCode works just fine with this library, speed-wise.  That said, I don't think it's fair to charge this much money for a product that is this slow.  Even simpler things like AutoComplete are so slow (takes 8-15 seconds to activate) that I type everything out myself.  

 

I've done all the regular steps of increasing memory usage, and all the other suggestions their (genuinely friendly) customer support staff have suggested.  The project is in C++ and I'm using AppCode 2018.3.

7 comments
Official comment

Hi Saro, 

As we are already communicating via the support channel, let's finish this thread and continue investigating the problem in ZenDesk. 

I quit AppCode, relaunched it, and it's now "refreshing files..." for 20 minutes.  I can't build or run.  Anyone know what this is all about?  

 

0

I am really sad to say this, but JetBrains does not seem to finally address this problem and it re-appears over the years.

0

This problem is a complex of regressions appearing from time to time after big changes. It cannot be fixed once. If such problems appear, we are working on them as soon as we understand the root cause of the problem. 

0

Thanks Stanislav for your reply - and sorry for my negative comment. I still love AppCode, even if it has these itches sometimes. I have indeed learnt to keep old 'good working' versions of AppCode on the Mac in case the newer ones have this performance issues. However, I hope you guys keep making it better :-)

0

Hey guys, I'm also encounter these issues. It's take almost double the time than Xcode to compile.

I'm a developer for 6 years, being developer for both android and iOS platform and I'm working in notorious American company. 

We have a huge project, but it's compiling just fine for Xcode.

lately we tried to switch to appCode, out of 50 developers, 10 of us use it for 4 straight days.

Unfortunately it's cannot replace Xcode because of the slowness it causing, all the amazing experiences I had in Android Studio are all gone. 

I guess we going to give it a shoot next year. 

Also, if this product is no good I don't understand why charging money on it. Do a beta release, give it for free and once you all fix them issues release it again. 

 

1

Hey guys, I'm also encounter these issues. It's take almost double the time than Xcode to compile.

Unfortunately, that's not the same issue. That's the separate issue with the Xcode build system. Let me first describe it in details, cause this issue continuously gives a wrong impression to our customers about AppCode. Xcode has its own build system. It can be invoked a) directly from the Xcode when you work in the IDE b) via the xcodebuild command-line utility shipped by Apple in the Xcode distribution. It's important to mention that both ways are recommended by Apple. First one is obviously for building apps from the IDE, the second one for CI. 

And initially, the speed of xcodebuild was the same. Next, Apple changed the Xcode build system. But the performance of the xcodebuild remains the same though years. It's much slower then Xcode build system direct invocation, especially for incremental builds. And nothing is improved here. We also cannot improve it, since it's closed source. 

In AppCode we do not introduce our own build system. We were using the xcodebuild instead. And in the past, we had a lot of complaints about its speed. Finally, we managed to invoke the Xcode build system directly in the same way as Xcode does. All the performance problems with the compilation speed were fixed until the Xcode 10.x, where our integration was broken after changes made by the Xcode team. We spent a lot of time fixing it and temporarily switched to the xcodebuild invocation again (one, two). In AppCode 2018.3.4 and the latest 2019.1 EAP we implemented the fix and now the compilation speed should be the same. 

Another important exception is that it's the same if you continuously build in AppCode without switching to the Xcode. That's because we cannot use the same DerivedData that Xcode uses, cause it's not possible to run two compilations simultaneously on the same DerivedData. It causes a lot of conflicts, so we use a separate one. 

So, @Guycohendev, about your comment: please, try the AppCode 2018.3.4 (should be possible via free trial) or AppCode 2019.1 EAP (that is free for all for a month). Also, I'm interested in getting in touch and helping your team to adopt the product better in general - even the list of issues you have will be really helpful for us to consider them in the future. My email is stanislav.dombrovsky at jetbrains.com, feel free to drop me an email directly, so we could arrange the meeting and go deep into details. 

1

Please sign in to leave a comment.