Skip to main content


Hardware differences.

The iOS platform is bound to Apple specific hardware, and has a fixed number of configurations. PrimateLabs (2013) suggest that mobile device release schedules are partially driven by the demand to access the latest version of the operating system, and the latest features, allowing developers to target a workable subset of devices without losing sales, or building to the lowest common denominator and losing features.     Apple hardware screen size resolution and aspect ratio.Until the release of the iPhone 5 all devices ran a 3:2 aspect ratio, which meant scaling was relatively easy, the iPhone 5 introduced a longer 71:40 aspect ratio.   iPhone 3/3GS/ipod touch: 480x320px, 163 ppiiPad 1/2/Mini: 1024x768px, 132 ppi iPad Retina: 2048x1536, 264 ppi iPhone 4/4S/iPod Retina: 960x640px, 326 ppi 
iPhone 5/iPod Touch: 1136x640, 326 ppi

Diagram showing Mobile device relative physical screen sizes and aspect ratios.

Android hardware screen size resolution and aspect ratio.Because Android is an open platform, there are many different devices and resolutions. The Android developer guidelines (2012) indicate that:       "xlarge screens are at least 960dp x 720dp
    large screens are at least 640dp x 480dp
    normal screens are at least 470dp x 320dp
    small screens are at least 426dp x 320dp"

        Popular device configurations include:    Asus Nexus 7 Tablet: 800x1280px, 216 ppi     Motorola Droid X: 854x480px, 228 ppi     Samsung Galaxy SIII: 720x1280px, 306 ppi    LG (Google) Nexus 4: 1280 x 768 pixel resolution 320 ppi

Chart showing distribution of screen sizes in Android devices - source - Android Play Store

From these data it is clear that building for a single screen size/resolution and aspect ratio isn't viable, and a cross platform application will require some form of relative size detection algorithm, however this is also true when building for just a single platform.  For the project I tested on a Nexus 4 device with a 4” 1280 x 768 screen, an iPad 2 with a 9” 1024 x 768  and an iPhone 3GS Simulator with a 3.5” 320x480 screen providing a representative range of ratios, sizes and pixel densities for cross platform development.

Screen touch layer.

The majority of devices use similar capacitive touch technology which requires a finger (or stylus) touch to register an event. The event produces an imprecise multi point blob making extreme precision tricky, which has design implications for the size of touch targets. It is essential that app design considers the smallest deployment screen to ensure pixel targets are large enough. This is one area that commonality between Android and iOS devices allows for a common approach. The Android developer resource suggests 48dp as a good size for a touch target, with Lee and Zhai(2009) indicating that targets smaller than the traditional finger width (22mm) are problematic, and should never be less than 7mm on screen.The fact that touching the screen obscures it also needs to be considered in design. In this project I used the whole screen split in half as touch targets when in game reaction time is critical, and large buttons for other selections.


The different screen sizes require different size icons, with precise naming conventions to match to devices:Michael Gieson (2012)outlines the  Mobile device icon size requirements which range from 29x29 px to 1024x1024px, each of which have specific naming conventions too.These details tend to be handled by the respective platform IDEs when building native applications, but need consideration when using a cross platform framework.

A small selection of the range of icon sizes required for cross platform development


Android and iOS support a number of different audio file types for both playback and streaming:   Apple developer guidelines(2012) indicate that iOS devices (and the Xcode simulator), support .aac, .aif, .caf, .wav and  .mp3. These formats must be uncompressed or they will not play.
Android supports .wav, .mp3 and .ogg, and in theory .aac may be supported but this is uncertain on Android due to platform fragmentation.
For a common code base it would be useful to use a common audio format, which in this case means .wav or .mp3. Unfortunately there are issues with both of these formats.

.wav (Waveform Audio File Format). A .wav file can hold compressed audio,but usually contains uncompressed audio, which is good for audio quality but bad for maintaining small file sizes - a key issue on small handheld devices. For example the background music for the game created in the project- a 9 second loop - weighs in at 1.6Mb in .wav format, whilst the same clip in .mp3 format is only 148Kb.
.mp3 (MPEG-1/ MPEG-2 Audio Layer III).

 .mp3 is a patented encoding format for audio that provides efficient lossless compression.  The patent requires that the technology be licenced, which was the source of continuing legal actions throughout the last decade. Despite this .mp3 is the de facto standard of digital audio compression, and indeed a synonym for digital audio players. 

OpenAL (Open Audio Library). OpenAL is a cross-platform audio application programming interface (API) designed to mirror OpenGL (Open Graphics Library). OpenAL provides rendering of multichannel three dimensional positional audio, making it very useful for sound effects in games. Early versions of the framework were open source software, but the later revisions are proprietary, prompting a move towards OpenSL ES (Open Sound Library for Embedded Systems).

System detection.

System detection algorithms may be required to build with the correct audio files for each platform, setting a global path and file extension variable which could be concatenated to provide the correct file type.

In summary common audio file format support is likely to mean using .mp3. Whilst there are some concerns about patent trolling, it seems likely this has been resolved, and .mp3 is safe to use. I used both .wav and .mp3 in the project.


Both platforms provide a range of fonts, serif and san serif, and the opportunity to import True Type Fonts (.ttf ). However fonts are expensive and licensing can be restrictive, as font creators are keen NOT to have their work bundled in applications.Workarounds to avoid licensing include using bitmaps of fonts. In the project where I wanted to use custom fonts (like Haettenschweiler) I created graphics, for example in the buttons, but text as a graphic is a poor alternative in terms of accessibility.

Game buttons used in ND vs PR

For dynamically generated text, such as the score and health I selected a specific iOS font (Marker Felt) as the chief target device was the iPad, with fallback to the default san serif font on Android.

Platform Foibles.

In terms of structuring an application iOS and Android have some other quirks:
On iOS most small games try to stay under 20MB because this was traditionally the largest file network carriers allowed to be downloaded over 3G, (the limit used to be 10MB!) Larger files require a WiFi connection or need to be downloaded via iTunes and synched.  The project iOS app file is 9.4Mb, and the Android .apk is 11.4Mb.
Early versions of Android platform didn't support folders, so all files had to be in the root directory, this is still true of certain files, but Android now supports folders. As I was targeting recent version of the OS I  used simple folders to separate the images and audio files from the system files. 
Android offers LandscapeR, LandscapeL, and portrait orientation events (but  not upside down) and iOS will support any orientation. I built the project with Landscape R as the default, and LandscapeL as an option.
    Rationale for project choices - The need for speed.Building for iOS and Android is worthwhile, the market is large, and the speed of OS uptake means developing for just the current OS version is viable. Anecdotal evidence from studios like Glitch Games (2013)- The developers of "Forever Lost" indicates that iOS supports a business model based on paid apps, whilst Android seems more focused on free apps with advertising.The brutally fast hardware and OS refresh cycles dictate that speed of development to get products to market within a ""platform cycle" is the key driver in the Iron Triangle (Bethke 2003).

The need for speed is amplified by the fact that building an app does not guarantee sales. There are a vast number of apps, more every day, and the ease of development creates a low signal to noise ratio, indeed New Relic mobile monitoring report (2013) that "More than 60% of apps in the Apple App Store have never been downloaded and of those that have, one in four is abandoned after its initial use." 
Cross platform development has the potential to reduce deployment time, which is a key factor in reducing costs, and code maintenance from hardware and OS revisions.


Android Developer API Guidelines (2012) Supporting Multiple Screens. Avaliable at: [Accessed on 28-5-13]

Michael Gieson (2012) Mobile device icon size requirements. Available at: [Accessed on 11-8-13]
Google Android Developer Resource. (2013) the 48dp rhythm. Available at: [Accessed on 19-8-13]

Lee, S., and Zhai, S.(2009) The performance of touch screen soft buttons. CHI '09 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Pages 309-318 ACM New York, NY, USA

Ascender Fonts (2012) Android default fonts. Available at: [Accessed on 18-8-13]

John Gruber (2007) iOS default fonts. Available at: [Accessed on 18-8-13]

Warden, J., (2011) Intro to Corona SDK- Anscamobile's Hackathon 2011. Available at [Accessed on 28-5-13]

Bethke, E.,  (2003). Game Development and Production. Wordware Publishing Inc.
CoronaGeek podcast: (May 14th 2013)  In discussion with the developers of Forever Lost. Available at: [Accessed on 11-8-13]

New Relic(2013) Mobile app download statistics. Available at: [Accessed on 11-8-13]

Popular posts from this blog


Beta Beater

The Google Developer Console is really very very good.
It's logically set out, and makes it super easy to run a Beta test.
I'm on the tenth iteration of the final draft, and think I've got to a point where I can actually promote the app to Production.
The latest revision changed the icon set, and removed a load more cruft, slimming the app down to just 12.14Mb. I could strip out the iOS icons and lose a few more bytes but the original aim way back when I started on this project was to build a simple game that could be deployed cross platform, so I think I'll try and maintain just one codebase... as I really should submit this to the iTunes store too, to close the project.

Spine again - animating game assets

Laura Tallarday gave a neat demo of how to build an animation in Spine on the CoronaGeek Hangout, so I had a bash at chopping up an image and animating it.
The plan is to add some more sophisticated animations to the new game "Duck sized horse".. but as was discussed in the show adding a whole bunch of spine animated objects might hammer a mobile device... and as the aim is to have 100 tiny duck sized horses, I'd best choose another approach for them.

anyway here's a swaying viking...