u/Sharky_J_Yellowfish

If you still have Simply Plural installed on your iPhone or Android phone, I recommend leaving it exactly as it is for now. Please don’t uninstall it, and don’t clear its app data.

Reason: The app still functions in offline mode after the shutdown. That indicates at least some data is stored locally on the device. I’m currently investigating whether that local data can be accessed and recovered.

I’m posting this here because it touches the same problem that comes up often in DeGoogling and privacy work: users cannot retrieve/export data that has become trapped inside closed apps, cloud-dependent services, or platform-specific storage. When a service shuts down, the safest first move is often to preserve the device state before trying anything destructive.

I want to be very clear: I do not know yet whether recovery will be possible. I’m not announcing a solution, and I don’t want to give anyone false hope. This post is simply about preserving your options while we investigate.

This investigation is effectively two separate projects, Android-based and iOS-based. Android and iPhone store application data differently, and each platform has its own security model. A recovery method that works on one platform may not work on the other, so both need to be researched independently.

If you uninstall the app or clear its storage now, any locally stored data may be permanently lost. If you leave the app installed, there is at least a chance that recovery will still be possible if a method is found.

For now, the safest course is simple:

- Leave the app installed.
- Do not clear its data.
- Try an export from the app if you still can.
- Back up your phone before making changes.

Disclosure: [DEV] I maintain PluralBridge, an open-source project related to preserving and migrating Simply Plural export data. Any tools, documentation, or research from this investigation will be published publicly. I used AI assistance to help edit the wording of this post.

If you still have Simply Plural installed, I recommend leaving it exactly as it is for now. Please don't uninstall it, and don't clear its app data.

The reason is that the app still functions in offline mode after the shutdown. That indicates at least some data is stored locally on the device. I'm currently investigating whether that local data can be accessed and recovered.

I want to be very clear: I do not know yet whether recovery will be possible. I'm not announcing a solution, and I don't want to give anyone false hope. This post is simply about preserving your options while we investigate.

Unfortunately, this investigation is effectively two separate projects. Android and iPhone store application data differently, and each platform has its own security model. A recovery method that works on one platform may not work on the other, so both need to be researched independently.

If you uninstall the app or clear its storage now, any locally stored data may be permanently lost. If you leave the app installed, there is at least a chance that recovery will still be possible if a method is found.

I'll share what I learn with the community as the investigation progresses, whether the news is encouraging or not. Any tools, documentation, or research that come out of this effort will be published in the public PluralBridge repository so the work is open and available to everyone.

If you have experience with Android or iPhone application forensics, backups, embedded databases, or mobile data recovery and would like to help investigate, I'd be grateful for the collaboration.

For now, the best advice I can offer is simple: if Simply Plural is still installed on your phone, leave it there.

I’m working on the high-level design and architecture of a browser app that I am developing to fill the vacuum of a similar app that is closing up shop on July 1. The app consists of a web client front end, a REST API service on the backend, and Azure as the scalable data store and API service hosting.

I am one of the users of the app that is shutting down, so while I have a solid understanding and black-box design, I grossly underestimated the scale. I was led to believe that the subscriber base came in at 100K subscribers, and that the concurrency was below 5K. I have since learned that in fact there are 500K subscribers and concurrency of 10-15K users at any time.

Given these new scaling assumptions and the privacy-sensitive data, I need to rethink scalability and security. In addition, I need to consider that 500K users / 10-15K concurrent users may be the low end. I don’t want to have to come back to the drawing board and do another redesign. I am currently working through the architecture for this system and would appreciate feedback on the user/security model before implementation gets too far along.

The system started as a data-preservation use case: users, such as myself, need to export their data before the service closes down for good. That was actually the easy part. The harder design problem is that the data is sensitive, may not always map cleanly to one individual owner, and needs to be able to address different communities with different rules around consent, shared access, privacy, support roles, and auditability.

The thing I want to avoid is building a simple “user logs in, admin manages everything” model that works for an early prototype but becomes the wrong foundation later.

The main architecture questions I’m wrestling with are:

• I am leaning toward treating each System as the primary security, privacy, import, and audit boundary. Does that seem like the right boundary, or is there a better model?
• How should I model shared ownership when data may belong to a group rather than a single person?
• Would you start with RBAC, ABAC, policy-based authorization, or a hybrid?
• How would you model consent and revocation so that it is invoked when needed, but is abstracted from the business layer of the code?
• What belongs in an audit trail versus ordinary diagnostic logs?
• How do you make audit records useful for event accountability without turning the audit system itself into a privacy risk or “noise pollution”?
• What early decisions would you avoid because they become painful if the system later has to scale?

While this isn’t strictly a medical app — data is private as in any app, but not because of HIPAA — it may need to support health-adjacent or clinical data. I want to avoid treating identity, consent, and auditability as adornments or “flair.”

For people who have designed systems with sensitive user data, multi-tenant boundaries, shared access, or audit requirements: what architecture patterns would you consider first, and what traps would you avoid?