Everything you will ever want to know about the remote desktop controllers on iPhone!

I've long been promising a generic roundup on accessing the desktop on other computers (let them be running Windows, Mac OS X, Linux or even some mobile operating systems like Windows Mobile) from iPhones and iPod touches (from now on: iPhones), mostly because there aren't really usable and/or up-to-date all-in-one articles on the subject, let alone comparative ones.

Getting this roundup ready took me a lot of time (over six weeks): much more than I've originally expected. The reason for this was that I've made some really serious bandwidth usage and networking model tests (all involving the making of videos of this process to provide you with as documented a process as possible) so that I can provide you as much objective, comparative information as possible. I have also very thoroughly tested the protocols used by these applications to find out internal weaknesses or lack of optimization. I've also been in really busy correspondence (asking about every single problem / question I've run into in their applications) with most of the authors of these titles. (Too bad the developers of Wyse PocketCloud didn’t respond to my requests and registering in their forums seems to be broken too – I’ve never got a mail from the forum engine with my password.)

Note that if you aren’t really interested in how a given title compares to the alternative remote desktop controllers, you may still find the discussion useful. I explain a lot of less-known things. For example, did you know that the cheap Mocha VNC client supports the discovery of VNC servers in the local network? Did you know that you can make your life much-much easier by using the built-in “scroll wheel emulation” support in most controllers? I not only point out these, but also explain how a given functionality can be accessed; for example, with the scroll wheel, I explain what gestures are needed to access it.

I also provide a much more detailed review of each of the reviewed app than you can find anywhere else. For example, I’ve read through the (U.S.) AppStore user reviews of Wyse PocketCloud. Most of them are pretty meaningless “best ever since sliced bread” and there are also quite a few of “useless cr@p, doesn’t even work”-type of posts. As you may have already guessed, none of these are true: PocketCloud is definitely not the best remote controller but is still far away from being useless. (Interestingly, I could only find one or two real comparisons to the alternatives among the user comments; see that of Dieburnrobot dated 24 Sep 2009) Note that many of even the five-star posts contain false info; for example the one stating connection entries can’t be edited after creation. (Yes they can be; this is what the right arrow on the rightmost side is for in each and every desktop controller clients.)

Should you (still) have questions after reading this roundup, let me know. Feel free to post a (public – do NOT send me any private mails because they don’t benefit your fellow iPhone users. I will simply ignore these kinds of mails) follow-up or question. I’ll more than happy to answer them. Do you have a problem with configuring a given remote controller app? Let me help you!

No pure media controllers!

First, let me point out that I've "only" reviewed and compared "full" remote control solutions in here. This means I have not included strictly multimedia-only controllers; that is, ones that only let for controlling multimedia playback but nothing else. They may be reviewed in some of my forthcoming roundup. That is, if you "only" want to remote control, say, your desktop Windows Media Player or run your scripts when initiated from your iPhone, you may want to wait for that article. (It's, generally, much easier and much less resource-, including bandwidth, intensive to remote control a multimedia app or server-side scripts with a dedicated application than via a generic remote access application. That is, you won't really want to remote control for example your WMP via, say, VNC client or LogMeIn.) (Just to have an idea of how these remote media controllers look like on another, competing platform, Windows Mobile, you might want to check out my dedicated article).

As with all my roundups, a lot of information can be found in the quite long comparison and benchmark chart and it’s there that you can quickly check for the existence of a given feature (for example, audio transfer) and instantly see which of the applications support it. This kind of comparison is definitely more complicated (but, of course, not impossible) if you would only need to rely on the main article text (the one you’re reading).

1. Introduction

The aim of remote access applications is the same: to provide you access to your desktop computer(s) (in here, I'll refer to them as "remote desktops") when you're away from them. You can control them from your client computer (or, in this case, iPhone) directly. That is, you can see the remote desktop on your (local) client computer (iPhone) as if it were running locally, right on your client and not somewhere else on the Internet far away. With some really advanced clients, you can also do direct file transfers (this, as of this writing, still isn’t supported on the iPhone), clipboard synchronization (for example, if you have a loooooong e-mail address in a local file / database on your local client computer, you only copy it to the local clipboard and, then, just synchronize the clipboard so that it also becomes available on the remote clipboard; this way, you can avoid having to re-enter it on the remote desktop by hand; unfortunately, currently, only clipboard synchronization going in the other direction is supported on the Apple platforms), remote administration and (at least on some other mobile platforms) Personal Information Management (PIM) data (calendar, contacts and even mails) access in addition to "plain" remote controlling.

There are, basically, two kinds of remote access / control applications: 1. Web-based ones and 2. non-Web based ones.

In general, the former

1. are much easier to set up on both the server and the client (except for, maybe, RDP-based, already built-in solutions like the RDP-based "Remote Desktop" in Window, where all you need to do is just enabling a checkbox to make remote access allowed). In most cases, when you plan to install the server of a Web-based remote control app on your desktop computer you want to access remotely, you just navigate to the homepage of the developer and let it download a server to your desktop PC, which, then, you just install (the latter is, in most cases, just clicking the "next" button and entering the username and/or password you'll want to use). The client install is equally easy: just select and install the client from AppStore. (While on Windows [and Windows Mobile] client you just navigate to already-registered desktop server page and, upon trying to make it work, the system will notice your client still doesn’t have a client; it’ll immediately auto-install one.)
2. give complete freedom to the subscribers in that they connect to their remote desktops really easily, independent of the networking model of their desktop (that is, these services even work over firewalled and/or severely restricted connections). All you need to do is making sure your computer you want to remotely access has Internet access. No need to configure any firewalls or to even know the actual Internet address of your computer, the central Web server takes care of all this. All you need to do is logging into your central account in the central Web server: it will connect you to your remote desktop.

That is, for a non-IT-professional, these kinds of remote access solutions are preferable to the other group, which, in general, requires manual server download, installation, configuration and, in cases, tuning. This is why, first, I discuss the first group.

1.1 Web-based end-user applications

1.1.1 LogMeIn Ignition

One of the most recommended remote desktop controller applications is LogMeIn Ignition, which is Web-based. It, basically, has two versions: the free LogMeIn Free, which only offers remote control (with all the advantages of web-based access: firewall support, on-the-fly, easy client install requiring almost no user intervention or setup etc.) and LogMeIn Pro, which, in addition to remote controlling your desktop, also supports file transfer (with desktop clients, bidirectional; with iPhone clients, not any kind of file transfer is supported) and, for non-iPhone clients,

1. Remote Printing to print remote files locally, on the printer attached to client
   
2. File Sharing to easily share large files, without uploads (similar to, say, MegaUpload)
   
3. Guest Invite to share the desktop for remote collaboration
   
4. File Synchronization to synchronize files & folders of the client and the remote desktop
   
5. Security (256-bit SSL encryption)

As can be seen, the iPhone version, unfortunately, is decidedly worse than the desktop PC one - as is the case with, unfortunately, most of the reviewed applications. (Almost none of them makes full use of the capabilities of the protocols – for example, file transfer.)

 

Verdict

A well-behaving, stable, useful application with all the most important goodies LogMeIn has (but without audio / file transfer or clipboard synchronization). If the networking model is very restrictive and you simply can’t use alternative remote desktop controllers (most importantly, Jaadu RDP or VNC), this title should be the way to go.

Note that the iPhone client works with both the free and the pro subscription versions. As the client doesn’t support file transfer at all, you will want to stick with the free one – unless you want to access the same computer using more capable (desktop Windows or Windows Mobile) clients. Paying the yearly / monthly fee for the Pro version is pretty much useless if you can’t make use of the advanced features.

1.2 Non-Web-based applications

There are several applications that, unlike the previously reviewed ones, don't use a central Web server for keeping tracks of a computer and help clients log in.

Some of them are based on the RDP (Remote Desktop) protocol (used by Terminal Server / Services in the Terminal Services / Server line of Microsoft Windows and Remote Desktop by Windows XP Pro / Vista); some of them (VNC clients) on Remote FrameBuffer (RFB ) and some use a proprietary one. In the following, I devote two subsections to the first two (RDP and VNC) cases. (I completely ignore the third as there is only one and pretty much incapable app for the iPhone with a proprietary protocol not utilized by anything else.) There are major differences between these three cases, which is worth elaborating on because they have a direct, at times, unwanted effect. This also has an effect on the behavior of all the applications based on these protocols. For example, RDP-based remote controlling locks the current user out of the desktop (making any kind of co-operation impossible between the remote and the local user), don’t allow for seeing extended desktops and, with some lower-quality clients, force the desktop to switch to using lower resolution.

First, how these protocols compare? I've constantly been asked on these; therefore, I elaborate on this question a bit more.

First, the RDP protocol differs a LOT from all the other protocols:

1. unlike the most important alternative, VNC, it can only run on Windows desktops – no Mac OS X, Linux or even Windows Mobile.
2. it’s already built-in (unless you have the cheapest and lowest-end Windows versions) – no need to install anything else
3. When a remote session is active, the terminal can't be used by anyone - they will be locked out
   

While RDP has its drawbacks, it has advantages too; in addition to the above-mentioned availability in many Windows operating systems (without your having to install any server component - you only need to enable them with a single checkbox tick), the really good bandwidth usage. Therefore, you may really want to compare its disadvantages and advantages to those of the alternatives - in a lot of cases, RDP may be the best solution.

Second, the second most important protocol is RFB, which forms the foundation for VNC (Virtual Network Computing) clients. When properly configured, with the proper clients, VNC (from now on, I use "VNC" to refer to remote controller products using the RFB protocol) can be even more bandwidth-friendly than the above-introduced Microsoft RDP protocol. VNC clients don't suffer from the above-listed problems of RDP either and, therefore, may be a much better choice than the built-in RDP under some circumstances (for example, when you don't want to lock out the current user while you remote control the desktop). They, on the other hand, require a separate one-time server install and, should you fine-tune the server-side options (e.g., scaling), they also require you to gain some familiarity with the server-side config utility.

1.2.1 RDP-based applications

1.2.1.1 Jaadu RDP 3.0.1

Without doubt the best RDP client for the iPhone right away. It supports true full screen (unlike many of the alternatives), sound transfer, clipboard synchronization (both from the desktop to the iPhone and not in the opposite direction), full (!) Unicode keyboard support, the full set of PC keys, the best cursor mode (allowing for both reliable selection of even the smallest icons and hovering cursor to see pop-up windows), and, with compatible routers, even port forwarding autoconfiguration etc. In addition, it’s actively been worked on and the developer is very responsive and quite often releases new versions. He’s also working on some goodies for the new version.

The biggest disadvantage of this application is the pretty hefty price tag ($30). Nevertheless, if you plan to access your desktop via RDP (again, before going for a specific program, compare the advantages and disadvantages of each of the three protocols; that is, VNC, RDP and LogMeIn!) quite frequently, I think this is the client to go for.

1.2.1.2 Remote Desktop by MochaSoft 2.1

This application comes in two flavors: the free lite version (which lacks all kinds of elaborate keyboard / mouse modes: it only lets for left clicks and pressing keys already available on the standard iPhone keyboard) and the commercial one.

Unfortunately, as is the case with all the other programs in this review (except for Wyse PocketCloud, which I consider a little bit overpriced for what it’s currently capable of), you generally get what you pay for. Even if you purchase the commercial version, you won’t have, for example, independent cursor control (the only way to activate something is directly tapping it, which has all its problems unless you zoom fully in, which also takes time and effort) or even full screen without any icons.

Every cloud has a silver lining, though: if you come from Windows Mobile, you will certainly welcome the new RDP engine not showing any disastrous consequences of for example smooth scrolling. The latter has certainly rendered the Windows Mobile version pretty much useless and a data use hog.

1.2.1.3 iRdesktop by Thinstuff s.r.o. 1.0.1

This is a free RDP, really rudimentary app. The only advantage it has over the most recommended RDP client, Jaadu RDP, is its ability to control more than one remote desktop at the same time. In this regard, only Carter Harrison’s WinAdmin (which is equally non-recommended) is comparable.

Otherwise, if you don’t really need to control more than one remote desktop at the same time, think twice before going for this title – again, you get what you pay for.

1.2.1.4 Wyse PocketCloud 1.0.1

This RDP client is pretty much in the similar price range as the most expensive apps in this roundup: that is, the Jaadu twins and LogMeIn Ignition. Unfortunately, it’s way less featured.

The only real advantage of this title is the built-in think Web clients which can be pretty easily compared to that of SkyFire on both Windows Mobile and Symbian. The latter allows users access, among other things, full Flash, Java applet etc.-based Web pages etc. and is great fun.

However, PocketCloud’s solution, when compared to SkyFire, severely lacks: it has no audio transfer (that is, you won’t hear a video, should you want to play it via a PocketCloud session) or favorites. It doesn’t have tabs either. Furthermore, the desktop-side component it requires has some CPU usage even when it’s inactively running in the background. (When operating on battery, every single percent counts.) I think this part of the app should really be enhanced with at least audio transfer and some kind of a favorite support.

I’ve made a video showing the mini-Web browser in action; it’s available HERE.

Note that it also has another unique feature: support for VMWare. I didn’t test this; some of the AppStore users love it.

 

1.2.1.5 WinAdmin by Carter Harrison, LLC 1.1.1

This RDP client is another one not really recommended – unless you need a tool that allows concurrent access to more than one remote desktops and, for some reason, you don’t want to use the free iRdesktop by Thinstuff s.r.o.

Nevertheless, of the two, I’d definitely go with iRdesktop by Thinstuff s.r.o. instead, should you really need this kind of functionality.

1.2.2 RFB-based (VNC) applications

Note that, after quickly listing the four different solutions, I also explain what needs to be known about different servers, encodings and server-side scaling. This knowledge will be essential in sometimes drastically decreasing the bandwidth needs of the applications. At first, I introduce the applications themselves.

1.2.2.1 Jaadu VNC 3.0

As with the case of RDP, it’s also Jaadu’s product that is undeniably the best among VNC clients – provided you don’t want to make use of partial screen transfer (of which I’ll talk later), which only VNC Pocket Office by Chillingo Ltd is capable of. The same stands for server scaling, which is only supported by two other clients.

Otherwise, it has some excellent features; for example, remote desktop-to-iPhone clipboard synchronization, an excellent cursor mode, easy switching (two-fingered swipes up/down) between full screen and standard view (other VNC clients don’t support full screen at all or, with them, it’s way more tedious to switch between the two modes) etc. Also, it’s promised to work OK with huge remote desktop sizes (for example, with ones utilizing double monitor configurations) on older iPhone models with 128 Mbytes of RAM only. (On my test 3G S, I haven’t encountered any memory problem on any of the tested VNC clients [or LogMeIn] in the high-resolution double monitor test.) The developer, along with some other goodies, also promises a gmail-based solution for truly network topology-independent access - something like only LogMeIn can provide. Let’s see how it works out.

Currently, if the (rather high) price and the lack for server scaling / partial screen transfer isn’t a problem, this is the most recommended VNC client.

1.2.2.2 Mocha VNC by MochaSoft 2.1

This client is pretty much similar in capabilities to that of the RDP client of the same company. It too has a free lite version with radically reduced features.

If you want a strictly free VNC client (and the lack of right clicks and the like isn’t a problem), you can safely go with the free version of this app. If, however, you would prefer the commercial version, let me point out that VNC Pocket Office by Chillingo Ltd is definitely more featureful and is more recommended – and is even cheaper.

1.2.2.3 VNC Pocket Office by Chillingo Ltd 2.2

This title is definitely superior to the Mochasoft VNC client I’ve elaborated on in the previous section – and, in some respects, even better than the (much more expensive) Jaadu VNC. Nevertheless, if you do have the money and couldn’t use the two extra, but not commonly used features (support for scaling and partial screen transfer), go for the latter title, particularly if you plan to use if often.



1.2.2.4 VNC servers

Now that I've quickly elaborated on the different VNC clients, let's take a look at the server side. Unlike with the Web- (LogMeIn Ignition) and RDP-based solutions, you must manually install a server on your desktop PC you’d like to access.

There are several VNC servers out there with slightly different capabilities. Some of these capabilities are, at the time of writing, unfortunately, exclusive. This means, for example, if you need (Western – other languages aren’t supported) accented characters, you’ll need to go for UltraVNC. On the other hand, if you have a double monitor configuration, you’ll need to use TightVNC instead. The latter, however, doesn’t support international characters on the iPhone (while it does on other platforms; for example, Windows Mobile).

In general, installing VNC servers is pretty straightforward. You install the product and just start the server in Start Menu / Programs on the Windows desktop PC. When it's running, it'll display an icon in the system tray (systray), through which you'll have access to the configuration dialog, user list and can even shut down the service.

1.2.2.5 VNC Bandwidth usage fine tuning

With a capable VNC client / server combo, you can fine-tune the bandwidth usage and force it to be really small. This, however, requires you to know what options there are.

First, there are so-called "encodings" used with VNC. Some of them really love wasting bandwidth; for example, RAW, which, as you may already have guessed, just sends over uncompressed raw screen data and, consequently, takes orders of magnitude more bandwidth than protocols utilizing compression methods. Well-known, high-bandwidth and, therefore, to-be-avoided encodings also include RRE and CoRRE.

The widely used Hextile (the best available with the above-introduced, free, not recommended three "legacy" clients) is already a bit better but still consumes a lot of bandwidth and should, therefore, be avoided. With some additional compression (Zlib hextile, for example) it becomes pretty usable, bandwidth-wise: it will "only" consume about three times more bandwidth than RDP or more advanced (for example, JPEG-based) VNC encodings. Of the Pocket PC clients, only Mocha (and, of course, PT PO) supports Zlib / ZRLE compression.

Finally, Tight with or without JPG (the best, most space/bandwidth-efficient way to encode images) is by far the most effective VNC encoding. Interestingly, all iPhone VNC clients state they would prefer not to be used with Tight – as opposed to (decent) clients on other platforms (for example, Windows Mobile).

Note that on the iPhone you don’t need to be afraid of these settings – all clients are configured to use the (by the developers) most recommended and pretty good ZRLE; there is no need to set it yourself.

1.2.2.5.1 Server-side scaling issues

In addition to choosing the right encoding (at least Zlib / ZRLE - again, note that Tight (JPG) would deliver better results but the iPhone clients, for some reason, don’t recommend using it), you should also know what server-side scaling is and how you can fine-tune it to further reduce bandwidth usage.

First, remote desktops are, generally, bigger than the resolution of your iPhone screen. For example, two of my high-end IBM Thinkpad notebooks have UXGA (1600*1200) screens, which is far larger than even the 480*320 (HVGA) screens of iPhones. If (and only if!) you don't zoom into this image fully and scroll around the page so that a pixel on the remote desktop equals to a pixel on the iPhone (or, even more, should you want / need to use touchsceen tapping), you can make use of clever remote desktop-side (!) rescaling of screen images before (!) returning them to the client. Just imagine: if you would like to just navigate on a 1600*1200 desktop with your iPhone screen, by instructing the server to resize the screen images returned to the client itself, you can save a LOT of bandwidth. For example, if the server uses the rescaling factor 2, then, it'll send over a 1600/2 * 1200/2, that is, 800*600 images, which are still bigger than the iPhone screen and, therefore, only result in very small image quality degradation - while delivering considerable bandwidth usage decrease. Using the scaling factor 3 with the above-mentioned UXGA desktops, the full screen images sent over will become 1600/3 * 1200/3; that is, 533*400 in size. Of course, this will introduce some kind of blurriness - but the data usage decrease advantage will be considerable.

Note that, currently, VNC servers are only capable of using integer scaling factors - that is, you can't make them return for example strictly 480*320 (HVGA) images of a 1600*1200 (UXGA) desktop (1600 divided by 480, that is, 3.333, isn’t an integer). This is why you can't just tell them "with a UXGA remote desktop and a VGA client, use the rescaling factor 3.333 so that you get the most optimal result with the best possible image quality".

You can find some real-world benchmark results to show all this in the chart. (See more info in the discussion of the chart.) Server-side scaling, while it does introduce some kind of blurriness (example screenshots of this later), really reduce the used bandwidth: with a two-factor server-side resizing, about 35...45%.

Finally, some examples of the quality degradation (all taken on a VGA Pocket PC; they would be pretty similar on an iPhone. Pay special attention to the increased blur on each consecutive screenshot.):

1:1
1:2
1:3
1:4

 

As can clearly be seen, the quality slightly degrades even at the rescale factor of two. That is, there is a clear tradeoff between quality and speed. You will want to use / configure the server-side scaling feature in the VNC clients actively supporting scaling (currently, VNC Pocket Office by Chillingo Ltd and Mocha VNC by MochaSoft) that directly allow for configuring. In VNC Pocket Office by Chillingo Ltd, this can be very easily done under “Server Scaling” (the last-but-one slider in the configuration dialog). Note that, on the server configuration dialog (right-click the Ultra / WinVNC icon and select Admin Properties), it’s accessible under “Default Server Screen Scale” – this is the only way of setting this on Mocha VNC by MochaSoft, which, as opposed to VNC Pocket Office by Chillingo Ltd, doesn’t have a scaling setting in its configuration menu. Note that if you modify the default “1” in Ultra / WinVNC, Jaadu VNC will just not connect – it’ll just go on showing “Connecting”.

2. Feature / benchmark chart

It's available here. Due to sheer size, I couldn't include it in here - sorry. You'll need to click the link.

2.1 Explanation for the chart

Compatibility (I’ve tested it on): I’ve listed the operating systems I’ve tested the apps on and, in parentheses, the OS’es they are declared to be compatible with. As you can see, as of this writing (09/30/2009), there is only remote desktop controller not compatible with the latest-and-greatest desktop Windows operating system version, Windows 7: Remote Desktop by MochaSoft 2.1. However, the new, compatible version is promised to be approved in 1…4 weeks.

Accessing more than one machines at the same time, in parallel?: two of the clients (namely, iRdesktop by Thinstuff s.r.o. and WinAdmin by Carter Harrison, LLC; both RDP clients) support keeping up a connection to more than one desktop. The (otherwise, much more recommended) apps (the two Jaadu apps, LogMeIn Ignition and VNC Pocket Office), unfortunately, don’t – with them, you need to disconnect from the first desktop first to be able to connect to the other one.

Control mode: Touchscreen (needs major zoom-in to be absolutely sure you do hit the icon you wanted to tap) / Cursor (you can control a self-standing cursor, making it far easier to hit anything): as is explained in the description of this row, there are, basically, two control modes in higher-end, more expensive remote controllers. The (in most cases, default) mode allows for controlling an on-screen cursor (generally, with an offset from the current touch position so that you do see the cursor during scrolling) and only activating anything (that is, sending a left click) when, after you’ve finished scrolling, you quickly tap the screen anywhere.

This lets for far better controllability than the other, Touchscreen approach almost exclusively used by lower-end and free apps. You won’t need to zoom in in order to be able to be absolutely sure to, for example, activate the right one of the consecutive Windows window minimize / maximize / close icons: you just drag the cursor over the right one, release the touchscreen and, then, tap it once to issue a left-click. With a control method not applying visible and draggable cursors, this is far more complicated and error-prone because of the inherent lack of preciseness of tapping with human fingers.

Bandwidth usage group: I've made some really extensive tests to find out how each and every remote control solution uses bandwidth. These tests are, therefore, of paramount importance if you

1. Have a very expensive (for example, mobile phone-based without an unlimited data plan) connection, where every byte counts
2. Have a slow connection and would, therefore, welcome the fastest possible solution

To reliably and comparably (!) benchmark the different remote controller solutions, I've done the following:

1. I've always reset the data counter on my iPhone before connecting to the desktop – and, after the test, I’ve read the current data counter (making sure it was also visible in the video I’ve taken of the entire process).
2. I've switched the desktop resolution to 800*600 (SVGA) on the notebook
3. I've automatically scrolled through a looooooong test HTML document (my well-known Pocket PC Gaming Bible Part I without the PPCMag header/footer), with disabled smooth scrolling by default (in another tests, I've enabled smooth scrolling to see how he protocol handles smooth scrolling events to increase the data transfer efficiency). To automatize scrolling (and also to reliably find out the rendering time of each and every page), I've used My Macros V2.8 by GoldSolution Software. With this application, it's very easy to simulate user input (in this case, pressing the Page Down key) and waiting for a pre-determined time (please also see this screenshot). The latter also helped me to find out the minimal delay between subsequent page down events for the current page to be completely rendered by the client. The iPhone clients (as opposed to Windows Mobile ones) were pretty similar in graphics rendering speed; that is, the 1-second delay I’ve generally used (and is clearly visible in the test videos) suited them all.

Note that, during these tests, I've paid special attention to not letting the notebook do any additional animation (for example, animated icons in the system tray or MSN contacts / Outlook mail notifications - I've disabled all these applications) and also made sure the mouse cursor was also hovering over the title bar of Internet Explorer, not displaying any additional tip bubbles and not moving at all.

Also note that I've often re-run the tests in order to be absolutely sure I get the right figures. I’ve separated these results (and the videos I’ve taken of the tests) by semicolons (.

In subsequent tests, I've repeated the test above, in a slightly modified environment; for example, I've switched on smooth scrolling and/or modified the color depth (in the client); all this to see how modifying these parameters affects the bandwidth usage of a given remote control solution. These additional tests delivered a lot of important results, which I've also elaborated on in the tests.

In most cases, the uplink (uploaded) data use being much smaller than the downlink (downloaded) data, I didn’t bother documenting the former. In these cases, there is only one data. For example, in the “Partial view optimization” row, with LogMeIn, it’s 4.1 Mbyte. In cases where I deemed it necessary to also jot down the uplink data use, I’ve separated it from the (much higher) downlink data use by a slash (providing the uplink benchmark result first), like in the case of VNC Pocket Office by Chillingo Ltd in the same row. There, 404k / 1.5M means the particular test resulted in the data use figures of 404 kbytes up- and 1.5 Mbytes downlink.

Note that in the non-scrolling tests, when I didn’t use a timer to stop, say, after 9 minutes (to be still able to upload the video documenting all this on YouTube), I’ve also provided the time interval of the tests. For example, “10 minutes: 22k/111k (8-bit)” means that, when running a 10-minute test, the up/downlink data use was 22 and 111 kbytes, respectively.

Nothing happens: The first test I’ve done was testing the data usage of the apps when no changes are visible. As you can see, the RDP-based solutions and LogMeIn are somewhat behind the VNC clients.

Speaking of VNC, it’s also here that I’ve tested the data use caused by different screen refreshing parameters of VNC Pocket Office by Chillingo Ltd. (The lower the value you can set when setting up an account, the more quickly the desktop controller app fetches the current state of the screen from the server.) As you can see, if you decrease this value to 0 (that is, there isn’t any delay between requested pages) from the default 0.5 second (assuming you use the “3G” default template), the data use becomes about tenfold. Nevertheless, this doesn’t mean you should never decrease this value to 0…0.2 – later, in the “Scrolling” row, when there is major screen acitivity, the overhead caused by the constant polling in no way amount to a tenfold data use increase.

 

Cursor blinking: my second test was finding out what data use a blinking cursor results in (as opposed to the case of absolutely not happening anything). As you can see, the data usage figures are definitely larger than in the first case but none of the tested protocols exhibited any severe bugs resulting in, say, data use of an order of magnitude more.

Scrolling: this is the test I’ve elaborated two bullets above.

General differences in scrolling bandwidth usage: smoothing: starting with this row, I provide you with information on how the data usage can be decreased by, for example, disabling smooth scrolling in the Web browser (here, I’ve used Internet Explorer for testing; however, other Windows browsers also support this). All these tests are based on the scrolling tests run with different parameters.

In the particular test of this row (smooth scrolling), there doesn’t seem to be much difference.

Color depth: when you, basically, work with textual data, there doesn’t seem to be much difference between 8- (256 colors max.) and 16/32-bit (65500 / 16 million colors) modes. That is, you don’t need to disable 16- or 32-bit color modes to decrease data use if you work with text most of the time.

Note that there is only one exception: if you switch to grayscale mode in LogMeIn (which turned out to be much more usable and pleasant to the eyes than I had predicted; see the video if interested), the data use will be halved. (This is a definite step forward from the results I’ve measured almost three years ago when publishing the Windows Mobile-specific version of this roundup.)

Partial view optimization: as has already been mentioned, only one of the reviewed apps (VNC Pocket Office by Chillingo Ltd) support data use reduction in a special mode that only transfer part of the entire desktop. This can be clearly seen from the data usage benchmark data provided here: while the data use of the other apps are almost exactly the same when scrolling through the standard Web page zoomed in the upper left quarter of the browser’s active area, VNC Pocket Office resulted in about a two-fold data use decrease (404k / 1.5M as opposed to 348k / 3.1M; all this allowing no smooth scrolling, 0 delay, 8bit color and no scaling).

This feature can become highly useful in cases of, for example, remotely browsing web pages full of quickly changing Flash animations. You, on the client, zoom into the text so that the advertisements are invisible – and, by this, you greatly reduce data use.

Connection model / protocol? : here, I just list the protocols the tested remote controllers are based on. In this test, there are only three of them: RDP, VNC and LogMeIn.

LAN (internet-less)?: this row is protocol- and not client-specific. However, I’ve found it necessary to mention it in the chart as well as it’s a very frequent request by iPhone users to have a solution that can be used to directly access one’s desktop in the same for example Wi-Fi local network, without the entire communication being done through the Internet – and, most importantly, the probably very slow home (A)DSL modem.

As you can see, if you do need a direct connection between your desktop computer and your iPhone (which, again, may me way faster than a connection through your Internet connection), you will want to prefer clients utilizing the RDP or the VNC protocol – that is, not LogMeIn.

Able to log in when the user is not / no user is logged in (can you register the server as a Windows service?)?: a decent remote controller application should also (automatically or configurably) register itself as a system service so that it's started even without any Windows user's logging in. This is of tremendous importance with all password/login-protected desktop PC's. You shouldn't rely on not rebooting your desktop either to avoid the need for this: there will inevitably be for example critical XP updates that do reboot the PC. That is, if your desktop Windows you'd like to remotely access doesn't log in automatically, make double sure you configure your remote controller server to be started as a service. Fortunately, all of them can be configured this way - most of them even defaults to being started as a service.

Dynamic IP announcement support?: Should your remote desktop be connected to the Internet via a, say, DSL line, your IP address will most probably change, in general, once a day. With built-in dynamic IP announcement support, you can very easily announce your IP every, say, 15 minutes. You will, then, be able to access this IP stored on a central server and accordingly set the address to connect to in the remote client.

Note that you will still be able to use your remote desktop on a dynamic IP with remote control software not supporting dynamic IP announcement because there are a lot of third-party software (not related to remote controlling) that do the trick. However, the easiest is to have support built-in.

Unfortunately, unlike on Windows Mobile (where there are remote control servers that do announce their IP address), currently, no iPhone remote desktop apps exist that do this. Nevertheless,
[*]the developer of Jaadu promise some kind of such a service will soon be implemented, making use of Gmail
[*]the no-ip service works just fine and, if you also install the official no-IP DUC client on your desktop, you will never see any difference between LogMeIn (which does this automatically) and any VNC or RDP client (which don’t). You just enter your no-ip.com address into your iPhone once and, after that (assuming the no-IP DUC is always active on your desktop) it will always be able to connect.

Note that you will still need to configure your router (if you don’t directly access the net) to pass the incoming port requests to your desktop. Jaadu’s desktop-side apps do this automatically if your router does support this kind of auto-configuration.

Service on desktop: Additional memory usage: here, I've elaborated on the memory usage of the desktop-side services (if any). As can be seen, none of the server applications are memory or CPU hogs. The only exception is Wyse PocketCloud’s WyseBrowser.exe (if you do want to use the Web browser), which a bit memory- and CPU-hungry; the latter even when there's no active RDP session. Hope this will be fixed.

Easy to stop/ restart service (no need to e.g. kill it from task manager / restart the desktop)?: here, I explain how the server-side listening services can be en/disabled and/or started / stopped. Fortunately, it’s easy with all of the reviewed ones – unlike with, say, CrossTec (and restarting GoToMyPC once you kill it) you may have seen if you come from Windows Mobile.

Misc: Landscape support? : all of the apps are capable of making use the landscape mode; some even offer orientation locking to avoid accidentally changing back to Portrait.

Dedicated chat support, using a simple textual protocol to communicate to greatly simplify chatting between the remote user and the local terminal user?: on other (even mobile – see Windows Mobile) platforms, some remote desktop applications support the use of dedicated chat windows, which aren't (necessarily) part of the desktop. With these chat windows, you the remote user can communicate with the user sitting in front of the remote desktop using dedicated chat windows. Supporting these is advantageous in two respects:

1. they are far more responsive than simply, say, using a, say, file edit window / Word document to communicate because the characters you enter, as you do it in a local (non-remote) text input component, are echoed right back to you.
2. When two users try to chat via, say, an open Word document, surely "race for controlling the cursor" events happen.

Unfortunately, there isn’t such support on the iPhone – yet(?).

Double monitors (extended desktops; VNC tested with UltraVNC and TightVNC)?: of the RDP – VNC – LogMeIn trio, both VNC (assuming you use UltraVNC) and LogMeIn support extended desktops using external monitors. Here, I’ve listed the results of my tests.

As can be seen, all VNC clients (and LogMeIn) support extended desktops.

 

Full screen support?: unfortunately, not all clients support full screen. Some (namely, Wyse PocketCloud 1.0.1), while they hide most of their GUI components upon pressing the “Full screen” icon, still leave the standard, system-wide status row at the top of the screen. Some (namely, MochaSoft’s both apps and LogMeIn) don’t offer any way of hiding their (somewhat transparent) on-screen icons. And, finally, some of them (iRdesktop and WinAdmin) don’t even bother hiding their (non-transparent) icon bars at all, taking up quite a bit of screen estate.

Jaadu’s apps and VNC Pocket Office by Chillingo are the best in this respect.

Copy-paste between client and remote desktop (clipboard synchronization): with the introduction of OS version 3, the iPhone, at last, has received support for copy/paste and clipboard.

Unfortunately, of the tested controllers, only Jaadu’s two (RDP and VNC) apps support copying, and “only” from the desktop to the local iPhone, not vice versa.

Server-side configuration capabilities: some apps allow for setting the most important parameters (for example, scaling) accessing the server-side configuration window (for example, with Ultra / WinVNC, Admin Properties). Here, I’ve listed whether it’s possible to set these parameters if the iPhone client doesn’t have the settings in its local configuration dialogs.

An example: Mocha VNC by MochaSoft doesn’t allow setting server scaling from the local options screen (unlike VNC Pocket Office by Chillingo Ltd). Nevertheless, from the controller, you can freely fire up Admin Properties and just set server scaling to your desire.

Accessing other resources on the remote desktop: File transfer between client and remote desktop: while file transfer is pretty common in other operating systems (even under alternative ones like Windows Mobile), none of the iPhone controllers support it. Hope this too changes – at least the Jaadu folks mentioned they will try implementing it.

Client-side remote / monitoring tools?: : ever wanted to avoid having to, say, use the Task Manager in a full remote session? Ever wanted to avoid remote registry editing in a remote session because of the amount of, say, registry tree navigation involved, which results in greatly slowed down operation when done remotely? On alternative mobile operating systems, there are desktop controllers that allow for remotely monitoring; for example, RemotelyAnywhere on Windows Mobile, it's possible. The local HTML interface offered this application, which is compatible with even the dumbest Pocket Internet Explorer, offers you the chance of doing all this stuff locally, without having to log in to a real remote session and accessing these monitoring / registry editing tools in there.

Unfortunately, nothing like this is possible on the iPhone.

Access to other PIM resources?: should you want to access and, what is more, search your mail or other personal calendar / contacts / tasks data stored in your Outlook or Outlook Express, you'll want to ask iPhone remote desktop controller software developers to take a look at how genuinely I'm InTouch (on Windows Mobile) does this.

Of course, you can do the same with actually logging in to your remote desktop and doing the same PIM stuff in there via Outlook (Express), but it's, of course, a much more awkward solution with orders of magnitude more bandwidth usage - remotely accessing / using for example Outlook will always be much harder than through a mobile screen/interface-optimized, locally (on the iPhone) running interface.

Console mode (in Windows Server products): here, I listed whether the RDP-compliant apps also support console mode available in Windows Server products (but not in XP / Vista / Windows 7, of course). Most of them do. Just remember to enable console mode on your iPhone before connecting – it’s disabled by default.

User interaction: Co-working with local (server) desktop user (no locks etc.): Here, I've listed whether the user sitting in front of the desktop computer can interact with the remotely connecting one

Anyone knowing RDP-based solutions knows both these painfully lack this functionality. Therefore, you'll need to go for an alternative solution if you do need these. All non-RDP-based solutions support co-accessing the same desktop with the physically in front of it sitting user.

Login: l/p credentials can be saved?: in some alternative operating systems (most importantly, Windows Mobile before version 6), it was impossible to store the login/password data of a user. Fortunately, there’s no such restriction in any of the iPhone remote desktop controller applications. Note that they all support for not only saving this kind of info, but also specifying more than one account. Some (namely, VNC Pocket Office by Chillingo) even offer Wi-Fi- and cellular-optimized templates to create these, the difference being in, for example, the delay, the color depth etc.

Windows accounts? That is, can you log in using any existing Windows user login / password pair (you don't need to come up with a new username and/or password but can use your familiar Windows one)?: this shows whether you need to come up with a password (and, probably, a new username) for logging in, or, you can use your Windows username / password. As you can see, with RDP apps and LogMeIn, you can directly use your Windows passwords. With VNC apps, on the other hand, you can’t – you need to use the VNC password, not the Windows one. The latter (if at all supported by the VNC server – Tight doesn’t support it, while Ultra/WinVNC do) isn’t supported in any of the current VNC clients.

iPhone 3G (128M RAM) test with as large a desktop as possible: in this test, I wanted to find out whether a memory-constrained device is able to reliably (without crashes) to access as big a desktop as possible. I used a UXGA (1600*1200) laptop. I ended up having to use one screen (the built-in one, that is) with RDP (as it’s incapable of making use of a secondary monitor) at either this (with RDP clients that do support his high a resolution) or lower (generally, SXGA [1280*1024]) resolutions. With VNC and LogMeIn (where you can use both extended desktops and there’s no obligatory screen resizing), I used a desktop sized 2880*1200 (coming from the built-in UXGA screen and an additional SXGA one).

I’ve run the tests on a jailbroken iPhone 3G but without any special memory hog SpringBoard / WinterBoard add-ons; neither any “memory free” apps like SwapMode in Cydia. It doesn’t even have YourTube (the excellent YouTube downloader plug-in; see my dedicated article HERE), QuickScroll (see THIS), iMobileCinema (see THIS), Backgrounder (the best “hack” ever written for the iPhone) or anything like these – that is, not anything that could take up system resources / memory. I haven’t run Safari / Mail / iPod previously either (these programs remain in memory after you exiting them). That is, these tests represent the “ideal” state (something that can be attained after resetting a device but without additional “daemon hunting” and hardcore hacking & free memory increasing). Note that, should you encounter any problems resulting from memory shortage and you don’t have any kind of “free memory” applications or hacks, just restart the iPhone by pressing and holding the Power button and sliding the slider when displayed.

All in all, I haven’t found any of the tested programs fail at the given screen sizes. I, however, noticed how slow some of the VLC apps are. This means if you’re an iPhone 3G user and want / need to use VNC, you may want to consider sticking with Jaadu VNC – it delivers by far the best and fastest performance. (On a 3G S, the difference isn’t this much pronounced.)

 

Wake up on LAN?: of the bunch, VNC Pocket Office by Chillingo also supports wake up on LAN functionality.

Automatic discovery of remote desktops on the same LAN?: the Jaadu apps and Mocha VNC support automatic discovery of local desktop computers. Note that in order for this to work, you must run Jaadu VNC Connect or Jaadu RDP Connect on the same desktop. They will keep broadcasting a message to the local network that there is a VNC / RDP server listening on these devices. Note that these broadcast messages are sent out even when the VNC server is shut down or stopped - or the RDP service disabled; that is, these three remote controller clients will find these desktops even then. Strangely, clients do find these desktops even after stopping Jaadu RDP / VNC Connect.

These two, protocol-specific apps (Jaadu RDP / VNC Connect) do other things as well. If the router you’re connecting to the internet is a uPnP-capable one, it tries to reconfigure it to port forward the VNC / RDP ports so that (from the Internet) incoming requests are passed right to the VNC / RDP server. This is also a great feature – you don’t need to manually do this kind of a configuration, which is, especially for non-geeks, is surely big help.

Note that if your router is behind a firewall (which is pretty common in an enterprise environment), these two Jaadu apps won’t be able to provide you with a direct IP to your desktops. You’ll see this right away: it’ll display an error message. Nevertheless, local discovery will still work in the same subnetwork – and, there, the auto-discovery support of the Jaadu apps (and Mocha VNC) is a god-send. You won’t need to check (with “ipconfig” or by just hovering the cursor above the VNC server, if you plan to use VNC) the current IP of your desktop after moving it to another network and enter the new IP into your iPhone. Any changes to the IP addresses will be automatically detected by the iPhone clients – all you need to do is tapping the discovered desktop(s) in the listing and you’re set. (They’re correctly recognized because the computername is also listed.)

Multimedia: Sound redirection from the desktop to the client (and, possibly, vice versa): you may also want to listen to what the remote desktop is playing. While you most probably won’t want to use remote the, for this reason, highly inefficient remote desktop control protocols for “traditional” multimedia transfer (there are far better means for this; for example, Orb), being able to hear what’s going on may be of paramount importance when you, for example, access the Web browser on your desktop to, say, watch a Flash video otherwise unplayable on the iPhone. (Note that not even the latest Flash players only available for jailbroken devices support playing back a lot of Flash videos on the Web).

Interestingly, the only desktop controller application, Wyse PocketCloud, to support thin client Web browsing a la SkyFire doesn’t transfer audio to the client either; this way, it severely hampers its usability. I can only hope the developers of the, otherwise, much more decent controller apps (e.g., Jaadu) implement some kind of a Web browser capability too. As Jaadu RDP already supports audio transfer, it’d be highly useful together with a nice thin client Web browser like that of Wyse PocketCloud.

Possible to start sound apps on desktop?: on some competing platforms (most importantly, Windows Mobile), some RDP applications didn’t even let users start applications emitting sound at all. While you may argue there isn’t much point in starting such applications when the client can’t deliver sound at all to your iPhone, there are cases when this can be a problem; for example, when remotely administering radio / audio recorder or transcoder applications. This can be very important when you maintain for example a netradio station or just want to record one without a direct stream recorder tool like WMRecorder.

The Special client-side input group elaborates on whether, in addition to sending the standard left clicks to the desktop, it’s possible to do the same to more elaborate mouse events: right-clicks, double clicks, mouse dragging, scrolling with the mouse wheel and the like. Also the question of being able to just “hover” the cursor anywhere is discussed in relation to this part.

Right clicks: elaborates on whether right clicks are supported. As you can see, all controller apps support this, except for the free (lite) versions of the two (RDP and VNC) Mocha clients.

Double left clicks: all controllers support double left clicks (for example, to quickly highlight the current word / paragraph in a Web browser or text processing application).

Tap-and-hold (like moving windows around): you can drag the cursor in most applications; WinAdmin and the two free Mocha apps being the exceptions.

Scroll wheel: particularly in a remote desktop control situation can become the scroll wheel emulation really handy. Then, to scroll around the current document (Web page etc.), you won’t need to access the scrollbar on the right at all every time you want to scroll. Support for this (which also exists in all the recommended clients) is pretty common. The exceptions are iRdesktop, PocketCloud and WinAdmin – and, of course, the lite versions of the two Mocha applications.

Special keys: unfortunately, not all remote desktop controller applications provide support for all Windows (or Mac) keys available on a standard keyboard. Some (iRdesktop, PocketCloud, WinAdmin and the free versions of the Mocha apps) even only offer the standard built-in on-screen keyboard of the iPhone – and almost nothing else. These become useless when you want to emulate e.g. function key keypresses.

National characters : unfortunately, support for sending accented characters is pretty scarce. The best behaving application in this respect is Jaadu RDP; the other applications behave far worse. Some are only capable of sending Western accented characters to the desktop (that is, accented characters of Western languages only but not even those of East-Euopean ones, let alone Hebrew, Russian, Arabic and oriental languages like Japanese and Chinese).

Unfortunately, in VNC, the situation isn’t helped by enabling “Japanese” in the “Keyboard & Mouse” group in Ultra/WinVNC – not even Jaadu VNC will be able to transfer anything non-Western (including even Japanese characters).

Is it possible to "hover" the cursor? and Server-side tooltips displayed? : you may want to position the mouse cursor without actually sending a click so that, among other things, you can see additional information – for example, the address of a Web link; the description of a GUI icon and the like. All the recommended desktop controllers support this – actually, all the ones that (also) have a Cursor mode.

Cursor tracking?: I've also listed whether remote controllers are dynamically able to follow the cursor and the text input caret. Doing this is highly useful particularly with clients zoomed in and having lost the current position of the cursor / input caret. Unfortunately, none of the apps are capable of these while, on competing platforms, there are some that do; for example, on Windows Mobile, both pcAnywhere and z2.

The Resolution, zoom, color group contains information on everything related to the usable desktop resolutions, color depth and the like.

Can just use the default resolution / screen orientation (without having to resize)?: in this row, I’ve listed whether you are forced to resize the screen (or, at least, to provide some kind of a resolution) when using the desktop from a controller. As you can see, in RDP clients, you must resize the desktop - or, at least, enter / select a resolution at configuration time; if you’re lucky enough, you’ll be able to force the same resolution on the desktop as is the current one of the desktop to, later, after finishing the remote session and returning to the original, higher resolution, avoid having to press minimize / maximize with all the windows that have been opened during the remote session.

 

Explicitly (from the client) settable desktop resolutions: here, I’ve listed the usable resolutions (when you are forced to provide the target resolution, that is; the case with RDP clients).

As you can see, it’s Jaadu RDP that is (again) the best RDP client. None of the other RDP clients allow for entering a resolution manually – and, in general, their list of selectable resolutions is very poor. For example, Remote Desktop by MochaSoft only allows for selecting SVGA (800*600), XGA (1024*768) and SXGA – and nothing else. Similarly, none (!) of the applications allow for using UXGA (1600*1200) – except for, of course, Jaadu RDP, which does let you enter and use this resolution.

This also means that, should you want to stick with an uncommon (for example, UXGA or WUXGA) resolution on your remotely controlled desktop and don’t want your RDP clients to mess this up, resulting in your having to manually resize the windows so that they, again, remember the current size of the desktop, go for Jaadu RDP. Or, of course, consider moving to VNC / LogMeIn, which aren’t plagued with this problem.

Color depth: here, I’ve listed the available color depths. In a nutshell: the higher the color depth, the higher the data use – and so is the image quality, should you want to see images, photos, videos (and not just textual content) in their full glory and using as many colors as possible. As you can see, most of them support more than 8-bit colors; the only exception is Remote Desktop by MochaSoft 2.1. Nevertheless, even it will receive a 16-bit mode in the next upgrade, according to the developer.

Note that I haven’t listed strictly protocol-dependent tests like “More than one concurrent remote users using the same remote protocol accessing the same desktop?”. In a desktop: this is impossible with LogMeIn (which logs out the previous user at once) and RDP. VNC, however, does support it. Some VNC servers, that is. To enable this, in the Admin Properties of Ultra / WinVNC, check “Keep existing connections” (instead of the default “Disconnect all existing connections”) in the Multi Viewer Connections group. In the TightVNC server, go to Properties (it comes up by just left-clicking the icon) / Administration and select “Automatic shared sessions” instead of the default “Refuse concurrent connections”.

3. Verdict

As you can see, there is no clear winner. This is pretty much understandable: the different feature set and performance of each app is in no way as important as the capabilities and restrictions of the underling protocol. Let me show you some examples. The list is in no way exhaustive –above, I’ve elaborated far more thoroughly on the weaknesses / strengths of each protocol; here, I only give you some examples of the most frequently asked questions and discussed dilemmas.

It’s pretty silly to go for for example the RDP-based Jaadu RDP (because of its, say, audio transfer and copy/paste capabilities) and when your desktop you’d like to access from the outside is under a corporate firewall – it simply won’t work. Then, you’ll need to stick to LogMeIn – the only app that offers accessibility under even the harshest, most secured networking conditions.

Similarly, you won’t want to stick with any RDP client if you plan to do any kind of a cooperation between the user in front of the controlled desktop and the iPhone user that controls it. The former will be locked out and won’t be able to do / see anything. Here, only VNC and LogMeIn can be of any help.

If you want to let more than one remote user on your remote desktop, your only choice is VNC (just don’t forget to allow for multiple access: it must be manually enabled in Win, Ultra and TighVNC.)

If you do plan to frequently use your iPhone to access desktops in the same network (e.g., connected to the same Wi-Fi access point), you will want to avoid LogMeIn altogether. It, unfortunately, uses remote connections even when the remotely controlled desktop and the controller, the iPhone is in the same subnetwork and, therefore, a direct connection between them could be established. This means in these cases LogMeIn will be much-much slower than both VNC- and RDP-based, direct solutions.

Note that, generally, there isn’t much difference between these three protocols, data usage-wise. None of them is particularly sensitive to for example smooth scrolling, which, back in the Windows Mobile days, caused a lot of problems and excess data use.

That is, first, always decide which of the three protocols can at all fulfill your needs and whether the one you choose has stumbling blocks making one of them impossible. After you’ve decided what protocol to use, I recommend the following:

- If you select RDP, go for Jaadu RDP. Don’t really bother with iRdesktop by Thinstuff s.r.o., Wyse PocketCloud or WinAdmin by Carter Harrison. The latter two are pretty much overpriced for their capabilities and the first isn’t very good either. The Mocha client, particularly now that it will receive Windows 7 compatibility very soon, is a better buy – but, again, if you do want to frequently access desktops remotely, don’t try to save money – go for Jaadu RDP.

- If you select VNC, Jaadu VNC is by far the best (and, unfortunately, expensive) choice. If you in no way have that much money, I recommend VNC Pocket Office by Chillingo Ltd instead – it’s pretty cheap and has some unique capabilities (e.g., wake on LAN, support for server scaling and partial screen transfer). The Mocha VNC client is decidedly worse – as long as you don’t want to use its auto-discovery. (Nevertheless, the entire auto-discovery works way better and more reliably in Jaadu’s apps.)

- If you select LogMeIn, your choice is pretty limited: LogMeIn Ignition only.

4. Recommended reading

My similar article, discussing desktop controller apps on Windows Mobile. Note that it contains three parts – don’t forget to follow the link to the next one at the bottom of the page!

 

(Reserved for future updates)

 

(Reserved for future updates 2)

 

(Reserved for future updates 3)

 

(Reserved for future updates 4)

 

UPDATE (10/09/2009 17:20 CET): the promised, updated, now, Windows 7-compliant Mochasoft RDP client (which also has a free version with restricted input capabilities) has just been approved by Apple and is already available in the AppStore.



In addition to having received Windows 7-compliance, it also supports 16-bit color depth now. (Previously, it only supported 8 bits; that is, 256 colors.)

I’ve tested it with my Windows 7 notebook. I encountered no problems during the testing.

 

UPDATE (11/05/2009 16:00 CET): LogMeIn, one of the most recommended remote desktop controller applications, has just received a major upgrade:



I’ve given it a quite thorough try.

Welcome additions:

- Far more special keys. The previous version only supported the F1…F12 function keys in addition to the standard iPhone keyboard and the Alt / Ctrl / Win modifiers, Menu, Alt-Tab and Ctrl-Alt-Del. The new version also supports the almost all the other ones (just make sure you slide the function key keyboard in keyboard mode to left/right):





- A new “Compressed” color mode, which might deliver better quality using lower bandwidth (note: haven’t tested the data use of this new mode):



What’s still missing:

- Accented character support (still, not even Western ones work)

- Audio transfer

- Clipboard synchronization support

- Full screen mode without anything on the screen – see for example the excellent three-finger swipe mode of the Jaadu apps (starting with version 3.0) doing the switching

- (Direct connection whenever and wherever possible; for example, over LAN’s)