Universal Windows Platform (UWP) build settings
To create a build for UWP, go to Build Settings (menu: File > Build Settings). In the Platform list, select Universal Windows Platform An IAP feature that supports Microsoft’s In App Purchase simulator, which allows you to test IAP purchase flows on devices before publishing your application. More info
See in Glossary , then select the Switch Platform button.
Note: Universal Windows Platform only shows in the Platform list if you’re using Unity on a Windows computer.
Unity doesn’t support Windows Phone development.
Building UWP applications with Unity
The main workflow when building a game or application for UWP using Unity is as follows:
When you click Build in the Build Settings window:
Unity generates and exports a Visual Studio Project.
Open the generated Project’s .sln file in Visual Studio.
Use Visual Studio to build your final application.
When you click Build And Run, Unity builds an app executable that can run independently.
UWP Build Settings
Use these settings to configure how Unity builds your application.
Setting | Function | |
---|---|---|
Target Device | Choose from the following options to build your app for any device, or select a specific device: Any device, PC, Mobile, or HoloLens. | |
Architecture | Select the type of CPU to build for (only applies to Build And Run). | |
x64 | 64-bit CPU. | |
x86 | 32-bit CPU. | |
ARM | 32-bit ARM CPU. | |
ARM64 | 64-bit ARM CPU. | |
Build Type | Select the type of Visual Studio project or build to generate. | |
XAML Project | Visual Studio project that integrates Unity within a full XAML environment. This results in some performance loss, but lets you use XAML elements in your application. | |
D3D Project | Visual Studio project that integrates Unity in a basic app window. This results in the best performance. | |
Executable Only | Hosts the project in a pre-built executable for rapid iteration. This setting has the quickest iteration speed because it doesn’t require you to build the generated project in Visual Studio. It offers the same performance as D3D Project builds. | |
Target SDK Version | The Windows 10 SDK installed on the local PC to build the application against. This setting is only relevant when calling Windows 10 APIs directly from scripts. Note: Unity requires the base Windows 10 SDK version 10.0.10240.0 or higher for building UWP apps, and doesn’t support Windows 8/8.1 SDKs. | |
Minimum Platform Version | Minimum Windows 10 release version required to run the app. Note: This setting is only relevant if you’re using Windows features or APIs that aren’t available in the base Windows 10 version (10.0.10240). | |
Visual Studio Version | Target a specific Visual Studio release if you have multiple versions installed. | |
Build and Run on | Select the target device or transport to deploy and launch the app during Build And Run. | |
Local Machine | Deploys and launches the app on the local PC. | |
USB Device | Deploys and launches the app on a remote device over a USB connection. | |
Remote Device (via Device Portal) | Deploys and launches the app to a connected device over the Device Portal transport. To deploy over the Device Portal, you must enter the connection and authentication information in these additional fields: — Device Portal Address (required) For more information, see documentation on Windows Device Portal deployment. | |
Build Configuration | Select the build type (only applies to Build And Run). Note: These build configurations are the same as those available in the Visual Studio project that Unity generates. | |
Debug | Produces a build that contains additional code you can use for debugging, and enables the Profiler A window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating or in your game logic. More info See in Glossary for your build. | |
Release | Produces a build that has debug code stripped out, and enables the Profiler for your build. | |
Master | Produces a build that is fully optimized for release. | |
Copy References | Disable this setting to allow the generated solution to reference Unity files from Unity’s installation folder instead of copying them to the build folder. This can save up to 10 GB of disk space, but you can’t copy the build folder to another PC. Unity also builds your application faster when you disable this setting. | |
Copy PDB files | Enable this setting to include Microsoft program database (PDB) files in the built Standalone Player. PDB files contain debugging information for your application, but might increase the size of your Player. For more information, see documentation on Windows debugging. | |
Development Build A development build includes debug symbols and enables the Profiler. More info See in Glossary | A development build includes scripting debug symbols. When you select the Development Build setting, you can also select the Autoconnect Profiler, Script Debugging, and Scripts Only Build setting. It also enables the DEVELOPMENT_BUILD #define. For more information about #define directives, see documentation on Platform dependent compilation. | |
Autoconnect Profiler | Automatically connect the Profiler to the build. Only available if you enable the Development Build setting. For more information on the Profiler, see Profiler overview. | |
Deep Profiling | When you enable Deep Profiling, Unity profiles all of your script code and records all function calls. This is useful to pinpoint performance issues with your game code. However, it uses a lot of memory and might not work with very complex scripts A piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info See in Glossary . For more information, see documentation on deep profiling. | |
Script Debugging | Attach script debuggers to the Player remotely. Only available if you enable the Development Build setting. | |
Scripts Only Build | Enable this setting to build just the scripts in the current Project. Only available if you enable the Development Build setting. Once enabled, Unity only rebuilds the scripts in your application, and leaves data files from a previously executed build intact. It significantly improves iteration times if you only change the code in your application. Configuring for Windows StoreIntroductionThis guide describes the process of establishing the digital records and relationships necessary for a Unity game to interact with an In-App Purchase Store. The Unity IAP Abbreviation of Unity In App Purchase In-App Purchase (IAP) is the process of transacting money for digital goods. A platform’s Store allows purchase of Products representing digital goods. These Products have an Identifier, typically of string datatype. Products have Types to represent their durability: subscription, consumable (capable of being rebought), and non-consumable (capable of being bought once) are the most common. Windows StoreIntroductionWindows App Development offers both local and remote Windows Store client-server IAP testing. This page covers local testing with the emulator and a simulated billing system, then Windows Store testing which limits app publication visibility to those with the app’s link. NOTE: This guide targets Windows 10 Universal SDK. Other Windows targets are available. NOTE: Unity versions 5.6+ support IL2CPP A Unity-developed scripting back-end which you can use as an alternative to Mono when building projects for some platforms. More info Getting startedKeep the game’s product identifiers on-hand for use in Microsoft’s Windows Dev Center Dashboard to perform remote Windows Store testing later. Test IAP locallyMicrosoft offers a simulated billing system, permitting local testing of IAP. This removes the need to configure anything on the Windows Dev Center or communicate with the the Windows Store via the app for initial integration testing. Configuring local testing is far simpler than for remote Store testing, although it requires temporary code changes to the app which need to be removed before app publication. To test IAP locally: Enable the simulated billing system in code where Unity IAP is initialized with its ConfigurationBuilder instance. WARNING: Remove these code changes after testing, before publishing to the Store; otherwise the app will not transact any real money via IAP! Build the application in Unity for Universal Windows Platform An IAP feature that supports Microsoft’s In App Purchase simulator, which allows you to test IAP purchase flows on devices before publishing your application. More info Open the application in Visual Studio and run the Local Machine target for x86. Remove the simulated billing system from code. Register the App on the Windows StoreOnce basic IAP functionality has been tested locally, you can more confidently begin working with the Windows Store. This test confirms that the app has all necessary IAPs registered correctly to permit purchasing. For testing IAP and publication use the Windows Dev Center and configure the app with a limited visibility. This limits the app’s visibility to those who have its direct link. NOTE: Testing on the Store also requires Certification, which may serve as an obstacle to testing. It is therefore important to complete testing locally before proceeding to testing with Windows Store. Reserve the app name. To test IAP with the Windows Store, the Windows Dev Center needs the published app. Click Pricing and availability and limit the app’s Store visibility so that it is only available to users who have the app’s direct link. In “Distribution and visibility” see a list of the Store’s available publication behaviors. Select Hide this app in the Store. Collect the direct link. This will be used to install the app on a Windows 10 device for testing. Submit the app for Certification. Submissions may take many hours to complete, and blocking issues may be raised by Microsoft Certification, which you will need to address before the submission passes successfully. Add In-App Products on the StoreAdd each IAP, setting the price to be “free” so that no money will be transacted during testing. After the test is completed, reconfigure the IAP with the desired price and republish it. See IAP Submissions. In the new app’s “App overview” page, click Create a new IAP . Enter the product ID. Configure the type, price, and language. NOTE: For Pricing and availability choose free for testing purposes to avoid incurring unnecessary financial charges. When you’re finished with testing, update and re-submit each IAP with the desired price in preparation for release to the public. Select Properties to set the type. Select Pricing and availability to set the price choosing Free as explained above. Select Manage languages and declare the supported languages. Select the declared language when returned to the IAP overview. Populate the Title, Description and Icon. Submit the IAP for Certification. As with apps, IAP submissions may take many hours to complete, and blocking issues may be raised by Microsoft Certification which you will need to address before the submission passes successfully.
Test IAP with the StoreThese steps follow a branch of the beta test process made possible with Windows Store. This involves limiting the visibility of the app itself, negating discovery by the public through the “Search Store” function. See Windows Dev Centre resources on beta testing and targeted distribution for more information. Confirm both the app and IAPs have completed Certification. Install the app on a Windows 10 device via the direct link, generated above. After passing test, update the IAP with the desired public pricing, update the app visibility settings to share with the general public, and submit both kinds of changes for final Certification. |