Apple Doesn’t Care About Games

Tell us something that we didn’t already know.

In his (not so) recent article in The Guardian, I was an App Store games editor – that’s how I know Apple doesn’t care about games, a former App Store editor, Neil Long, confirms facts that we knew to be true, even obvious, through our experiences with game submissions.

The fundamental conclusion, that Apple doesn’t particularly care about games, is self-evident. Apple is not a game company, and they don’t value games as a way to sell hardware, or increase prestige, or whatever the hell Apple’s mission is these days. Oh, right… their primary mission is increasing shareholder value, so they have no immediate incentive (and very little foresight) to invest in nor properly support the mobile game ecosystem they created “by accident“.

The article confirms what we already surmised, from a “woefully understaffed team of app reviewers”, to comical submission failures, to generally making whatever changes seem to bring in the most profits, regardless of the effects on their customers, game publishers, or the long-term health of the entire system. They don’t see a reason to address the fact that the median income of an iOS game on the App Store is, literally, $0; as long as a few games make them loads of cash, they do not care.

This is, of course, why Apple did the calculus and determined that it was considerably less expensive to reduce commissions to 15% for most game publishers (which costs them absolutely nothing for the majority of games) than to lose their monopoly on iOS sales. (Honestly, I don’t actually know how many “publishers” have signed up for the App Store Small Business Program to get the commission reduction, since a seemingly large, and growing, number are non-professionals.)

I could speculate on the theoretical issues that will be an increasing problem for the App Store in the future, but instead I will mention the very real issues that are happening right now. First, the economics of mobile games (for both Apple and Android) are no longer generally viable without manipulation techniques. A handful of games are making millions of dollars per month (or even per day), but the vast majority do not earn enough in their lifetimes to cover the cost of development. There used to be developers advocating a “mobile first” design strategy, and now I hear nothing about this approach; I do hear about companies deciding that it is not worth the effort, and I know that is a very active discussion point for our future games.

On the other hand, despite the ostensibly strict submission and approval process, Apple is allowing the App Store to be inundated with multiple copies of essentially the same game, submitted by “different” publishers. In some categories I have explored, it is easy to download just a few games and find at least two that are obviously based on the same source code, with only minor graphical revisions (or else cloned so closely as to be counterproductive). I don’t know the actual business model (whether it is a larger company flooding the market, or somebody selling source code packages, or amateurs just submitting sample game applications from some tool or another), but the result is that the App Store experience is getting steadily worse. I love the fact that a 12-year-old with talent (as I was when I got started programming games long before any of this was possible) can gain valuable experience by publishing their own game on this platform, but when every game is either a first project, a clone, or a product with a 6-figure marketing budget, there is little value to be found.

Here are the questions that have to be asked by professional developers:

  • Why should we commit resources to developing a game for iOS (or Android) when the chances of profiting are very slim?
  • What incentives do we have to update and improve released products that have not recouped costs on this mobile platform?
  • Why should we develop for a platform where discoverability is such a problem, and getting worse all the time?
  • What incentives do we have to bother to remove a “zombie” product (i.e., one that earns nothing) from the App Store once published?
  • Why should we bother to support a platform whose owner so clearly does not care about us nor our support of their platform?

I do not have any tangible solutions to suggest (publicly) at this time, primarily because changes are up to Apple and they are unlikely to listen to me (based on every previous interaction). In general, though, as the article says, “Apple could have reinvested a greater fraction of the billions it has earned from mobile games“, and further, it could be seen to actually care about those of us who work hard to make a living developing games and, in the process, supporting their platform (and bottom line). You know, any reasonable change that does not make our lives more difficult or potentially cost us more money to compete would be a start.

Launch Screen Sizes for iOS 12

If you still use launch screens, these are the sizes you need.

As with mobile icons, the proliferation of new Apple mobile devices demands an ever increasing number of launch images.  This post lists the necessary artwork sizes to directly support all devices (and possible orientations) as of iOS 12.

Of course, Apple realizes that adding new launch screen sizes every time they introduce a new form factor will quickly become unsustainable.  (It is close to that now; otherwise, this post would be unnecessary. 😉 )  For that reason, they introduced launch storyboards, which allow a launch screen to be defined by a layout of controls and constraints, rather than by individually sized images.  The only problem is that, unlike normal storyboards, the launch storyboard is loaded before the application runs, so only automatic layout can occur; no code can be executed.  Therefore, customization is restricted, which prevents developers from accomplishing the same thing that is possible with launch images, namely, use of the entire screen on each individual device for displaying an image.

Apple takes the position that the launch screen should display an image reflective of the first screen of the application to give the impression that the app has launched that quickly.  This certainly is better for Apple, who is not known for missing branding opportunities, but using the launch images for branding, i.e., a splash screen, is expected in the game industry (and, arguably, for any software).  Also, games usually have custom background artwork, and if that is customized to screen sizes, there is no easy way to mimic that with a launch storyboard, at least at the moment.

To be fair, nowadays the launch screen is a somewhat rare occurrence, as it is only shown at first launch, or when the application has been unloaded, either closed by the user or removed from the background by the system to recover resources.  If you design your splash screen to be an image in a sea of solid color or a repeating texture, you can reproduce that with a launch storyboard.  The kind of splash screens that Rick Tumanis designed for Demolish! Pairs or Pretty Good Solitaire, however, do not lend themselves to this approach.  It is for that reason that we still use launch images in those games (and others).  In fact, Demolish! Pairs will reshow the splash screen if you shake the device from the menu.  (It is an ‘undo’ when done from within a game.)

So without further ado…

iPhone Launch Screen Sizes

Apple iPhones provide the bulk of the variety in device screen sizes, so you need to provide 11 (or 12) launch images for full coverage, as follows:

  • Portrait iOS 12+
    1. 1242 x 2688 (@3x) – iPhone XS Max
    2. 828 x 1792 (@2x) – iPhone XR
  • Landscape iOS 12+
    1. 2688 x 1242 (@3x) – iPhone XS Max
    2. 1792 x 828 (@2x) – iPhone XR
  • Portrait iOS 11+
    1. 1125 x 2436 (@3x) – iPhone X / iPhone XS
  • Landscape iOS 11+
    1. 2436 x 1125 (@3x) – iPhone X / iPhone XS
  • iPhone Portrait iOS 8+
    1. 1242 x 2208 (@3x) – Retina HD 5.5″ (iPhone 6 Plus / 6s Plus / 7 Plus / 8 Plus)
    2. 750 x 1334 (@2x) – Retina HD 4.7″ (iPhone 6 / 6s / 7 / 8)
  • iPhone Landscape iOS 8+
    1. 2208 x 1242 (@3x) – Retina HD 5.5″ (iPhone 6 Plus / 6s Plus / 7 Plus / 8 Plus)
  • iPhone Portrait iOS 7+
    1. 640 x 960 (@2x) – 2x (iPhone 4s)
    2. 640 x 1136 (@2x) – Retina 4 (iPhone 5 / 5s / SE)
  • iPhone Portrait iOS 5, 6 (legacy)
    1. 320 x 640 – 1x (optional – unused on iOS 8+)
    2. 640 x 960 (@2x) – 2x (same as #10)
    3. 640 x 1136 (@2x) – Retina 4 (same as #11)

Note that the lowest supported target system for Xcode 10.0 (latest version as of this writing) is iOS 8.0, and no devices at the original iPhone resolution (320 x 640) can run that version of iOS, so the final unique size (#12) is unused in modern apps.

iPad Launch Screen Sizes

There is good news and bad news when it comes to supporting iPad launch images.

Good News

The good news is that you only need 4 launch images for iPad support, as follows:

  • iPad Portrait iOS 7+
    1. 768 x 1024 – 1x (iPad 2)
    2. 1536 x 2048 (@2x) – 2x (iPad Retina / Air / Air 2 / 5th gen / 6th gen)
  • iPad Landscape iOS 7+
    1. 1024 x 768 – 1x (iPad 2)
    2. 2048 x 1536 (@2x) – 2x (iPad Retina / Air / Air 2 / 5th gen / 6th gen)

That is pretty straightforward, especially given that they are the same aspect ratio, so you can just create the double density size and directly reduce the image.  Further, if your target platform is iOS 10 or higher, the iPad 2 is no longer supported, so you only need the two larger images for all remaining iPads.

For completeness, here are the legacy sizes for iPads running iOS 5 or 6:

  • iPad Portrait Without Status Bar iOS 5, 6 (legacy)
    1. 768 x 1004 – 1x (optional – unused on iOS 8+)
    2. 536 x 2008 (@2x) – 2x (optional – unused on iOS 8+)
  • iPad Portrait iOS 5, 6 (legacy)
    1. 768 x 1024 – 1x (same as #1)
    2. 1536 x 2048 (@2x) – 2x (same as #2)
  • iPad Landscape Without Status Bar iOS 5, 6 (legacy)
    1. 1024 x 748 – 1x (optional – unused on iOS 8+)
    2. 2048 x 1496 (@2x) – 2x (optional – unused on iOS 8+)
  • iPad Landscape iOS 5, 6 (legacy)
    1. 1024 x 768 – 1x (same as #3)
    2. 2048 x 1536 (@2x) – 2x (same as #4)

The only (4) new sizes here are just the same launch screen sizes with an area for the status bar (20 or 40 pixels) removed.  These sizes are never used in modern apps.

Bad News

The bad news is that, as keen observers will have noticed, I did not list any of the iPad Pro models above; this is because an iPad Pro acts like an iPad Retina.  Without a launch storyboard, all iPad Pro devices show up as though they are only 2048 x 1536 resolution.

To be fair, the smallest iPad Pro, the 9.7″ model, is only 2048 x 1536, but the two larger models have higher resolution that is not used: 12.9″ is 2732 x 2048; 10.5″ is 2224 x 1668.

If you want to have the full resolution of iPad Pro devices, you must use a launch storyboard rather than launch images; you cannot use both, as (experimentation suggests that) the inclusion of a launch storyboard supersedes launch images.  Damn.

Conclusion

The release of iOS 12 added the need for 4 additional launch screens (to support both orientations for the iPhone XR and iPhone XS Max), so a “universal” app needs to provide a total of 15 launch images to support all iPhone and iPad devices.  However, if your game or app needs to take advantage of the full resolution of the iPad Pro, you will need to provide a launch storyboard instead, and adjust your launch screen appropriately.

All Apple needs to do to provide complete support is to provide constraints for individual form factors, allowing different images to be selected from the launch storyboard based on device model, OR use a provided launch image in preference to (or prior to) a launch storyboard.  Best of all, they could just remove the arbitrary and silly restriction that prevents access to full iPad Pro resolution unless we provide a launch storyboard, which restriction seems to be in place for the sole purpose of strong-arming developers into supporting launch storyboards (before they provide equivalent functionality).

In the meantime (which will likely be forever), it makes sense to start figuring out how to adjust your launch design and strategy to work with launch storyboards.  This is not unlike what is currently necessary for Android support, anyway.  For our next project, we are investigating a high resolution square-ish logo that can be the sole image in a field of white, scaled to largest size possible to fit the launch screen.

Abandoning this expected branding opportunity, though?  Not likely.

Modern Mobile Icon Sizes

Icon sizes you need to support iOS 12 and Android Oreo devices.

With the explosion of mobile devices, it keeps getting more difficult to keep track of the myriad icon sizes required for mobile apps.  This post simply lists the required sizes and uses for iOS and Android devices (as of now).

When creating an application icon, it is best to start with an image that is (at least) the size of the largest icon necessary, which is currently 1024 x 1024, and then reduce that image to the necessary sizes, reducing level of detail as/if necessary for smaller icons.

iOS App Icons

As of Xcode 10 (iOS 12), iOSApple iOS devices have application icons for the app on three different device types (iPhone, iPad, and iPad Pro), the store, spotlight (search), settings, and notifications, and these icons may need to be provided in single (unadorned), double (“@2x”), or triple (“@3x”) scale factors.

For a “universal” app, you need to provide icons in 13 resolutions (for 15/18/19 different uses, depending on how you count).  iPhone only apps need 8 resolutions; iPad only apps need 9 resolutions.

Here is a list of the iOS icon sizes, along with a color-coded list of the uses:

  • 1024 x 1024
    • App Store – all applications  (<title>.png)
  • 180 x 180
    • iPhone application @3x  (<title>_iphone@3x.png)
  • 167 x 167
    • iPad Pro application @2x  (<title>_pro@2x.png)
  • 152 x 152
    • iPad application @2x  (<title>_ipad@2x.png)
  • 120 x 120
    • iPhone application @2x  (<title>_iphone@2x.png)
    • iPhone spotlight @3x  (<title>_search@3x.png)
  • 87 x 87
    • iPhone settings @3x  (<title>_settings@3x.png)
  • 80 x 80
    • iPhone spotlight @2x  (<title>_search@2x.png)
    • iPad spotlight @2x  (<title>_search@2x.png)
  • 76 x 76
    • iPad application  (<title>_ipad.png)
  • 60 x 60
    • iPhone notification @3x  (<title>_notify@3x.png)
  • 58 x 58
    • iPhone settings @2x  (<title>_settings@2x.png)
    • iPad settings @2x  (<title>_settings@2x.png)
  • 40×40
    • iPad spotlight  (<title>_search.png)
    • iPhone notification @2x  (<title>_notify@2x.png)
    • iPad notification @2x  (<title>_notify@2x.png)
  • 29 x 29
    • iPad settings  (<title>_settings.png)
  • 20 x 20
    • iPad notification  (<title>_notify.png)

Android App Icons

AndroidAndroid icon requirements had remained fairly consistent, but as of Android 8.0 (Oreo, API 26), those application icons are now classified as “legacy”, though still required for support on earlier devices (i.e., 85.4% of the market); the latest devices can use “adaptive” icons.  All applications should have a store icon.

For most Android apps, you should provide application icons in 6-8 resolutions (none of which overlap with the iOS resolutions).

Store Icon

Android apps, if they are to be published, require a store icon:

  • 512 x 512 – Google Play

Legacy Icons

To support devices running Android 7.1 (Nougat, API 25) and earlier, which you absolutely should, provide legacy icons in resolutions supporting 5 (or 6) different screen densities:

  • 192 x 192 – xxxhdpi
  • 144 x 144 – xxhdpi
  • 96 x 96 – xhdpi
  • 72 x 72 – hdpi
  • 48 x 48 – mdpi
  • 36 x 36 – ldpi (optional)

Note that some legacy icons can (technically) be omitted, but those sizes will be generated by the Android system from other sizes, and not necessarily the best resolution (i.e., a larger icon may be generated from a lower resolution icon, which looks poor).  Therefore, only the low density (ldpi) icon is considered optional; no modern devices are low density, and if one was it would necessarily generate the icon from a larger source.

Adaptive Icons

Adaptive icons were introduced in Android Oreo to allow the system to perform visual effects with the shape and/or contents of an application icon.  In order for this to be supported, adaptive icons need to be separated into foreground and background layers; the foreground contains the important content of the icon, toward the center, and the background is an image or color that may provide branding but could be clipped.

These are the components:

  • foreground – 108 x 108 image with transparency, icon content in center 72 x 72
  • background – color or 108 x 108 image to be composited with foreground

The foreground and background may be moved or sized independently before being composited together, and the resulting image will likely be cropped into an arbitrary shape; Android reserves an 18 pixel border for these kind of visual effects.

For more information, see this page about supporting adaptive icons.

Conclusion

For a mobile app to support all recent iOS and Android phones and tablets, you will need to create about 20 icons, in the resolutions above, including separate foreground and background layers for adaptive icon support.  If possible, start by creating an App Store icon (1024 x 1024) from a separate foreground and background.  Use that as a source icon to generate the smaller Google Play, iOS, and Android legacy icons, adjusting detail as necessary.  Finally, resize the foreground and background layers appropriately to generate the components for the adaptive icons.  (Then, take a deep breath.)

Now you are ready to implement your application. 😉  Of course, if you want to support Android TV, Apple TV, Android Wear, Apple Watch, Android Auto, and/or Apple CarPlay…