Alcinoe, a Delphi component library that targets the current Florence release

The version constraint is the first thing to check

The README states it in the opening section: Alcinoe is fully compatible with Delphi Florence 13.1, and if you are using an older version of Delphi you should refer to the releases section to find the latest Alcinoe version compatible with your Delphi version. That sentence is the entire compatibility policy, and it has a practical consequence. A component library that tracks a specific compiler release is not a drop-in for a project on an older toolchain, and the fix is not a compile fix but a version choice, which means the decision about which Alcinoe to use is made before you write any code. The release tags follow the same numbering, with 13.1.31 from 2026-09-23, 13.1.20 from 2026-06-20 and 13.1.18 from 2026-06-02, so the version string tracks the Delphi version it targets rather than standing on its own. The repository is not archived, with the last push on 2026-10-08, so the 13.1 line is the active one.

The changelog is the authoritative upgrade guide

The README points at ChangeLog.md for upgrade notes and breaking changes, and it is unusually specific about what can change: from time to time the project may rename units or types, or adjust procedure and function signatures, and the changelog is the authoritative place to see what changed between versions and what you may need to update in your code. That is a real difference from a library that promises source compatibility and breaks it quietly. Renames in Pascal are especially awkward, because the compiler finds them for you at build time, but a changed signature with the same name and arity is a silent behaviour change, and a renamed type that appears in a public property is a change that ripples through your forms. The practical advice is to read the changelog for every version between the one you are on and the one you are moving to, and to treat it as a migration document rather than a changelog. The project also asks contributors to raise an issue or a pull request, with discussions under issues.

A FireMonkey control set, demonstrated rather than described

The showcase in the README is built around demo applications rather than feature lists, which is a reasonable choice for a component library where the visual result is the product. The Alcinoe FireMonkey Controls Demo shows the UI components with advanced features and custom styling, and it is published on Google Play and the App Store so you can try the actual components on a real device rather than reading about them. The Dynamic ListBox demo is the more technically interesting one, because it describes an on-demand data model that creates and frees items dynamically, and it is presented as a solution for smooth performance and low memory usage on content-driven interfaces such as social feeds, chats or news streams. That is a design decision worth understanding rather than copying: a virtualising list that only instantiates visible rows is a different control from a list that instantiates everything, and it changes how you write the data binding. Two applications built with the library are also shown, RockQuest, a rock painting and discovery app, and KisKis, a dating app.

What the repository actually contains

The top level of the tree describes a full Delphi library workspace rather than a single package. There is a Source/ directory for the code, Libraries/ for third-party code, Embarcadero/ for the vendor material, Tools/, Tests/, Demos/ and References/, and an Archive/ directory for older material. The build tooling is Windows batch scripts at the root: BuildAll.bat, BuildJars.bat, NormalizeAll.bat and InitEnvironment.bat, plus a GitHelp.txt. That tells you the project expects a Windows development environment with the Embarcadero toolchain on the path, and the InitEnvironment name suggests the batch files set up the environment themselves. There is also a .gitmodules file, so parts of the tree come from other repositories, and the presence of a BuildJars script alongside a repository that is otherwise Delphi suggests some part of the stack is Java. The library covers more than UI: the repository topics name BSON, JSON, a MongoDB driver and WebRTC, which puts it in the range of a general purpose component set for Delphi developers who want to avoid assembling their own.

The positioning, and what the sponsor tier actually buys

The project states its philosophy in the first paragraph: development should be focused on innovation rather than fighting the constraints of your tools, and every developer deserves the best performance, the freedom to customize, and the power to deliver exceptional user experiences across platforms, while maintaining independence from the dominance of GAFA, which the README spells out as Google, Apple, Facebook and Amazon. That is a values statement rather than a technical claim, and the audience it addresses is specific: teams that have decided to stay on Delphi and want a component ecosystem that does not depend on the big platform vendors shipping first. The Magic Foundation runs an Associate tier with concrete benefits, namely priority support for submitted bugs, with faster triage, dedicated investigation and ongoing updates until the issue is resolved, and the licence is Apache-2.0 with the text in license.txt. For a library you intend to embed in a commercial product, that licence is the easy part: Apache 2.0 places no copyleft obligation on the code that links against it.

Where the risk sits for an adopter

The honest risks are visible in the documentation rather than buried. The first is the version coupling already described, and the second is that the library moves types and signatures between releases, so an upgrade is a project rather than a version bump. The third is the platform of the toolchain itself. The build scripts are Windows batch files and the library is Delphi, so this is a Windows development story, and the component demos exist as real mobile applications on Google Play and the App Store. That is a genuine strength, because it means the controls are exercised on the platforms they target, but it also means you are committing to a mobile UI framework whose own roadmap you do not control. The last point is the boring one that decides most evaluations: this is a component library maintained by a foundation, not a product with a service level agreement, and the support model beyond the paid Associate tier is the issue tracker.

Editorial conclusion

Adopt Alcinoe if you are a Delphi developer on Florence 13.1 who wants FireMonkey components, JSON and BSON handling, and a MongoDB driver without pulling in the rest of a larger dependency set, and skip it if you are on an older Delphi, where you have to hunt for a matching Alcinoe release in the releases section. Verify three things before you upgrade: that the ChangeLog entry for the version you are moving to does not rename a unit or change a procedure signature, since the project says it does that from time to time; that the components you actually use are the ones that have been ported in your target version; and that your build tooling handles the repository's own layout, since the top level is full of Windows batch files for building everything and normalising it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MagicFoundation/Alcinoe on GitHub
4. README
5. Releases