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

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?  

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

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. 

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 :-)

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. 

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. 

I'm understand the situation, but should we looking forward for some solution from JetBrains team? I'm big AppCode fan but I ran into performance issue and have to postpone using AppCode on current project. Yes it is huge, but it is my work and I have to deal with it. There is a lot of legacy code wide room for refactoring, but I can't do anything because of slowness. So I wan't to ask, are you guys working on your own build system? Or maybe on some other radical solution?

@Andrew What specific issue do you mean? If we are talking about the compilation speed, the fix is implemented already, as I said earlier:

>In AppCode 2018.3.4 and the latest 2019.1 EAP we implemented the fix and now the compilation speed should be the same.  

Not only compilation speed but also very slow resolving and syntax highlighting. Every change causes re-resolving and paralyzes the work process. In Xcode I can see compilation problems almost just after typing but in AppCode I need to start compiling for such hints. I use latest EAP version

I'v been experiencing the same.

Sometimes when debugging, the app freezes for like a minute then I'm able to do anything (UI Freezes).

Sometimes adding a new line takes about 15 seconds, AutoComplete as well, all operations, but it works fine after a while, then starts again. I've even increased the memory of AppCode to 4gb, but didn't solve the issue.

I'm using the latest 2019.1

My complaints are not about long builds. AppCode works slowly at all: starting IDE, long indexing, syntax highlighting, find usages, refactoring, autocompleting, displaying parameters hints, debugging.

Sometimes it is faster to write method names completely by self, than wait for autocomplete.

Also, AppCode does not infer types properly using Swinject.

(AppCode 2019.1)

I'm sorry to close this thread, but it's not possible to track several issues and problems here. I encourage everyone to follow the approach mentioned by Florian here.