What should we know in order to make a 3rd-party developer's life easier?

My company is looking to develop a cross-platform mobile application.

What are some general things we should know before approaching a developer that will make their lives easier and our app better? What are some common feaux-pa's that developers repeatedly get from ignorant clients, but can't stand?

I'm Looking for all answers, from the most obviously obvious to the "not what you'd think".

Thanks in advance.

If you're building something for developers:

1. Examples are very, very valuable.
2. Invest in "progressive complexity". Developers should be able to start really, really simple and then work their way up. Make step 1 easy, and build confidence over time.
3. Provide a forum for your customers to collaborate and ask questions. Developers would rather not have to call you -- give them support online both directly and from others in the community.

I take it that your app isn't for developers necessarily, but rather you want to know about proper etiquette in outsourcing development. It that's true, dharmesh's points 1 and 2 are still relevant. But there is more.

Think of your dev as a partner, and treat him or her with respect and gratitude and you won't go far wrong.

That said, the fundamental principle here is "Don't be cheap," both in the money you are willing to spend and the time you are willing to spend interacting with your dev. So, speaking as someone who develops, but occasionally outsources certain things:

1. Examples (as dharmesh said). These take time. Mock-up screenshots are very helpful. So are analogous apps that you may know about.
2. Progressive complexity (again as dharmesh said) for any app that is non-trivial for the developer. This will, of course, depend on the developer's particular experience. Think about setting a budget that is based on milestones, with the milestones being increasing complexity.
3. Work with the developer to get through problems. Be willing to compromise on some business logic if it means keeping the problem
   solvable. I recently had to give up some functionality on a
   calendar app because it made the problem waaaaay too hard for my
   devs. It turns out I can get fine without the functionality, and if I want it later I'll put
   it in when I have the resources to throw at it (paying a dev or two
   serious $ for a serious, full-time commitment). Good enough is good
   enough.
4. If the app is non-trivial, and you aren't a genius at specs, it's going to be a lot more complicated than you think (the mistake I made in point 3). Be willing to spend extra $ as a reward/bonus/etc for the honest effort your dev gives. Even if it doesn't quite work out perfectly.
5. You may find that you share skype or IM accounts or have some other way to get real-time communication with your dev. Don't abuse this. Just because you see your dev is on skype doesn't mean it's ok to 'check in.' To the extent possible, schedule 'check-ins' in advance and don't abuse the privilege of having his/her contact information.

And, although it doesn't sound like the case here, I'll add for future readers that it's my impression also that it's not considered ok to 'subcontract.' Meaning, if I were working for some company making $X/hr, and I outsource my work to someone making $X/5/hr, that isn't considered cool. I'm not sure about this, but I've been asked directly if I was doing it, probably because I code myself, I seem to 'know too much.' I handled it by pointing to my web site, showing them what I'm about, and telling them that I just need help building my product.