To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using Java Native Interface (JNI) in a manner that is similar to those programs written using operating system-specific application programming interfaces (APIs).

Programs that call SWT are portable, but the implementation of the toolkit, despite part of it being written in Java, is unique for each platform.

The toolkit is free and open-source software distributed under the Eclipse Public License, which is approved by the Open Source Initiative.

The original AWT was a simple Java wrapper library around native (operating system-supplied) widgets such as menus, windows, and buttons.

Swing was the next generation GUI toolkit introduced by Sun in Java Platform, Standard Edition (J2SE) 1.2.

They decided to open-source the project, which led to the development of Eclipse, intended to compete against other IDEs such as Microsoft Visual Studio.

In essence, SWT is a compromise between the low-level performance and look and feel of AWT and the high-level ease of use of Swing.

[8] James Gosling, the creator of the Java language, has argued that SWT is too simple, and is a difficult toolkit to port to new platforms for the same reason that AWT once had porting problems: that it is too simple, too low level, and too tied to the Win32 GUI API, leading to problems adapting the SWT API to other GUI toolkits, such as Motif and OS X Carbon.

Since SWT is simply a wrapper around native GUI code, it does not require large numbers of updates when that native code is changed, providing that operating system vendors are careful not to break clients of their API when the operating systems are updated.

[9] This deep integration can be useful in a number of ways, for example enabling SWT to wrap ActiveX objects on Microsoft Windows.

Contrary to Swing, a Display class is necessary to access the underlying operating system, and its resources must be explicitly disposed of when they are no longer used.

This is because SWT is technically just a layer over native library provided GUI functionality, exposing the programmer to native GUI code is part of the design intent of SWT: "Its goal is not to provide a rich user-interface design framework but rather the thinnest possible user-interface API that can be implemented uniformly on the largest possible set of platforms while still providing sufficient functionality to build rich graphical user interface (GUI) applications.

As of 2018[update], SWT supports these platforms and/or GUI libraries:[11] As of March 2018[update], SWT 4.7.3a (and 4.8M6) is officially compatible with the following operating systems (graphic library or similar if explicitly required / processors):[13] Windows XP has historically been supported as have Linux on s390, Solaris 11 (SPARCv9), Solaris 10 (x86_64), HP-UX (ia64), AIX (PPC and PPC64).

[14] SWT was designed to be a high performance GUI toolkit; faster, more responsive and lighter on system resource usage than Swing.

The result has been the Eclipse Remote Application Platform (RAP), which combines the qooxdoo Ajax library with the SWT API.