Hello everybody!
These are the results from the 2019 JUCE User Survey, which was sent out to the JUCE mailing list a few weeks ago.
If you missed out on this opportunity to give feedback, and would like to be involved next time, then please sign up to the JUCE newsletter using the box at the bottom of our homepage https://juce.com/ . Complying with GDPR regulations has shrunk our mailing list drastically, so you may need to re-join if you have not heard from us recently.
The data we are presenting here should be viewed as suggestive, rather than definitive. Weâve bucketed responses into non-paying, Indie and Pro categories, as that makes the results a little more interesting to look at, but there are small segments that are unrepresented here. The shrinking of our mailing list has also introduced some bias, with a number of newer signups being from corporate emails like accounts@bigcompany.com
. This makes it likely that the multiple JUCE seats bought by corporations in this manner donât have a voice. Opening up the survey by making it publicly available could address some of these issues, but we would then have to rely on people self-categorising and preventing people voting multiple times becomes much more difficult.
Anyway, with all of those caveats out of the way, here are the results.
Some questions were open, allowing people to respond however they would like. For these ones the JUCE team has read everything and attempted to summarise any common themes. Some questions only allowed a single choice, whereas some permitted multiple selections.
What made you decide to use JUCE?
The overwhelming majority of people responded with comments along the lines of âstrong cross-platform and cross-plug-in-format supportâ.
People with a Pro license had much more emphasis on GUI cross-platform support.
People who are not paying for JUCE were much more likely to have decided to use JUCE for learning or education.
What is preventing you from using JUCE?
A few people are not using JUCE as they perceive C++ to be too difficult to work with. Otherwise there were remarkably few meaningful responses.
- GUI rendering performance
- DSP libraries
- GUI widgets
- Plug-in features
- Tutorials and documentation
- Build systems integration (CMake etc)
- The Projucer
- Native GUI widgets
- Testing systems integration (Google Test etc)
- Windows support
- macOS support
- iOS support
- Linux support
- Embedded support
- Android support
- Web browser based GUIs
- The JUCE module ecosystem (a module marketplace etc)
- The JUCE module format
- Accessibility
- UWP support
We have a clear leader here, with a handful of other areas jostling for second place. Of the more heavily voted for options people who are not paying for JUCE are more interested in tutorials, documentation and the Projucer, whereas Pro users have a much stronger preference for build system improvements.
Are there any other ways that JUCE could be improved for you?
We had lots of people telling us what they wanted from JUCE. A summary of some common themes is below.
Non paying users:
- GUI design tools in the Projucer
- GUI improvements
- A public JUCE roadmap
Indie:
- Thread safety infrastructure
- Support for precompiled headers
- A GUI markup language
- Billing system improvements
Pro:
- A public JUCE roadmap
- Build systems / JUCE static library
- Fonts and rendering
JUCE users are primarily focussed on desktop apps and plug-ins, but the percentage developing mobile apps and software for embedded devices has increased over the last year or so.
This is a question weâve had some experience with via the forum. Whilst JUCE attempts to remain backwards compatible as much as possible there are times when we need to make improvements to the API itself. This inevitably leads to some grumbling, which is understandable when people are forced to make changes to their code to keep pace with the latest version of JUCE. However, we need to change to move forward. Something weâll be doing in the not too distant future is to make ownership transfers into and out of the API much more explicit, using standard C++ features like std::unique_ptr
. The responses to this question provide a bit of reassurance that the JUCE community supports such endeavours.
Rather remarkably most people who completed this survey have also posted at least once on the JUCE forum. I suspect thereâs a bit of a bias here involving the personality of people likely to have filled in the questionnaire, but itâs a nice validation that a very large fraction of JUCE users have contributed in some way.