Malloc Simulatorはリジェクトされました。

ここしばらく、別のアプリケーションの開発に重点を置いていたため、報告が遅れましたが、別途申請していたMalloc Simulatorが、今月初めにリジェクトされました。理由は、「iPhoneに対する不的確な診断情報を提供するので、ユーザを混乱させる」というものでした。決して、誤った情報を提供してるつもりはなかったのですが、一般のユーザには誤解を与えると解釈される面はあったかもしれません。
さらに、SysStats Liteで、レビューの長期化を回避するために、実装を取りやめた「メモリ解放機能」とともに共通している点が1つあります。それは、意図的にメモリ不足の状況を作り出し、そのときに起こる内部動作が見えるようにしているということです。
わざと異常な状況を作り出して、その副作用を利用することを目的にしたことが、レビューの長期化やリジェクトに繋がったのではと、自分なりに理解しています。
Malloc Simulatorに関しては、問題を修正して再申請するのは不可能なので、残念なことですが、お蔵入りとなります。
その一方で、これらの過程でいろいろと得られたこともあります。過去に、この日記で説明したことと重複する部分もありますが、ここでもう一度整理してみたいと思います。

SafariやMailなどを終了させる処理について

すでにいろいろなところで説明されていますが、SafariやMailなどのバックグラウンドプロセスとして動き続けるアプリが、RAMを大きく消費しています。それらのプロセスを終了させれば、空きメモリが増えるのは自明ですが、iPhoneOSでは、システムコールを使ってプロセスを終了させることは許可されていません。ところが、何もしていないのに、それらのプロセスがいつのまにか終了していることがあります。いろいろ調べているうちに、フォアグラウンドで動いているアプリがメモリを確保しようとして空きメモリが不足していると、SpringBoardがSafariやMailなどを終了させて、空きメモリを作ろうとすることがわかりました。仮想メモリがないので、swapoutする代わりに終了させるという意味で、それは妥当なことでしょう。
SysStats Liteの「メモリ解放機能」は、その状況をわざと作り出したことによる副作用を利用して、バックグラウンドプロセスを終了させるという方法で実装していました。このときに、一度に確保するサイズが大きすぎたり、メモリを確保するペースが速すぎると、フリーズしたり異常終了するので、ゆっくり少しずつ確保して行くようにしていました。

空きメモリがかなり少なくても異常を起こさないアプリがあるのはなぜか?

当然のことですが、空きメモリサイズより大きなメモリを一気に確保しようとしたり、少しずつであっても、速いペースでメモリを確保してしまうと、異常を起こす確率は高くなります。
空きメモリが少なくても問題なく動くアプリでは、「メモリ解放機能」でやったことと同じような状況が内部で起きていると考えられます。裏を返せば、そういう実装になっているアプリは、異常を起こしにくいと言えるかもしれません。

最後に

実は、Malloc Simulatorは、このあたりのことを説明することを目的に作ったものでしたが、AppStoreに並べるのは適切ではなかったかもしれません。
あと、これらの振る舞いは、ドキュメントで説明されておらず、あくまでも観察した結果をまとめたものになります。将来に渡ってこの通りに動く保証はなく、iPhoneOS 3.0では、変わる可能性もあります、また調べてみたいとも思いますが、開発者の立場から言わせてもらうと、このあたりの標準的な振る舞いは、正式なドキュメントで説明されているとありがたいですね。。。
とりあえず、ここで書いたことが、みなさんの参考になれば幸いです。