Since you mention recurring payments as a priority, I'd recommend Chargify. They give a list of gateway options here: http://chargify.com/payment-gateways/
One of my businesses is an online retailer. We use PayPal Standard (but don't require a PP account) simply because the UI for generating postage and tracking shipments is very easy. USPS has an open API, but I've yet to find a payment processor that integrates shipping.
I second this, http://chargify.com has many more features than Braintree, Spreedly, and Recurly. Also, they work with international merchant accounts/gateways.
"no tech scene, no innovators, no night life, no forward-thinking, no excitement."
Sounds to me like a blank canvas and opportunity to be a big fish in a small pond. Your town not being cool enough isn't a good excuse. It's like blaming a chair for making you sit in it.
If you are a true entrepreneur and have the ambition, you'll hustle up make things happen. In the meantime, lower your standards and take the next job that's offered to you.
It seems to me that a key move to stabilizing bitcoin would be finding a high demand product that can only be purchased with bitcoin. That along with offering retailers incentives (aside from the "no fees" aspect). A group of heavily invested bitcoin owners would be wise to organize such efforts.
That would have to be something that cannot be resold. Still, a company which sells its product (which would have to be unique within its market segment) for "real" money today would have to say goodbye to all those dollar-wielding one-dot-oh customers and hope they come back tomorrow with bitcoins.
If you want the best user (and developer) experience, write 2 different codebases and share graphical assets.
Even though you could write portable C++, the API for getting to the hardware is going to be pretty different. I have worked on a project where we developed an app with identical look and feel on both Android and iOS simultaneously. The UI was basically completely custom (designed in Photoshop by a 3rd party).
My biggest advice is to do the Android UI layout IN CODE. The iOS version was completed in about 70% of the time of the Android project mostly because of the slowness of developing the UI with XML/Eclipse and Android's immature layout API.
UI layout in code can be a pain because you can't see what you're doing until you do the compile-install-run which can be 30 seconds. That's a hefty amount of time if you're just tweaking one visual element and need to run through 1-10 possibilities.
Normally I would agree- ALL my iOS apps are done in Interface Builder. But if you add more than 50 PNGs to an Android/Eclipse project, the iteration cycle is well over a minute long compared to a 5 second recompile. That's not counting the slowness of the Android emulator (hardware was faster for debugging for me)
I'm a HN n00b so I don't understand why this is getting promoted up so quickly. Do people not actually visit the links? No offense kreci, but there's no actual info on that page yet. Seems like pure self promotion to me.
I'm in the home office with a hot cup of Casi Cielo working in the bowels of CoreText and Quartz for a huge feature update to my iPhone/iPad app. When I need an eyeball break, I walk into the living room to see if I can catch a cool commercial)
