Sunsetting LambdaNative

[mgorges]

Dear LambdaNative community members,
After careful consideration, we are sunsetting LambdaNative development due to a lack of community support and competing priorities, making it impossible for our small research team to maintain. Thus, we felt it was appropriate to formally announce that his project is now in need of new maintainers/caretakers and advise new developers to seek solutions elsewhere.

To justify this decision, there are three main reasons:

1. There isn’t enough of a community to support the development. As is evident from discussions in open issues (e.g. see unable to upload to google play #459) and decreasing numbers of commits over the past few years, this shouldn’t be too surprising, but since @clpetersen and @karliwalti left, and @ddunsmuir and I (@mgorges) transitioned to new roles and responsibilities, reducing the accumulated tech debt is beyond our capacity. Importantly, there simply aren’t enough developers who use Scheme or other related functional programming languages, unlike frameworks that use JavaScript, Java, Rust, or Go. Hence, we can't easily bring in trainees or staff to help with this, and neither seems to be a large, broader community.
2. User feedback demonstrates that apps generated with LambdaNative don’t meet their expectations, i.e. apps look ‘dated’ and don’t follow the responsive behaviours and workflows as other native apps do. While there is very limited support for native widgets, such as native-keypad, the look and feel of custom widgets is no longer in line with current design practices, and it feels futile to aim to improve this. Widely available and commonly used alternatives include React, Flutter, Kotlin, which are able to meet most use cases. Band-aid solutions like adding Framework7 or creating hybrid apps, which allow the continued use of code with specific hardware or timing requirements, didn't seem to have much uptake either.
3. There is significant technology debt that requires fundamental rewrites and redesign, starting with the transition from Ant to Gradle for Android builds in 2014, which we have some workarounds for, the deprecation and eventual removal of OpenGL favoring Metal in XCode-26 impacting iOS and macOS in 2025, which may the addition of a compatibility layer like MGL to continue support, and other libraries being outdated, whereby many updates will break things or require new workarounds and testing. For example, while the switch of the default version of Gambit from 4.7.9 to 4.9.2 is trivial and has been available since 2016: a one-liner replacing libgambc with libgambit in modules/config/LIBRARIES, the official current version is 4.9.7, which is entirely untested by our team.

I will continue to push commits we need to maintain some legacy applications (mostly around data collection, sensing and medical device integration), merge pull requests (as long as they compile and run on macOS, but no longer optimize or test on all platforms we officially support: macOS, Win32, Linux, Android, and iOS) and if there are others in the community who wish to take on a maintainer role please get in touch, but otherwise I suggest that new developers look elsewhere for their needs.

Sorry Matthias

[bkmgit]

Happy to implement testing for Linux and Android.

Widgets are more difficult, though https://lvgl.io/ and https://www.tinypixos.com/en/ give some hope.

[bkmgit]

As does https://minigui.fmsoft.cn/

[bkmgit]

Options to avoid direct use of OpenGL:

https://github.com/ocornut/imgui
https://github.com/mikke89/RmlUi
https://wiki.libsdl.org/SDL3/FrontPage

Though no widgets. Using an icon library maybe sufficient.

[bkmgit]

Functional approach does have benefits and is being used in HumbleUI, but this primarily targets the desktop.

Slint is a declarative cross-platform solution, but one needs to write the logic in a different language.

[bkmgit]

GUI Easy for Racket similarly would not target mobile and embedded devices.