Facebook Tweet


Unity Publishing Metrics

Jul 2015

I worked through the "Roll-a-ball" beginner tutorial of Unity 5 and published to all the platforms that I may care about. I thought you'd be interested in my findings. Here are results from Windows, Mac, Android, iOS, and WebGL.

Tutorial: Roll-a-ball


Particularly interesting part of the publishing process is that I used a single Mac installation to publish to everything, including Windows. Cross-compiling has been around forever, but it is nice to have the process be so easy. A couple platforms took an extra step, but it was painless.

Windows 7

App size: 30 MB

The Windows package was zero-install. All the frameworks were provided in a nice data subdirectory. This package would be very easy to wrap up in your favorite installer tool. I did not test on a completely fresh Windows installation, but this initial test is promising.

Windows roll-a-ball screenshot

The guidelines require small indies to use the made with unity splashscreen if not paying for the premium version. I wanted to see how long this "payment" lasted. The Unity logo was on the screen for just a couple seconds. If anything, I think it made my beginner app look more professional.

Windows made with Unity


App size: 40 MB

The Mac app had all the frameworks in its standard .app bundle. It was zero-install.

Mac roll-a-ball screenshot

"Made with unity" was identical to the Windows version and was on the screen for just a couple seconds.

Mac made with Unity


App size (reported by iOS): 61 MB

Instead of a ready-to-upload package, Unity created an Xcode project that I then needed to load and compile manually in to an iOS package. The project compiled with no problems. I actually don't mind this because iOS projects require lots of tweaking in the settings to get the package just right. I already had a $99/year iOS developer account to be able to do this test. This project would not run in the free simulator.

This image is the final archive that could be uploaded to the app store.

iOS roll-a-ball screenshot

Just like the others, the "made with unity" was very breif. Maybe 2 seconds.

iOS made with Unity

And now the app running the tutorial. The shadows do not look correct. It does not look correct on Android either. Something to consider when developing. The desktop versions look OK. For now, I'll blame myself for this error. I burned through the tutorial pretty haphazardly.

iOS roll-a-ball screenshot


App APK size: 18.4 MB

App Installed Size: 30 MB

Android was probably the easiest to publish. It spit out an APK that could then go directly in to Google Play. I already had the Android SDK and a signing key ready-to-go. A new user would need to set all that up. It is not trivial to do, so maybe "easy" is misleading. It is easy once all those behind-scenes steps are done.

Unity added no extra permissions. Since Google now hides the INTERNET permission, I unbundled the APK itself and did not seen any in there.

Android permissions

I don't know why the Android-based splashscreen looks different than the others. The part I care about was fine. It was on the screen for just a couple seconds.

Powered by Unity

Screenshot from the app listing showing install size.

Android installed

And now the app screenshot

Android permissions


App download size (via directory listing): 110 MB

WebGL took forever to compile, and the result is a monstrosity. To their credit, Unity calls this feature beta. I agree.

For the huge size, it seems the culprit is a single uncompressed rollballwebgl.js file at 104 MB. Their tool outputted a 15 MB compressed version that does not seem to work or I am just misunderstanding something. Anyway, I ran the JavaScript file through uglifyjs, and after a long while, this was the result:

Dans-MBP:Release dannagle$ uglifyjs -o rollballwebgl-ugly.js rollballwebgl.js
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
Abort trap: 6

Splashscreen lasted 2 seconds.

WebGL Powered by Unity

The screenshot looks nicer than it really is. This game had a lot of artifacts. WebGL from Unity is not ready for prime time. I think the app size problem could potentially be solved with the various JavaScript compression tricks. However, that would not solve the performance problem. Maybe 2D works better.


I hope you find this quick test useful. I say except for WebGL, Unity passes.

I didn't do any performance metrics, but I am mostly interested in 2D. I am sure any modern mobile device could handle the types of apps I plan to create.


Dan Nagle is a SW Developer and the founder of NagleCode. His apps have been downloaded hundreds of thousands of times. Contact Dan to speak at your event.

More Posts

Jan 2018: Pay Down Calc v2.0 - A Resource For Consumers and Agents
Jul 2015: Unity Publishing Metrics
May 2015: JavaScript is not the answer to everything
Feb 2015: Abandoning Scripts for Static Pages
Apr 2014: Qt is better than Java.
Oct 2013: The government does not need to make a health website.
Sep 2013: Google Reader may by dying but RSS is not
Jun 2013: Stop writing batch scripts. Start writing AutoIt scripts.
Mar 2013: Goodbye XP Hello Linux Mint
Dec 2012: Your Goals Should be SMART
Apr 2011: Happy 40th Birthday FTP and Farewell
Aug 2010: Breaking the World Record Typing Numbers to Words

Copyright © NagleCode 2007 - 2019.