Please add me to the "I'd really like a stopgap solution that eliminates the pixel doubling" list.
Another way in which the iPhone app interacts badly with an iPad (beyond just looking ugly) is that when an iPad app uses a bluetooth keyboard, you can hide the on-screen keyboard, but when an iPhone app running "in emulation" uses a bluetooth keyboard, the on-screen keyboard stays visible. And another is that the "home button on top" screen orientation isn't working (and since that's where the cable plugs in, I often prop my iPad up that way).
The other thing to remember is, yes, the iPad offers APIs that the iPhone doesn't today, like USB file sync and keyboard support (both bluetooth and dock). But we already know that OS 4.0 is going to bring at least some of that stuff to all these devices, and it's not impossible that there will be an "iPhone HD" with 1024x768 pixels on its display at some point. The (good) reasons to have distinct apps today could easily disappear. By the end of this year, it could be easier to maintain one universal app than two apps that differ based only on their original target hardware. (I think a lot of the developers who rushed out "for iPad" versions are going to be caught in a suboptimal situation once OS 4.0 hits and the devices get full API parity, and I'd hate for OmniGroup to be caught by that. Differentiating the versions as "lite" and "pro" rather than "iPhone" and "iPad" might help prevent that.)
Another way in which the iPhone app interacts badly with an iPad (beyond just looking ugly) is that when an iPad app uses a bluetooth keyboard, you can hide the on-screen keyboard, but when an iPhone app running "in emulation" uses a bluetooth keyboard, the on-screen keyboard stays visible. And another is that the "home button on top" screen orientation isn't working (and since that's where the cable plugs in, I often prop my iPad up that way).
The other thing to remember is, yes, the iPad offers APIs that the iPhone doesn't today, like USB file sync and keyboard support (both bluetooth and dock). But we already know that OS 4.0 is going to bring at least some of that stuff to all these devices, and it's not impossible that there will be an "iPhone HD" with 1024x768 pixels on its display at some point. The (good) reasons to have distinct apps today could easily disappear. By the end of this year, it could be easier to maintain one universal app than two apps that differ based only on their original target hardware. (I think a lot of the developers who rushed out "for iPad" versions are going to be caught in a suboptimal situation once OS 4.0 hits and the devices get full API parity, and I'd hate for OmniGroup to be caught by that. Differentiating the versions as "lite" and "pro" rather than "iPhone" and "iPad" might help prevent that.)
Threaded Mode