Core SDK

When we set out to develop our tech stack, we did not envision a single application that fits all. Such monolithic application result in compromises: as a software gets more complex, the required training time goes up, usability goes down, maintenance cycles get longer, customisations get harder to do and so forth. And even if one only considers a single application, in today’s world there should be a desktop app, a mobile app, perhaps a web app and each of these categories is multiplied by the number of platforms to be supported. E.g. one usually cannot do an Android app as a 1:1 port of an iPhone app, Windows apps use different metaphors as macOS apps.

So instead we built an SDK, a flexible toolkit that provides its functionality in optional components. An application therefore becomes a matter of developing the UI and combining ready made components. This has four main advantages:

  1. The UI/app can be custom tailored for the specific use case. One can reduce the user interface to just the actions required for the specific use case and not overburden the user.
  2. The app can support platform-specific features and combine them with the foundation provided in the SDK. E.g. on iOS, an app can support iCloud syncing although the importer/exporter in the SDK do not even know that technology exists.
  3. One can easily integrate parts of the SDK’s functionality – such as the file importer/exporter – in an existing app without having to use other parts – such as the render backend or input handling.
  4. Extensibility. If the SDK does not support a specific format, the user can write an extension and integrate it into the SDK such that it will be treated as a first-class citizen. Similarly, one can write a custom render backend and the scene graph won’t even know it exists,

The following is a small selection of highlights, more information is provided in the SDK’s documentation.