I'm providing three different answers to this question with two different approaches - click here and here for the other answers. I'm doing this to allow all answers to be voted on, commented on, and accepted independently.
Let's assume that certificate errors happen too often for everything you've tried (perhaps because you've tried setting up certificates, going all over the place with them, and still can't get them to work reliably enough). Let's also assume that the data you are sending is not critical enough to absolutely require HTTPS encryption (e.g. you don't do anything with real money) and you are OK with sending it unencrypted. In this case, it probably is safe for you to proceed with HTTP downgrade under one condition: imformed user consent. The user must explicitly affirm that they data they are sending is not critical enough to absolutely require HTTPS encryption and that they are OK with sending their data (or receiving data that will become theirs) unencrypted.
What that essentially means for you is that your HTTP downgrade should not be automatic, behind the user's back. Instead, if you encounter a certificate error with the website, you should follow the example of modern browsers encountering such an error and inform the user, perhaps with some kind of dialog box. Let them know that the SSL certificate has failed and that, while they can technically still continue, it will be at the cost of encryption - they then can make the choice between what option they want, and proceed under their own consent, with both of you now having the knowledge that your connection is vulnerable.
Of course, when asking users to make a decision like this, there is an ethics issue of whether or not it is right to ask users to open up the data they send, and that will depend on the kind of data you expect to deal with. In general, the more free-form the data the user can reasonably send, the less ethical this becomes, since free-form data can very easily become secret data. This gets especially hairy in international markets, where the sensitive data the user is sending might include the fact that they're even using the app at all, depending on the user's jurasdiction.
Even if you can determine that the choice might be an ethical one to allow, it should not be a mindless one - most users are trained to just click "yes" if you let them, even if they're binding themselves to sell their firstborn baby. Most browsers, when offering the cert bypass choice, tend not to mention it at all initially, and instead hide the option behind some ominous sounding "Advanced Options" button that only technical people will willingly click.
And, after all that, once you have allowed the insecure HTTP connection, you may want to treat it differently now that it has been compromised, perhaps outright refusing certain transactions and limiting the effects of others. For instance, one could reasonably limit HTTP transactions to be read-only and not allow them to affect any state.