different distros have different set of libraries, + Debian vs RPM packages
You know your "surface dependencies". So for each distro you need to find the packages that provide those dependencies (and document that), and to test that it does also bring all transitive dependencies (not just in terms of underlying libraries, but also in terms of "built with the right options" or whatever runtime-constraints might exist). Finding the set of packages is a one-time task that's not too complicated, but you'll have to test at least for every release, so a good test setup is necessary (good automation, and/or goot QA team).
But if you have a complex set of dependencies, it becomes likelier that you'll run into complex constraints about which version of what is needed, and sometimes you have to abandon some versions of some distros... or start addressing this by trying more difficult things that bring another set of complexity: compile yourself and ship your own glibc and libraries, or build statically-linked binaries, but you'd be opening a new can of worms... This will heavily depend on what you use to build your application. If you use C++ for example, you have a lot of other details to consider (the system compiler's ABI, kernel ABI...). From experience, the most awful thing is when you use several commercial libraries, that each have their own set of supported "platforms", and if you look closer you discover they incur weird constraints on what version of the compiler you can use, and you have to call them and negociate custom builds... (that experience was 15 years ago, maybe things are better now).
Docker can help simplify the infrastructure you need for tests. It can even allow you to skip all this, if you prefer to stick with 1 distro, and ship your app with a docker image that builds on that distro (which will work the same under all distros). Some server-side systems do that, but I've not seen that second option in the wild for desktop applications, so I'm sure there are other difficulties (guessing: displaying stuff must not be too complicated if you can pass
$DISPLAY and the network settings allow it, but would copy-paste work? Drag-and-drop?...).
Of course if what you build is open source, better embrace each distro's system and become part of the ecosystem, as described in Kilian's answer.
Different UI - Gnome vs KDE
Side-note: each desktop environment (DE) comes with its own set of packages, and some of your dependencies might depend on packages that are only available with one DE. But usually whatever package you need is available to install, so let's say this is addressed by the "distros packages" section)
For the look and feel, if you want your app to "look native", again it depends on what you use. Your UI toolkit might be GTK-based, or Qt (there are Qt look-and-feels that can look like GTK apps -- this also depends on the distro and the packages, but for some common distros it might be worth documenting "install package so and so, go there in your settings, choose this...").
Or you might be using a "neutral" toolkit, and you don't care about that. But you'd still have "desktop integration" problems like "How do I open that web page with user's default browser?" or "Open that pdf file with the default PDF viewer". There are gnome-specific and KDE-specific commands for that, but there are also generic tools, I'd recommend
xdg-open. You might run into funny edge cases, so you might want to offer the ability for the user to configure system commands for desktop integration, but with a robust base config that should work on 99% setups (See XDG standard and xdg-open)