I believe this is the case of an app that has been removed from the App Store though, which will receive no such support.

Also, trustworthy people do not ask you to trust them.

I am honest and trustworthy, and so if you gave me the pin to your debit card to go buy something for you, I would not mis-use that information.

But because I am honest, I would never ask you to trust me with your pin. If we were standing next to each other at a pos, I actively look away when you start to type so I don't even find it out by innocent accident.

Honest people take the trouble to figure out some way to get a job done without requiring you to trust them, even if you would have, even if it's less convenient for you both.

In fact, I think that one thing is probably the single biggest proof of trustworthiness.

A person or organization that I've never met before and and does not ask me to trust them, is more trustworthy than one that I've known for years and have a long history of good interactions with.

And I would agree it should be outrageous and intolerable.

I wonder if there might be some way for a developer to post their own hashes somewhere, but then there's no good way for an end user to use them to verify their phone.

You could post a web page that reports that Apple has not modified the contents of your app, or a site could do that for many apps, by downloading the Apple-repacked app and checking it, but you could only check the copy of the app that the site downloaded.

It would not prove that Apple didn't modify the individual copy of the app residing on anyones phone.

I don't know the details of ios userspace, but I extremely doubt it's possible for the browser or any other app to read some other apps files and uload them to a site to have them checked. So you couldn't make a 3rd party site that says "check my phone".

Maybe such a report could be made by reading the app out of an unencrypted backup?

Twitter, JSON/ATOM/RSS feeds, apps in privately hosted F-Droid compatible repos...etc

They haven't — which is bad — but they could, and that would be a guarantee. Same as you get with reproducible binary packages in Debian.

On Android, the original security model was that the developer signs the code, preventing a distributor from modifying it (as long as the signature checks are sound).

Apple's system is worthy of complaining about, but you can only bring it up so often. Google taking Android backwards in this regard is worth making a fuss over; but Google is likely to just steamroll through.

https://stackoverflow.com/questions/67067587/app-store-app-n...

I just checked the App Store for the first time since that update. The version number and release date remain the same. The only visible change is the new release text prepended with:

> This app has been updated by Apple to use the latest Apple signing certificate.

Link for those curious:

https://www.macrumors.com/2021/04/16/psa-apple-updating-old-...

If the data was freely accessible, you could at least pull it out and migrate to an app with a more user-friendly business model.

I didn't mention OSX because I didn't want to be overly verbose but yeah any non-free OS at this point has pretty much no respect at all for privacy or user freedom.

Wait, what is Apple doing? Which Apple OS is sending a hash of every file that is opened? And can this be disabled?

The intent seems to be malware prevention, but yes, the implementation is terrible from a privacy perspective. Far better would be a local bloom filter or similar.

But the bit about Windows being more respectful of privacy is not correct, or at least substantially more complicated. For instance, if you run 'full' telemetry, Microsoft can, in fact, pull your documents from your machine and execute things on it remotely, something I've seen no indication Apple does.

https://answers.microsoft.com/en-us/insider/forum/insider_wi...

Here's a rather embarrasing example of data storage rot[0].

> Don't do that, that'll delete all the data as well.

Not necessarily, but it depends on the app.

I use the User Defaults dictionary all the time, for things like operational prefs. I even have an SPM module that I wrote for it[1]. User Defaults gets deleted with the app, unless you do some hacking to sync it somewhere else.

I think that storing as an app file may also get deleted when the app is deleted.

We're not supposed to use that for persistent data, though. Apple provides Core Data for that kind of thing (a mixed bag). Even that needs to be done correctly, like storing using iCloud (Disclaimer: I have not chosen to use Core Data for my apps, so I can't speak to it authoritatively).

Or you could do what I do: Use a server.

[0] https://www.theguardian.com/uk/2002/mar/03/research.elearnin...

[1] https://riftvalleysoftware.com/work/open-source-projects/#RV...

more fun facts: user defaults has a limit to how big it can be. And I also think that your library would benefit from using actual types instead of Any, you can actually define this so long as the value is Codable, generics would make the library nicer to work with instead of requiring the dev to cast the type themselves. You basically just switch out Any for a generic and have the Generic conform to Codable. If targeting an iOS version that is 14+ I would just recommend using the AppStorage or SceneStorage property wrappers.

I'll probably do that. I started it years ago, so it has a lot of legacy. I will probably do a refactor, when I come up for air. A couple of my libs could use a facelift.

Offloading and reinstalling the app fixed the problem!

Came to these comments specifically to find a reason for that (reinstalling an app was not an option because I think the app no longer is visible in the App Store).

Thanks to @xuki, I tried offloading and reinstalling the app, and it fixed the problem!

It's a video about the efforts to preserve an old iOS App that had been broken by new updates and removed from the app store

https://tidbits.com/uploads/2021/05/Setapp-sqlite-640x469.jp...

It's great!

As an application user, I want to start a career as a software engineer, so that I may save my data from a deliberately crippled application.

There is no compatibility or obsolescence problem with ios, ios apps, or most importantly the data in ios apps, that is not artificially created by people who benefit from such problems.

Expecting a 7 year old build of anything to still work is entirely "realistic".