Your iPhone native application has been extremely successful and of course, customers have been asking when a similar Android native application will be available. So, you assign the design of the Android application to your user interface design person who in turn dusts off the iPhone wireframe documents. But wait, where does your user interface designer draw the line on having the Android application function the same as the iPhone application versus having each application support the UI design guidelines and behavior for each platform? Designers and programmers will be confronted by this issue as businesses look to support multiple platforms both externally for customers and internally for their own employees. Do they have to do double the design work?
The answer is yes and no. Android natives applications have been out long enough for designers and developers to have discovered that Android applications that try to look and function like their iPhone brethren aren’t accepted as well. The customers who are asking for the Android version are not iPhone users and using iPhone-style navigation is likely not intuitive for the experienced Android user. The same would go for testing of your bright and shiny Android application with people experienced with the iPhone. The iPhone testers who are putting the Android app through its paces for the first time will get hung up on things that feel unfamiliar and give inaccurate feedback about the fit and finish of the application.
Finally, in the case of corporate mobile applications, there is the issue of support and training. As a designer, you don’t want the Android and iPhone functionality and navigation so dissimilar that your support costs will increase if you have to support functionality two separate ways. As with everything else in life, there needs to be a middle ground between support what makes each platform unique and endears it to its advocates and having the applications functions in relatively the same way.