Well, of course they do. File extensions are an important part of including resources in applications, and missing or incorrect ones can corrupt files and cause all kinds of issues. For me, it was spending hours tracking down a bug in my Android application code only to discover the problem was using a .tiff image instead of a .png.
After 8 months of experience with both, I am finding myself falling solidly into the “I’d rather develop for iOS than Android” camp, and this is just one of the many reasons why. Eclipse gave me no indication that my file extension could possibly cause any issues. I was using a .tiff file (the default file format for Mac OS X Grab) and trying to use that in an Android activity in my onResume() function. There were no warnings about the fact that Android doesn’t natively show .tiff files and searches showed nothing that suggested my file format was the issue.
I checked race conditions. There’s a known issue about ImageView.setVisibility(View.VISIBLE) not working on certain Android layouts, so I had just about given up. I made an entirely new activity, added the image, ran the app again calling that new activity instead of resuming the old one – and there was still nothing. The file format was the last thing I checked – and sure enough, exporting as a .PNG was the fix.
So, if you’re at your wits end because something just isn’t displaying the way you expect it to, make sure to use a file format that you know works – it might be the tiny bug you don’t catch.
Also related: in Xcode, files that have a lowercase .png need the full file name to display. To use the built-in capability to differentiate between retina and non-retina assets, make sure that your assets are named with .PNG instead, and then you don’t need to include the extension when calling on the resource.