3. Setting Up Unity and Your Mac for iOS Development 49
3.2 Setting Up Unity to Work with Your Apple Developer Profile
Before we go ahead and build anything to iOS from Unity, there are some important bits of information we need to give it.
The first thing we need to do here is to open up Unity and navigate to Player Set- tings. Open Unity, click on the menu File–>Build Settings. The Build Settings window (Figure 3.1) shows a list of scenes included in the build, the currently selected platform, and any platform-specific settings. In the Platform section, ensure that iOS is selected before continuing. The selected platform will determine how assets are imported and compressed by the engine, so it is important to have this set correctly early on. Once you are sure that iOS is selected as the target platform, click on the Player Settings but- ton at the bottom of the window.
Here you will find (amongst other things) the name of your company, your game name, your game’s icon, and some important things that we need to tell Xcode to be able to install our game onto our devices—some pretty important things! In actuality, most of the settings in Player Settings can be left at their default values for the first run.
There are just four things that need their default values changed and are essential to the build, but we will take a look at the rest of the Player Settings since there are some things that you will inevitably need in the future, and it will help to know where they are.
3.2.1 Company Name
If you have a company name, put it here, or perhaps use your own name if you don’t have a company. Unity will use this to form a filename when it builds a Preferences file (used to store your game’s preference data). Be sure to change this from its default value.
3.2.3 Product Name
When you see your app on the home screen of your iPad, iPhone, or other iOS device, an icon will be displayed and the product name is the name shown under it. We usually use the name of the game as the product name. Unity also uses this as part of the Prefer- ences file filename. Be sure to change this from its default value.
3.2.4 Default Icon
This is the icon that will appear on all platforms (such as desktop Mac/PC builds or iOS builds). It can, however, be overridden with specific icons for specific platforms later, which is useful when you need to do things like have a smaller icon for iPhone and a larger high-quality icon for iPad.
3.2.5 Per-Platform Settings
The first thing we need to do here is to open up Unity and navigate to Player Settings.
Open Unity, click on the menu File–>Build Settings. As shown in Figure 3.1, the Build Settings window shows a list of scenes included in the build, the currently selected plat- form, and any additional platform-specific settings. In the Platform section, ensure that iOS is selected before continuing so that iOS-specifics are shown from here on. The selected platform will also determine how assets are imported and compressed by the engine, so it is important to have the platform set correctly early on. Once you are sure
3.2. Setting Up Unity to Work with Your Apple Developer Profile 51
that iOS is selected as the target platform, click on the Player Settings button at the bot- tom of the window.
3.2.6 Resolution and Presentation
y Default orientation. Which direction on the device is initially up?
y Use animated autorotation. Should we use that native rotation animation when users change the orientation (the one that makes the screen spin around to match the new orientation) or should the screen just flip around?
y Allowed orientations. In some cases, you may not want users to be able to ro- tate the screen to a particular orientation. For example, if we build our UI to only fit into a portrait orientation, we will need to disable landscape. Use these checkboxes to check which ones to allow Unity to automatically turn to.
y Status bar. iOS has a status bar showing things like battery charge, the time, signal strength, or carrier. We can choose whether or not to hide this when users are playing a Unity game. Unity also provides us with a drop-down to specify the style of the status bar as the application launches.
3.2.7 Icons for iPhone, iPod Touch, and iPad
The splash image is an image to be displayed when a user launches your project. Note that the free version of Unity always displays a Unity3D logo during the initial loading
Figure 3.1. Build settings and platform settings in Unity.
sequence and this section is only applicable to Pro licenses, as shown in the table below.
Splash Image Type Splash Image Description and Resolution
Mobile splash screen Specifies a texture that should be used for iOS splash screen.
Standard splash screen size is 320 × 480. (This is shared between Android and iOS.)
High res. iPhone Specifies a texture that should be used for iOS fourth-generation device splash screen. Splash screen size is 640 × 960.
iPad portrait Specifies a texture that should be used as iPad portrait orienta- tion splash screen. Standard splash screen size is 768 × 1024.
iPad landscape Specifies a texture that should be used as iPad landscape orien- tation splash screen. Standard splash screen size is 1024 × 768.
3.2.8 Other Settings
There are only two values in the Other Settings section that you will need to change when you make a build for the first time. The bundle identifier and target platform set- tings will need to be set, but you should also take a quick look at the SDK Version and Target iOS Version settings.
3.2.9 Static and Dynamic Batching
When Unity draws objects on the screen, it has to send out what is known as a draw call to the graphics system (OpenGL). Each draw call has a cost in terms of performance, so we need to keep the number of calls down as much as possible. By cutting down on draw calls, the system doesn’t have to work so hard at processing them and our game will run faster. Unity provides two batching methods.
y Static batching. This is a Unity Pro-only feature for performance optimization.
This is the process whereby Unity combines a number of immoveable objects (models or meshes) at runtime, then rather than sending out draw calls for each object, the engine combines them wherever it can into a single draw call.
In a nutshell, the fewer draw calls, the better performance we will get. We will look at batching some more in Chapter 9.
y Dynamic batching. Nonstatic objects (things that move!) can go to the batch party, too! Simply by having the “dynamic batching” checkbox checked, any objects that share the same material may be batched automatically into a single draw call. The downside is that this only applies to objects containing less than 300 vertices, as batching actually begins to degrade performance on objects that have more than that.
3.2.10 Bundle Identifier
Whenever we build to iOS, our source files need to include something called a bundle identifier. Sounds scary, but it’s just a fancy name and Unity will take care of the hard
3.2. Setting Up Unity to Work with Your Apple Developer Profile 53
part once we tell it what to include. The bundle identifier is a string, similar to a web URL in format, that ties your build to an application ID you register through the web- based developer portal. In essence, it ties your application to the one that you are telling Apple about. Your profiles will contain these identifiers, and if the one in your game doesn’t match up with the one in the profile, Xcode will give you errors when you try to put it onto your devices.
In Section 2.9, we covered everything you needed to get set up through the Apple Developer Center, including setting up the application ID. Refer to that section to set up an app ID. You will need it now.
3.2.11 Target Device
This drop-down provides options for all of the available iOS-based platforms. Treat the iPod as the same device as the iPhone—there are very little differences between the two in terms of what Unity can do with them.
3.2.12 Target Platform
This area provides a drop-down so that you can select which processor architecture your game will run on. If you don’t know what ARM is or much about processor archi- tectures (and why would you be expected to?) you don’t need to be alarmed.
3.2.13 ARMv6 (OpenGL ES 1.x)
This is for iPhones and iPods. Newer graphics capabilities are not supported under this platform, such as features supported by OpenGL ES 2.0.
3.2.14 Universal ARMv6+ARMv7 (OpenGL ES 1.1+2.0)
This creates a build that will work on both older devices and newer, including the iPad and new Retina display-capable iPhones.
3.2.15 ARMv7
This target creates a build that works on iPads exclusively, relying on the capabilities of the ARMv7 architecture.
3.2.16 Target Resolution
y Native (default device resolution). The default resolution of the device will be used when you choose this option.
y Standard (medium or low resolution). The standard resolution setting is the lowest you can get, the same as the original first-generation iPhone: 480 × 320.
y HD (highest available resolution). This setting uses the maximum resolution allowed on the device.
There are several different screen resolutions that need to be supported across iOS platforms. When Apple brought in the retina display, it meant higher-quality images
for the user, and more work for us to support them. If you are working on a 2D-based game, this may present more of a problem in terms of making a 2D system that is scal- able and does not distort or tear when exposed to differing aspect ratios. Games that use a 3D user interface (UI) generally translate easier, as most can be supported by a simple change of camera position or orthographic height. Third-party libraries such as EZGUI1 make it easier to produce 2D UIs that translate between resolutions, but you should try to approach your designs carefully and formulate scaling strategies early on.
For simple menus, you can use Unity’s built-in GUI class along with the graphical user interface (GUI). Matrix function to scale the UI to the current resolution. Due to the performance impact of the GUI system, this option should only be applied to in- stances where highly optimized performance is not a goal.
At the time of writing, the resolutions on iOS devices are listed in the following table:
iPhone 4, second-gen. iPod Touch with retina display 960 × 640 iPhone 3G/3GS, first-gen. iPod Touch 480 × 320
iPad 1024 × 768
iPad 2 1024 × 768
iPad 3 2048 x 1536
3.2.17 Override iPod Music
If this checkbox is checked, any music that the user is playing through the device will be paused when the game launches. Once the game is closed, the music should resume.
3.2.18 Requires Persistent Wi-Fi
If your application requires a Wi-Fi connection (for example, a Wi-Fi–based multiplay- er game), you can check this box to ensure that iOS keeps any current Wi-Fi connection open throughout the game.
3.2.19 Exit on Suspend
Several iOS devices are capable of multitasking, which means that you can keep an ap- plication open and switch to another one then back again without the original applica- tion losing its place. If this “exit on suspend” checkbox remains unchecked, Unity will hold on to session data so that users can switch out and back again; otherwise, session data will be lost and the game will exit whenever users try to switch.
3.2.20 API Compatibility Level
As iOS users are often paying for bandwidth, or at least trying to limit how much band- width they use, it makes sense for us as game developers to try and keep our file sizes down as reasonably as possible. Unity gives us some great tools to reduce sizes such as image optimization and compression, audio compression, mesh compression, and even
1 http://www.anbsoftware.com
3.2. Setting Up Unity to Work with Your Apple Developer Profile 55
asset size profiling. One extra boost in cutting down the file size is to use reduced .NET libraries.
Using a subset of .NET means that you cut out a lot of the uncommon functional- ity and leave in place all of the main parts of .NET used in most Unity games. This will cut down the overall file size dramatically as well as cut down the memory footprint your game makes as it is running on iOS devices. .NET 2.0 includes the full .NET Mono libraries. The .NET 2.0 Subset only includes a smaller subset of libraries, to reduce file size.
3.2.21 AOT Compilation Options
AOT stands for “Ahead of Time.” AOT compilation is the act of compiling an interme- diate language, such as Java bytecode or .NET Common Intermediate Language (CIL) code, into a system-dependent binary. The binary, in our case, is the app file itself—the file that gets run by the iOS device and makes up your iOS game.
3.2.22 SDK Version
With Unity, there should be no real reason to worry about this setting. It refers to which version of the Apple iOS SDK that Xcode will use to compile your app with. There are options here to compile to the Simulator, which, sadly, at the time of writing is still not something that Unity can actually do.
There are too many options in here to go through one by one, but the ones you will use most are
y iOS Latest. Uses the latest iOS only. For most cases this is the best and easiest option; and
y Unknown. Xcode will manage the SDK version, not Unity. This is for advanced users only.
3.2.23 Target iOS Version
Even though iOS has gone through so many changes and seen so many different ver- sions, it is still possible to build versions of your game that will run on older versions, which is useful to us in supporting those iOS device owners who may have chosen not to or are unable to update their OS to the latest version. There may be features missing from older versions, but we usually want to at least try our best to support them.
Setting this to Unknown is usually enough. When you build your project, Xcode will use its default settings and you should be able to go ahead and compile without any trouble.
3.2.24 Stripping Level (Pro Feature)
If you are not a Unity iOS Pro user, you can skip this section. It’s not much of a party, though, so try not to feel left out. Only Unity iOS Pro offers the opportunity to strip out some of the unused (or least-used) libraries from your build, reducing the application file size substantially.
For extra information on this (such as how to put together a per project custom stripping black list), take a look at the “Optimizing the Size of the Built iOS Player” sec- tion2 in the Unity documentation.
As a quick heads up, if you ever start seeing strange errors you should disable any stripping options before starting to debug. Although Unity handles stripping really well, it may on occasion cause problems that might not have obvious causes, so it’s always a good thing to rule this out early on. Don’t let that scare you off, of course, since stripping is a fantastic way to reduce the download size and memory footprint of your games.
The three settings for stripping are:
y Strip assemblies. Script byte code is analyzed and classes and methods that are not referenced from scripts are removed; essentially, this cuts out the bits of the engine that you aren’t using. Be aware that this may, occasionally, get it wrong. If your scripts use reflection, this can be a common area for the strip- ping to fail.
y Strip byte code. .NET DLLs are stripped down to metadata only. This substan- tially reduces file size. Note that this will not affect performance, but will make for a smaller download.
y Use micro mscorlib. With this setting, several of the least-used components are removed from the core .NET libraries. If your code uses System classes (such as System.XML), you should use this option carefully. Most of the basics you need to achieve in Unity will be there, but if you’re getting heavy and you’re having troubles, you might want to keep an eye on this.
3.2.25 Script-Call Optimization
There are two options for script calling. One is used during testing and debugging to make sure that errors are caught and reported, and the other is used in a final release.
The Slow and Safe setting means that errors are usually caught, but scripts may be slightly slower than the alternative option—Fast but No Exceptions, which is the option you want selected when it is time to build and send your game to Apple.