AppCode is tantalising. It has so much potential to be great, but it reaches greatness all too rarely. Instead, using it often feels like a peculiar form of masochism. You know what I'm talking about – it's slow. Slow enough to make you cry, but you know... only every second day. Or when the wind is blowing from the north. When the wind it southerly, it knows a hawk from a handsaw.
Periodically, this madness drives me back to Xcode... until I miss the many things I like better about AppCode.
JetBrains seem to be in damage-control mode. There have been many complaints on the public AppCode forum about glacial, unusable slowness, but they've repeatedly been met with "oh, it must be your particular situation – send us a copy of your project" – disingenuously ignoring that performance is bad for most projects, not just a few outliers. And now they've closed the forum. Not all their product forums mind you – just the AppCode one. Yikes. When a company starts doing this sort of thing, you can't help worrying about the product's future.
But for now...
A ray of hope
Cocoapods, as it turns out, slows down AppCode. If you have a lot of pods, it slows down AppCode a lot. Pods are added to your project as source code – that means they're compiled as part of your project, but more importantly here, AppCode indexes all that extra code. This has a big impact: indexing is much slower, and things like code completion have way more to deal with – and often grind to a halt.
If you stop and think about it, the code in your pods is probably many times the size of your project's main code. I'm currently working on a project that has 50 pods once you count all the transitive dependencies. That's a lot of extra code for the IDE to deal with. (Yes, that's too many dependencies, but quite a few are integrations that the client wants, and I don't have much choice about those.)
So, what to do about it? There are a couple of options.
Swift Package Manager 👎
This won't save you, sorry. AppCode doesn't support Swift Package Manager yet. Fingers crossed for the future.
With Carthage, dependencies are added to your project as binaries, not source – they're either pulled down already-built, or Carthage builds them during its equivalent of
pod install. Carthage is also nice because it's less invasive – it fits into your project nicely rather than forcing a workspace upon you like Cocoapods does. Unfortunately, not all projects support Carthage – particularly older ones (which you can understand) and those from big vendors (who have no excuse).
If it works for you, Carthage is a good option, and you'll get the same performance gains as...
The cocoapods-binary plugin 👍👍
The cocoapods-binary plugin has made the 50-pod project usable again in AppCode. It's really a dramatic difference. Similarly to Carthage, it builds dependencies at install time and adds the binaries to your project.
A nice thing about it (and it beats Carthage in this regard) is that it's simple to flip an individual pod from binary to source. So you can get down into a dependency's code when you need to – for debugging or just better understanding – but you don't burden the IDE with all the source for all the dependencies all the time.
It's not perfect: best to stay away from the "all_binary!" option, which just seems flaky. Also, if you're using Firebase, there's a bug you need to work around. And depending on what you're doing, CI might get harder, so you might want to look into that.
But overall, it's been totally worth it. AppCode is usable again – really quite often.