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)
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.