> I don't even know what that means
I already gave an example, but I can expand on that.
A CLI compiler only has to take its input and run it through the various compilation stages to the end or abort if something is invalid.
To do what eclipse does for code completion as you type on the other hand you have to to hook into the AST generator stage and the type inference engine given partial, invalid inputs, try to fix them up and then do searches on what other known pieces can be dropped into a particular place.
Which means your compiler can't just bail out at its earliest convenience. It needs public, not internal, APIs to massage state back into working condition so the next steps can then run until the IDE has gathered enough information.
Or take a memory profiler (with allocation callsite recording). The first step of interactivity is being able to turn it on and off at runtime. That means hot-swapping out some code, imagine replacing a malloc with a call-stack capturing one. It gets even more complex if you're using custom allocators.
And for the analysis part: In a simple CLI tool you might just run some graph analysis that takes 20 seconds on a multi-GB heap dump which then spits out the top 10 dominators and a class histogram and you'll hopefully know what to optimize. And you might want to diff those outputs (yay for text processing!) for test runs so you know how things change from build to build.
In a GUI you want interactivity, which means you can't just run those 20-second calculations every time the user navigates through some tree view. You need incremental algorithms, caching sub-results - but not too much otherwise the profiler itself will munge too much memory - etc. etc.
So you need APIs that go deeper into your graph logic than what you would think of public APIs needed for the CLI. And of course you need to build the whole GUI on top of that too.