The core question isn't "how safe is X" but "what safety gurantees does X make" and "does X actually holds it's promises".

A decently used software downloaded from sourceforge is more trustworthy than unknown code transferred unencrypted over the internet.

Projects like Tor go even beyond that standard and provide deterministic builds to allow independent verification of check sums to make sure that you really are running the code you think you are running.

It's a general question of trusting software.

In this case trusting software that travel unencrypted through the internet. It's a quite easy principle to not trust code that travels unencrypted to do anything. It's really security 101. Don't trust unencrypted communiction channels.

Yes, there might be times when you violate that heuristic and don't get harmed but good security practice is still "Don't trust unencrypted communiction channels".

The idea of saying: "Well I don't have to trust the unencrypted communiction channels because I can do my fancy sandboxing, shouldn't come up." It's not how you think in crypto. In this case, the sandboxing doesn't work.

You could have said: "This is just a fun project, don't put any important private keys into it." You didn't but started arguing that your system can do more than it can.

The fact that you made that promises as laxly makes the belief in the iPhone app providing what it claims also doubtful. Key issues:

1) Do you make sure that the real image never get's written into SDD storage? (There's no way to trustworthy delete files in SDD storage)
2) Do you got the entropy production really right?
3) Do you really provide no traces in the final image?
4) No other bugs that make the crypto fail?

Given the 101 issues with the other project and the way you present it, why should someone trust that you handled those questions well?