raylib bundles every dependency, then limits you to one window

Every dependency is vendored under src/external

raylib ships with no external dependencies: every library it needs is already sitting in the repository under src/external. There is no system library for your linker to hunt for, and nothing to resolve before you compile. That choice is what makes the platform list credible, because the same tree builds for Windows, Linux, macOS, Raspberry Pi, Android and HTML5, and the hardware acceleration is expressed against a fixed set of OpenGL versions: 1.1, 2.1, 3.3, 4.3, ES 2.0 and ES 3.0. Three headers carry most of the weight. rlgl is the OpenGL abstraction layer, written to be usable as a standalone module if you want the GL calls without the rest of the library. rlsw is a software renderer backend that requires no OpenGL at all, which is what makes a machine with no GPU driver a supported target. raymath holds the Vector, Matrix and Quaternion operations. The cost of vendoring shows up the moment something in the bundled code misbehaves: you cannot upgrade a system copy of the offending library, because there is no system copy to upgrade. The fix lands in your own checkout. The licence is Zlib, and the project's answer to every limit below is that you modify the library for your own needs.

Resizing the window stops the render loop, and there is only one of them

Two windowing limits are stated together, and they are the ones a desktop product hits first. Window resize and move stops the rendering loop on platforms supporting a window, and by default raylib gives you a single window with a single OpenGL context, with no multi-window support. No multi-window means no docking panels, no separate settings dialog, no picture-in-picture, and no two independent 3D viewports inside one process. If you hand the window edge to the user, the frame in progress can stall while the drag happens, so the behaviour you actually ship is whatever you decide to do after that stall. A prototype, a game, or a kiosk that runs fullscreen never touches a resizable window and never meets this problem. An editor, an inspector with a 3D preview beside a property list, or any tool with a modal does. No flag is offered for either limit, and the recovery is not documented, so recovering it means modifying the library or moving to one of the forks and alternatives the project points at. Decide which one you are before you design the window layout.

RenderTextures come back vertically flipped

RenderTextures are flipped vertically, exactly as OpenGL provides them, and it is up to the user to draw them flipped to the screen. So the inversion is not a defect waiting for a bug report; it is a line of code you own, in every draw call that targets an off-screen target. The failure mode is quiet. A flipped world looks like a correct world when the scene is roughly symmetric, so the mistake survives a quick look and reaches a reviewer as a mystery. The same frame often needs both paths as well: a raw render texture feeding a postprocessing shader, and an unflipped one for the sprite and UI layer drawn on top of it, which means two drawing routines and two chances to get the transform wrong. If your plan is a minimap, a camera buffer feeding a postprocessing chain, or a reflection pass, price the flip into the drawing layer from the first commit rather than after the shader work is finished. No flag, no render scale, and no helper removes this step.

Text stops at the glyph, with no RTL, ligatures or emoji

Two text limits are stated together, and together they rule out whole product categories. Font rasterization has lower quality than the alternatives built on Freetype2, HarfBuzz or Slug, and text drawing does not support right-to-left scripts, ligatures or emojis. Latin labels in a development tool are fine. A product aimed at Arabic, Hebrew or Persian cannot rely on the draw call to produce the right order, and a consumer interface that shows emoji has no fallback inside the library. This is not a gap a patch request closes quickly, because shaping and bidirectional reordering are a different discipline from rasterizing a TTF. The format list is wide enough to be a real strength elsewhere: TTF, OTF, FNT, BDF and sprite fonts all load, and the examples carry a dedicated text/ directory to copy from. But the width of the format list says nothing about the width of the character repertoire, and the quality gap is stated against specific libraries the project names as its alternatives. Where users type accented Latin, emoji, or a right-to-left language, the answer the project gives is that you modify the library yourself.

The examples are the reference, and the cheatsheet is the whole index

raylib is designed to be learned from its examples, and there is no standard API documentation. The index you get instead is a cheatsheet listing every function in the library with a short description of each, plus a source tree you read directly. The examples directory is organised by subject, with core/, shapes/, textures/, text/, audio/, models/, shaders/ and others/, and the collection holds more than 200 code examples. Two files in there matter most when you start: examples_template.c shows the shape of a program, and examples_list.txt is the inventory. The build files beside them say how they are meant to be run, through a Makefile, a Makefile.Android, a Makefile.Web, a CMakeLists.txt, and two Windows batch files, raylib_compile_execute.bat and build_example_web.bat. The project is blunt about the tradeoff too: no fancy interface, no visual helpers, no debug button. What this arrangement costs is searchability. There is no documentation site to grep, so finding the function that draws a rotated sprite means reading C. For one learner that is the point; for a team onboarding five people it is a tax paid in review comments. This is the whole program shape:

#include "raylib.h"

int main(void)
{
    InitWindow(800, 450, "raylib example - basic window");

    while (!WindowShouldClose())
    {
        BeginDrawing();
            ClearBackground(RAYWHITE);
            DrawText("Congrats! You created your first window!", 190, 200, 20, LIGHTGRAY);
        EndDrawing();
    }

    CloseWindow();

    return 0;
}

The wiki decides how you install, and anyone can edit it

There are two installation paths, and they have different owners. Prebuilt binaries for Windows, Linux, macOS, Android and HTML5 are published on the GitHub Releases page, and raylib is also carried by package managers across several OS distributions. If neither fits, the build instructions live in the project wiki, on separate pages for Windows, macOS, GNU Linux, Chrome OS, FreeBSD, Raspberry Pi, Android, Web (HTML5), plus a general page for working anywhere with CMake. The wiki is open to edits, and readers are invited to fix a platform page themselves or open an issue when a build breaks. That is a feature and a warning at once: the page describing Chrome OS or FreeBSD may have been written by whoever needed it that week, so the instructions for an unusual target are community-maintained while the CMake page is the fallback. The original development environment was Windows with Notepad++ and the MinGW GCC compiler, and the projects/ directory holds ready-to-use templates for several IDEs, with a warning in the same document that some of those templates could require review. Treat a template that fails to open as a known possibility, not as a broken install.

6.0 shipped in April 2026, seventeen months after 5.5

Three releases carry the version history: 5.0 on 18 November 2023, 5.5 on 18 November 2024, and 6.0 on 23 April 2026. The seventeen months between 5.5 and 6.0, and the major version in 6.0, tell you the API moved, and that it moved after a long quiet stretch rather than on a schedule. The repository is not archived, and the last push to the master branch landed on 27 September 2026, five months after the 6.0 tag, so the default branch runs ahead of any binary you can download from the releases page. Pinning is the decision this forces on you. Pin 6.0 and you take the major bump, which means reading CHANGELOG before you touch a single call site. Pin 5.5 and you sit on a tree whose last tagged release is from November 2024 while master keeps taking commits underneath you. The repository also carries HISTORY.md and ROADMAP.md, so the older line is written down, but no deprecation window or compatibility promise between the major versions is stated anywhere, and the examples in the default branch are built against the default branch rather than against the tag you pinned.

Editorial conclusion

Pick raylib for a prototype, a course, a single-window tool, or a project where you already expect to patch the library yourself, since every limit it lists is a limit you would otherwise write around anyway. Skip it for a multi-window editor, an interface with Arabic, Hebrew or emoji, or a team that wants a versioned API reference, because there is no standard API documentation. Before committing, build the project on your exact target OS, read the wiki page for that platform, and read CHANGELOG before moving across the 5.5 to 6.0 jump.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes