Short answer: yes, XLib will work for the foreseeable future.
Although in some enviroments there will be additional libraries required. You don't need to worry about that.
Long answer:
XLib
XLib targets X Windows Systems (a.k.a X11). XLib is the classical library to use with X11 as works very close to it. XLib also includes a lot of helper code that eases the integration with the desktop environment.
X11 has been the core for desktop interfaces in the Linux ecosystem for a long time. Desktop Environments such as Gnome and KDE build on top X11... in essence X11 is a protocol, where the client sends requests and the X Server responds (will talk a bit more about that below), this is hidden by XLib which stores the requests in a buffer which are then taken by the X Server which will respond asynchronously, but XLib will make it appear synchronous.
High level components such as buttons et.al. exist as widgets on XLib, so this is the closest to the equivalent Win32 API.
XCB
All the communication hidden by XLib makes error handling harder, which led to the creation of the competition: XCB, which is intended to replace XLib by providing direct access to the X protocol. That means that XCB has a smaller footprint, it is asynchronous and has better performance. This makes XCB better in terms of performance, in particular for threaded applications.
Plot twist: XLib since the version 1.2.0 is actually built ontop of XCB. This means that you can mix XLib and XCB code with no problem... but it means that you need an additional library for XLib since it depends on XCB.
X Server
As mentioned above, there is an X Server that provides the abstract information and talks to the screen and input devices. The server doesn't know anything about user interface design. Then there are X Clients, which will interface with the server... this architecture facilitate for Clients to work over the network allowing access to remote terminals/desktops (although that's an over-simplification).
The X Server doesn't know about GUI, allowing it be changed, that's what Desktop Environments do. In this scenario X11 does all the rendering, although libraries for hardware accelerated graphics might bypass this.
Wayland
In the past there were competitors to X11, many deprecated... and there are new competitors to X11, in particular I want to mention Wayland.
Wayland is another protocol, much simpler than X11, that yields control of the actual rendering to the client.... basically Wayland shares a buffer for video memory where the client renders whatever it wants however it wants, so there is no graphics API. In fact, Wayland will handle the concept of windows and the composition of these buffers in video memory according to the windows they represent. This makes Wayland better for encapsulation in general (no API means less surface, and the model allows to isolate the memory easily).
X11 has needed a lot of updates to remain relevant with new technologies and standards (e.g. supporting font and image formats, supporting hardware acceleration, etc...), but with Wayland that problem goes to the graphic libraries the developer use.
While support for Wayland is increasing, X11 will stay around because of all the software build around it. What is expected to happen is that code from X11 will become part of the kernel, become extensions to Wayland or become libraries to be used by developers.
For instance, what do you do if you have a machine that runs Wayland but you need to run a program that uses X11? Well, there is XWayland that will run an X Server on top of Wayland.
Mir
I also have to mention Mir, which is a competitor to Wayland made by Canonical Ltd. (the people behind Ubuntu). It differs from Wayland in that Wayland doesn’t handle input but Canonical wanted that in there... so they made their own.
Similarly to Wayland, it will be able to run X11 using XWayland... but on top of Mir.
Conclusions
There may come the day where X11 isn't what you want to target. And also in the present there are environments where targeting X11 requires additional libraries.
