On Networks, FarFinder and Webjimbo

April 2nd, 2009

The following is taken from my response to Glenn Fleishman’s Macworld article about getting Back to My Mac working on your Mac. FarFinder and Webjimbo users can encounter similar issues, so I include this here for anyone interested. It will make more sense in the context of the original article.

—-

The issues Glenn describes above are common to any remote service you run on your Mac, including FarFinder, so I thought I’d contribute some of my own experience.

The single most common problem is when people with DSL connections buy a separate wireless router. This causes the “double NAT” problem Glenn describes - you now have two private networks: one between the modem and the router, and one on the other “side” of the router where your Macs are. Rather than putting the router (or Airport) in bridge mode, I usually recommend telling the modem to forward all incoming traffic to the router (”DMZ” or “default server” setting). This is because most routers support UPnP, while many modems don’t, so the poor user is often saved an extra configuration step.

Alternatively, the simplest solution to the double NAT problem is to buy a decent DSL modem with a built-in wireless router, thus you only need one device.

(Incidentally, cable modems are transparent to the network, so a wireless router added to a cable connection doesn’t suffer the double NAT problem, since it’s on the internet-proper.)

Another big problem is that a lot of routers just don’t do UPnP (automatic port mapping) properly, even though they claim to support it. (I go into this in detail in an earlier comment.) Of the big names, D-Link are particularly guilty of this in my experience, and I often end up advising users to add the port mapping to the device manually instead - a hassle, but a stable solution in the long run.

Having said all this, it’s almost always possible to get things working properly on a home network with the right configuration changes. (Exceptions are cases where the user doesn’t have access to the modem and router, eg. some apartments, some offices, schools and most hotels. The ISP restrictions Glenn describes are less common in my experience.)

But the network device makers are letting us down. Settings are hard to find, badly named and terminology varies wildly from device to device, often to the point of nonsensicality. Reliable, standards-compliant devices would be a great step forward, but there’s also a lot that could be done in terms of automatically adapting to common network conditions, eg. the double NAT problem.

Unfortunately the obvious place to lay the blame is on the software - FarFinder, BtMM or whatever, and you get many people mistakenly saying that a product doesn’t work. You can’t blame them - they shouldn’t really have to care about this network stuff - but they end up missing out on useful software because of it and mislead others too. The fact is that quite often configuration will be required and there’s simply no way for the software to do it for you. The best it can do, like FarFinder, is recognise common situations and point you towards some help.

(Of course BtMM might have other reliability issues too - I don’t know, I don’t need it :-)

One day, IPv6 might solve this all for us, but don’t hold your breath.


FarFinder hits the App Store!

March 11th, 2009

At last! FarFinder’s native iPhone application is finally in the App Store and ready for download. Here’s a link to it in iTunes, or of course you can go straight to the App Store on your iPhone. Make sure you have the very latest version of FarFinder on your Mac—you can use Check for Updates to be sure.

I’m not going to do anything daft like paying people on Mechanical Turk for positive reviews, but if you could leave a review on the App Store I’ll be grateful, and you’ll also help other people find what is hopefully a truly useful app amongst all the noise. The content of the review is, of course, up to you.

Early downloaders may have noticed that email was broken; this is fixed in today’s 1.2.9.5 release of the Mac app. (The iPhone app doesn’t need updating.) 


Thanks for waiting

I know that many of you have been waiting for this for a long time now, and will be as excited to start using it as I am to finally have it released. My thanks to you all for your patience and support these past months.



Summarising the delays

The delays have been fairly well documented in this blog already, but to summarise: FarFinder was first submitted to the App Store on December 6th, which means it has taken just over 13 weeks to be approved. The eighth version is the one that made it. This experience highlights two major problems with the review process:

  1. Everything that Apple wanted changed was present in the very first submission. This whole process would have taken about a week if they had reviewed the whole app at once, rather than drip-feeding their complaints one by one.

  2. Review turnaround time is dog slow—two weeks for one of the reviews. This is would be just moderately problematic if it weren’t compounded many times over by point 1.

About what’s changed

The main thing you’ll notice is that some files are missing their custom icons, while others are represented by non-standard icons that are specific to FarFinder. This is a result of Apple’s not allowing their own icons to be presented in the iPhone app; there were other niceties removed for the same reason.

The irony of this is that as Mac developers we’re used to putting in those little touches that make the user experience just that little bit better; the changes I’ve had to make to satisfy Apple have made the app just that little bit worse.

Having said that, no actual functionality has been harmed.

FarFinder for iPhone: we shall simply ignore your questions

February 20th, 2009

Two days ago I was hopeful: I had an email from an App Store reviewer asking how to log in to FarFinder. They had been trying to use their Find Me user name and password instead of their Mac’s account details. (This trips a few people up.) Good though, because it seemed somebody new was taking a look at the app.

But no. Today:

We’ve reviewed FarFinder and determined that we cannot post this version of your iPhone application…Please see the attached screenshots. Your application uses standard Mac OS X icons for Downloads, Documents, iTunes music files, etc.

That’s all. I’ve discovered this already: they simply won’t deign to respond to questions or challenges or to explain themselves further. Not only that, they don’t even acknowledge that such questions have been received or read. Here’s your takeaway quote: This is the attitude of a company that knows it has its customers over a barrel. There’s no way the rest of us would get away with treating our customers and associates like this, nor would we want to.

There’s a saying: “Don’t attribute to malice that which can be explained by incompetence”, and I’ve considered it. One does come across this behaviour with the worst sort of call centres—places where the reason you get no joy is that the people can barely read, let alone formulate a rational reply. But I have difficulty believing that the App Store review centre would really be one of those places.

Being a sucker for punishment, and wanting the best for my customers, I sent back another reply:

Please reconsider your rejection or explain why you are treating FarFinder differently from other applications:

FarFinder is a remote access application. It doesn’t “use” standard Mac OS X icons, it displays whatever is on the remote Mac. Other remote access programs, such as Mocha VNC and Jaadu VNC will do the same thing, and you have allowed these in the App Store.

Please do not ignore this question. We developers put in a lot of hard work for these applications - you should at least take the time to reply to our submissions and treat our applications fairly.

We shall see.

FarFinder for iPhone: Status Update

February 14th, 2009

Today, FarFinder’s native iPhone application was rejected from the App Store yet again. Here’s why:

Using your application, when the user logs in to the machine, the default OS X directory and file icons are displayed.

“But that’s what FarFinder does!” I hear you say. And you’d be right.

It’s also what any VNC application that runs on your iPhone does—it displays whatever’s on your Mac’s screen on your phone’s screen, including the trademarked Apple icons they’re complaining about. FarFinder does the same thing—it transfers what you’d see on your screen over to your Mac. The trick is, it only transfers the bits it needs.

There are VNC applications on the App Store. There are also other applications that display Apple icons; obvious candidates are those that let you copy files from your Mac to your iPhone (also a FarFinder feature): AirSharing, FileMagnet, DataCase.

So, if nothing else, standards aren’t being universally applied—unfair, wouldn’t you think? In the interests of getting this sort of thing out in the open, here is my reply:

This rejection is entirely unfair—there are other applications on the App Store which do the same thing, and you have accepted them. Please revisit the decision to reject FarFinder.

FarFinder simply presents whatever files are on the target computer. The trademarked icons to which you refer are transferred over the network from the Mac and displayed on the iPhone.

There are a number of other applications in the AppStore that do the same thing, including the following (screenshots attached to this email):

- AirSharing: Displays the icons of whatever files you transfer to your phone, including icons for Apple products. The attached screenshot is from your very own web site, where AirSharing was a pick of the week.

- DataCase and FileMagnet: Same as AirSharing

- Mocha VNC: Any VNC application will also display Apple’s icons on your phone. The data is also transferred over the network, and you have no problem with this.

I also note that FarFinder has been in the review process for ten weeks now. It has always had this functionality, and yet this is the first time you have complained about this core feature of the application.

Looking forward to your fair judgement on this issue,
Adrian Ross

See that last point? FarFinder has been in the App Store review process for ten weeks, and this is the first time they’ve mentioned it. I don’t know, between this and some of the more frivolous earlier rejections, a developer could start to get paranoid. You know, as if there’s something more to all this.

Stay tuned.

FarFinder iPhone App: Apple’s Just Killing Us

January 29th, 2009

Where’s FarFinder’s native iPhone application? Does it really exist? By now, you’re probably beginning to wonder.

The app has been ready to go since December 6; ever since, it’s been waiting for Apple’s approval before they allow it in the App Store. All iPhone applications go through this process—even free ones like FarFinder—and via the App Store is the only way to get applications onto your phone.

The delay is enormously frustrating for my customers and—and as you can imagine—for me too. So here’s a breakdown of what’s happened so far. Read as much or as little as interests you.


So, eight long weeks.

It hasn’t been one solid block of waiting time—there have been some minor things about the application that Apple wanted changed. The problem is twofold:

  1. There’s a huge delay before they get around to reviewing the app. Their longest so far is three weeks.

  2. The app review stops as soon as they find something they don’t like. You make the change immediately and resubmit the app, but now you’re back at step 1. Given their glacially slow review times, it’s absurd that they don’t continue testing and inform you of multiple problems at once.

Here’s a timeline of the events so far. Note that, without exception, the problem was corrected and a new version of the app resubmitted within a day or two.

December 6: FarFinder submitted to App Store

December 10: Rejected for (1) containing an image of the iPhone on the welcome page, and (2) for not working over the mobile network (complete nonsense, this last one).

The welcome page now looks like this:

welcome.png

That’s a black rounded rectangle with a grey border, rather than an actual image of half an iPhone. You can see we’re really improving the user experience here.

It’s worth noting that at first all they did was send a screenshot and say there was a trademark violation; at that point I couldn’t imagine what they were referring to and had to email, twice, for clarification. More delays.

“Not working over the mobile network” just meant that they hadn’t set FarFinder up properly on their Mac, so they didn’t have any remote access whatsoever. The red lights make this fairly obvious, but they rejected the app all the same.

December 30: Rejected for misusing a plus-sign image.

It’s reserved for adding a contact, but I used it for adding something else. Fair enough, but couldn’t they have told me earlier?

January 14: Rejected for highlighting a table row to indicate selection.

You’re only allowed to use a checkbox to do this, apparently. It’s really less obvious what’s going on when you do it that way, but hey—it’s not like there’s a forum for discussing this stuff!

January 25: Rejected for using images of Macs.

Here’s what you would have got when choosing which Mac to connect to. See how the icon looks like your actual Mac? Cool eh.

login.png

Here’s what you get now. Again, such a massive improvement!

loginNew.png

January 30 (the time of writing): We’re still waiting…

…and customers are, quite rightly, emailing.


What should Apple do differently?

Apple has set certain standards for iPhone applications with the intention of providing a consistent and high-quality user experience. This is an admirable aim and I’m certainly not disagreeing with it, despite some minor quibbles above.

But their current processes are inefficient to the point of arrogance. A two-month delay is not just irritating for developers and users, it has a direct impact on a developer’s livelihood. Apple’s attitude seems to be that we should simply be grateful we’re allowed to write for the iPhone at all; it’s time to start acknowledging that quality developers have taken the time to learn to write for the new platform, and that without us the iPhone will abandoned to the fart-app peddlers and other novelty merchants.

  1. Review applications in full

    Drip-feeding you one problem at a time is a ridiculous way to do things. The huge delays between app reviews compound the problem, making this simply unforgivable.

  2. Speed up review times

    Yes, this has been said by others many times, but it’s no less valid. Sure, they probably have a lot of apps to review, but it’s not like this is a new situation—the App Store’s been open for ages. Employ some more people! Judging by the communication I’ve received so far, they’re not exactly employing rocket scientists to do this work, so they should at least be cheap.

  3. Tell us what’s required!

    Most of these time-consuming rejections could be avoided in the first place if the interface and trademark “guidelines” (read “requirements”) weren’t scattered throughout hundreds of pages of documentation.

    Requirements should be gathered together in one document so we developers at least have a chance of adhering to them. As far as I know, no such document exists (although I’d be pleased if someone could correct me on this).