OpenGL has core and extensions.
Extensions start by being proposed by a vendor. GL_NV_sync is such example (it was proposed and implemented by NVIDIA, although other vendors can also implement it if they want).
When an extension becomes really useful/widespread but needs some tweaking (i.e. a different behavior in edge cases, a different interface to accomodate for certain hardware) it may be promoted to ARB (IIRC ARB stands for Architecture Review Board, but don't quote me on that). Which is what happened when GL_NV_sync became GL_ARB_sync.
In some cases, an extension is vendor agnostic but it's not popular/stable enough to be ARB, so its name will say EXT.
Once it becomes really useful it can get into core. GL_ARB_sync became into core in OpenGL 3.2; which means it's guaranteed/mandatory to be present starting from OpenGL 3.2
GL_APPLE_sync (GL ES) & GL_APPLE_fence (GL) are Apple's way of doing it. However since Apple already supports GL 3.2; that means you can use GL_ARB_sync.
Long story short you only need to aim for three:
- GL_ARB_sync (Windows, Linux, OSX, all vendors; unless you don't target GL core >= 3.2)
- GL_APPLE_sync (iOS)
- EGL_ANDROID_native_fence_sync (Android)
The rest are just historic relics that vendors must support so old games can still run.
Good response, that's a general rule of thumb to remember. However, I'm still going to support GL_NV_fence not for Windows, but for Android since the EGL extension requires you to have the EGL context/display setup by your own code in advance. I've always initialized OpenGL ES using Java in the past, and I plan to use SDL2 to initialize OpenGL ES for Android, so I believe it's safe to assume I won't have easy access to the EGLDisplay pointer. Because of this, I will likely use GL_NV_fence since it is supported on Android. At least, it is supported on every Android devices I own with 5.0+ installed. But I will cross that bridge when I come to it.