| > There are servers needed for the app to work, right? But why? This is described as "a simple app, in which we listed all the recipes we ever prepared, and it would propose randomly three of them. We would then choose together one of them." You could, if you chose to, built/architect that in a way that doesn't require a backend at all. You can use deep link URIs to send a _lot_ of data in a link in an email (like literally gigabytes on iOS). Easily enough data to send each other newly added meals/recipes. You could also encode recipes in QR Codes, so one person enters a new recipe and the other can scan a QR Code the app generates to grab it - you can get about 4kb into a high density QR Code that'll read reliably off a phone screen. Use one of those to maintain the whole meal/recipe database on each device, no backend required. Maybe use a date based PRNG so both ends will pick the same "three random recipes" every day. Send messages between apps as emails with deep links in them, so one user can use the native iOS "share by email" widget to send a "hey, what do you want for dinner" email, with an app generated message with three deeplinks, one for each random choice. Recipient responds by tapping the deep link for their recipe choice, which opens their version of the app - and the app digs the data out off the deeplink URI to pres3ent a "share your choice" button that also uses the native iOS "share by email" widget to send the response back to the first user. Tapping links in emails and sharing via email isn't as "nice" as an app with a centralised database and push notifications, but it also has zero ongoing cost to run and you know for sure the developer has no lever to enshittify the service, and has no user PII or usage data to sell to surveillance capitalists. Hmmm, I wonder if you could do this entirely as a web app? |