Something like this does not exist in any acceptable manner.
You can't just compile it for a different OS, and you can't run it with some sort of "emulation". And to top it all of, cross-platform application solutions usually don't allow anywhere close to the control and integration we would want for good media playback, rather then just some generic web-based UI that those cross-platform things fall back on.
And re-writing the app may not solve all the issues just as much as everyone hopes it would.
The problem with video playback, for example, isn't strictly a bug in our application as such. We produce a fully compliant video stream, we even validated it with Apples owns validation tools and there isn't even as much as a warning, yet when you play it on iOS, the player component we use, which comes from the OS itself, decides to be dumb and load more media into memory then it can handle, eventually crashing due to running out of memory (often quite quickly, sometimes after a few seconds)
I realize for a user this distinction makes not much of a difference, but the problem for us is that we have a fully compliant video stream, which works everywhere else, but Apple decides to just fail and die with their provided video player component. Yes, our stream is not the most common type of stream, since its neither fully "VOD" nor "Live", but there is a specification for this type of stream, and Apple wrote this specification - and their validator accepts it with no complaints. We are, afterall, using a video format developed by Apple themselves.
Re-writing the application would not solve this, unless we get an entirely different video player not based on Apples broken component. And if we had such a thing, we could possibly also just plug it into the current JRemote for iOS.
The alternative is to entirely re-design how we deliver video to JRemote on iOS, which is a very complex process with full of unknown factors (like, "will this work at all") which we won't know about until such a time when we already spent a lot of time working on it so we can test it. We do plan to do this, since if it works it may also help improve other video consumers, but its not a short-term task. In the meantime, Bob is trying to figure out if we can fix it in the JRemote app itself, but it may not be.