The web app manifest is now a resource

Every installable Phlo app needs a web app manifest, and until this release each one hand-rolled it: a route that sets the content type, encodes the JSON, sets a cache header, plus a link tag in the head.

logbook.tools was the app that made it obvious. It serves eight disciplines under four brands, so it carried four hand-written manifest variants that differed in name, icons and start URL and agreed on everything else. Once the fourth one was written it was clear this was not app code.

It is now the manifest resource. List it in data/app.json, declare the body, and the route plus the correct application/manifest+json serving come along, with %manifest->head ready to drop into your head view:

prop %manifest.body => arr(
    name: 'Logbook',
    start_url: '/',
    display: 'standalone',
    icons: arr(arr(src: '/icon.webp', sizes: '512x512', type: 'image/webp')),
)

Apps with several variants keep their own routes and serve each body through manifest::output(), which does the encoding, the content type and the cache header. The switch in logbook.tools was verified byte-identical against the old hand-written output before it shipped, then adopted by ecms.nu, filesystem.online, teslacam.online, flysight.video and wapps.nu in one pass.

Engine 1.0.1. See chapter 24 of the guide for the manifest and the service worker beside it.