Show HN: An open app development platform for eInk smart screen

Without a first-party backend service, the smart screens would need to store configuration data (e.g. which app is currently active, where to reach the render endpoint) directly on the device. Every time you wanted to change that data, for example to change which app is active on the device, you would need to pair to it with bluetooth or some other means.

Now that I think about it, I actually like the idea of offering this as a fallback option. Hmm... but I don't want to over-promise anything.

But as long as the backend is available, handling configuration changes on the backend is simply a much better user experience. This is why I chose this option as the initial way to go.

I hope this makes some sense, I am happy to answer further questions.

Making this work without a first-party backend would require a way to regularly change configuration data on the embedded device by pairing it with the mobile app. Bluetooth or local wifi access point. That's do-able, but unless you're Apple, it's hard to make that a seamless experience.

I went for the mandatory first-party option because it is important to me to build a device that is super reliable. Nobody wants to debug the bluetooth connection with a calendar. Running the server is cheap enough that I can keep it running for a decade or more, even after I stop selling the last device.

Still, the comments in this post have convinced me that offering this as a fallback option may be a good idea, to address the understandable concerns about obsolescence.