Disclaimer: this is an automatic aggregator which pulls feeds and comments from many blogs of contributors that have contributed to the Mono project. The contents of these blog entries do not necessarily reflect Xamarin's position.

May 24

Breakout! How to stop an infinite loop in a Unity C# script.

(or what I did at my first Hack Week with Unity)

This post is about a little trick for breaking infinite loops in scripts in Unity. It works with Windows / 64 bit in the Editor and in 64 bit builds with script debugging enabled. With a little more effort it can be made to work on 32 bit and even builds with script debugging disabled.

Infinite loops seems to be something that should be easily avoidable. But from time to time, I’ve encountered them in sneaky variants. Once it was the broken random function returning 1.000001 on impossibly rare cases. Another time a degenerate mesh sent a NaN right into an unsuspecting while(1) { d += 1.0; if(d>10.0) break; /* .. */ } loop. And then there was the broken data structure traversed by an algorithm that assumed current = current.next; would surely lead to an end eventually.

If you have experienced an infinite loop in your script code in Unity, you know it is quite unpleasant. Unity becomes unresponsive and you may have to kill the Editor entirely to get out of the mess. If you were lucky enough to have the debugger attached before running your game, you may be able to break it. But usually only if you can guess the right place in the code to set a breakpoint.

Some years back, before joining Unity, I found a way to break a script that is stuck like this. But it was not until my first Hack Week here, that I got to talk to the right people and realized why the trick works and how it may be used to create a proper way to break scripts in Unity (sneak peek of my Hack Week project). Until we get that feature properly done and release it, you can use the trick below. Or just hang on for the fun of a little tour into disassembled, jit’ed code. What could possibly go wrong?

Do not try this at work!

As a trained professional you know the value of practice, so try this out on a toy project before you attempt a rescue operation at work. Fire up Unity and create an empty project, add a box to an empty scene and create a new C# script “Quicksand” attached to the box. The script should contain this code:

using UnityEngine;
class Quicksand : public Monobehaviour
            public OnMouseDown()
                   // "Mind you, you'll keep sinking forever!!", -- My mom

Now hit play and click the box. Observe Unity freeze up and experience the onsetting rush of panic until you remember that this is just a test. No actual work is going to be harmed!

So now your script is stuck and Unity seems to be hung. Let us start up a new instance of Visual Studio.

For this to work you probably (I didn’t check to be honest) need to have selected C++ as one of the languages when you installed VS. Go to Debug menu and select Attach to Process (NOTE: this is not the same option you usually choose for attaching to Unity). Locate the Unity process and attach to it.


Having attached the debugger to the stuck Unity, select “Debug | Break all” and find the disassembly view showing the code currently executing on the main thread. The following gif shows the little dance you have to perform. Perhaps you even need to click on “show disassembly” or something like that depending on your configuration of Visual Studio. (On one machine where I tried it, I had to hit F10, which does a single-step, for the disassembly to show).


As you maybe know, the scripts are — for performance reasons — translated into machine code on the fly before being executed. This is known as jit-compiling (just-in-time compiling). The result is what you see in the disassembly window. Hopefully it looks something like this:


In this case you can almost see the infinite loop (indicated by the red arrow I have artistically rendered on top of the screen snip). There is one mov, one cmp and a lot of nop’s and then the jmp loops right back to where we started. No escape!

In a more realistic case, your C# code will be more complicated, and it will be harder to tell what is going on, but you don’t really have to understand it, because here comes the trick: hit F10 (single step) a number of times until you get to one of the “cmp dword ptr [r11], 0″ instructions. They should be sprinkled liberally all over the code because they are part of the debugging infrastructure. After a few steps, you may end up with something like this:


With a bit of luck you already have a window named “Autos” (if not, use Debug | Windows | Auto to find it). It should show you the value of the registers that are in play at this point:


Now simply change the value of R11 to 0. Like this:


If you were to execute the cmp instruction now, it would try to read from address 0 which is going to generate an exception. And that is actually exactly what we want: So hit F5 (continue program execution) and answer “Continue” to the dialog box that pops up:


If all went well, you now get a proper (Mono-)exception in Unity, the loop is broken and Unity is back to normal. You can save your work and look at the call stack in the Console to see which part of your script code caused the hang.


That’s it. Go forth and loop! A little warning is in place: you have now messed around pretty deep inside Unity and it is prudent to save your work (if needed) and restart the Editor. My experience is that everything seem quite healthy, but just to be on the safe side.

Why does this hack work?

The reason this works at all is that Mono has a built in system for debugging scripts. It works by sprinkling (actually, once for each C# line) the jit-code with reads from a specific memory address. That is the “cmp dword ptr [r11], 0” instructions we saw above. When you are in debugging mode and are single stepping through your code, the page that holds this memory address is made read-only and we will hit an exception once for every C# line of code. The Mono framework can catch this outside of the jit-ed code and basically pause the execution after every line.

The trick we did above, where we set the register r11 to be 0, will end up generating the same type of exception, because the address 0 is never readable. So the debugging framework sees something that looks like single-stepping, but because we are not really debugging, a NullReferenceException is generated and we get a nice call stack. Very convenient!

This technique also works for standalone games. You attach to yourgame.exe, break all, find the jit code, force a memory fault and you should be good. You will have to look up the call stack in the log file, though.

Corner cases

The example we just looked at was, to put it mildly, conveniently simplified for tutorial purposes! In reality, there are a number of catches you may run into. When you hit “break all” you may not actually break into ‘clean’ jit’ed code. If your C# code makes use of any API calls, the program might be inside some of the core Unity code. It will look like this:


Here we see the program having called into GetPosition. When the top of the Call stack contains real function names and not just hex addresses, it is usually a sign we have left mono / jit’ed code. But just hit Shift-F11 (Step Out) a few times until you are back in jit-land (nop’s galore is also a good indicator of jit-code).

Sometimes you can manage to break Unity at a point where the main thread is not active. It is probably easiest just to continue (F5) and then break all again until the main thread is active.

There are probably more weird cases, but hey, this is debugging, so improvisation is key!

What about 32bit

You can do something similar in 32bit mode. The jit-code looks a little different. Perhaps something like this:


This means we read from 0xB10000 in this case. To provoke a page fault, you need to actually change the code because the address is hardcoded directly in the instruction and not in a register as with 64 bit. So you open a memory view (Debug | Windows | Memory | Memory1) and navigate to the address of the instruction (the yellow arrow), that is, 0x65163DC in our case. Here we find:


You can recognize the address: it is the “b1” found 4 bytes in from the start. Change it to 00 and then continue (F5) as before. This will have the same effect, but with the difference from the 64 bit case, that you will break out every time you hit this location.

So what about non debug mode?

Ok if you are really unlucky, you may have a bug that is only reproducible when you compile your scripts with debugging disabled. In this case you have to improvise a bit. If you can look at the code and find a way to provoke a read fault you should be golden, but it may or may not be super easy. As a last resort you may need to inject, manually, something like cmp eax, dword ptr ds:[0x0] which we know from above happens to be the sequence 3b 05 00 00 00 00. But maybe we are a bit more lucky. Let us try our example script from above. Breaking it yields:


Oh no! The worst. The compiler optimized it to just one jmp instruction looping on itself. There isn’t even room for adding in our cmp (the jmp is relative and only takes up 2 bytes). However, since we are assuming everyone is desperate (a release build hung, after all) we don’t have to be too careful and can just trash the code with our read. Navigate to 4D34446 in the memory window and fill in 3b 05 00 00 00 00 on top on whatever is there. Hit continue (F5) and hope. In my case the game (I was doing this part of the test with a standalone game)  came back to life and I could inspect the output log to find:


At this point you really should shut down the game as you have effectively ruined a part of the jit generated code and your scripts will likely not work anymore. But at least you know where you were stuck.

Sometimes you can find a read instruction in the vicinity of where you stopped. Then you can right click on it, select “Set next statement” and by setting a register to 0 you may be able to create the right exception that way.


So with a bit of trickery it seems unbreakable loops are in fact breakable. Hurry up and try it out so you can join the ranks of grizzled veterans growling “Ha! In my days we did it in disassembly!”. Soon we’ll ship a better solution and it will be forever too late!

May 19

Make your Daydreams a reality

It was really exciting to see John Riccitiello, our CEO, on stage today at Google i/o with Clay Bavor as they walked through the details about their new Daydream VR product.  We believe that Google shares our vision of democratizing development, and ultimately democratizing VR, which is what makes our partnership so exciting. 

Furthermore, we think mobile is going to be a key part of that, which is an easy conclusion to reach just by doing the math. With an installed base of around 3 Billion in 2016, mobile devices are already dwarfing the 1.5 Billion PCs.  That makes Daydream particularly interesting from a mass market perspective and it very smartly fits into our strategy of creating a platform that allows any developer to create once and publish everywhere.

You may have heard us talk about the “gap of disappointment,” or the slower than suspected start to VR adoption/content this year. Daydream, as well as other platforms like Samsung’s GearVR are going to help drive what we ultimately think will be massive adoption of VR globally on the scale of Billions of people 10 years out. That’s no small number, and we believe it will be just that big.

We also announced today that we will be supporting Vulkan, and plan to give early access to developers in Q3 of this year.  We’re committed to solving hard problems for our developers, and we believe these announcements are aimed at doing just that.  In the end, we want people to create amazing experiences that will delight consumers across the globe.  It’s an amazing journey we’re on, go out and dream, then use Unity to bring those dreams to life.

How Next Games unlocked the secret to ad success

‘You can’t put ads in a battle builder,’ Next Games’ peers told them. ‘No one’s ever done it and it will never work.’ This was the general message that Next Games – one of the stars of Helsinki’s thriving mobile games scene – got from their fellow developers when they pegged them for feedback on their monetization plans.

Rather than abandoning the idea of using a view-to-play model in their two breakaway hit games – the IP-based battle builder, Compass Point: West, and the strategy game, The Walking Dead: No Man’s Land, based on the popular comic book and AMC TV series – Next Games decided to go about it in a different way. Instead, Next Games put extra effort into incorporating the video ads in a way that added to the overall game experience, enticing players to immerse themselves even deeper in the game.


As Saara Bergström, Next Games’ CMO, put it, “the increased engagement and retention from a good video ads experience puts money in our pocket from the increased lifetime value of our players.”

After some monetization research, Next Games knew that video ads, if integrated in the right way, would indeed work in both their titles. The trick was that they had to design and fit ads into the natural gameplay experience.

Next Games implemented this approach by integrating rewarded video ads into their games, using their own lead game designer to make them feel like a natural part of gameplay. What’s more, the technical integration was – as Bergström said – “remarkably painless.”

Find out how Next Game’s players have embraced rewarded video ads and both engagement and retention has skyrocketed.

Read the full case story

Screen Shot 2016-05-19 at 14.13.24

May 18

The Unity Engine QA Process

We often get requests to explain how we test the engine before we release it. We have previously blogged about it, but none of these posts give a clear overview of the entire process. It’s a large undertaking to do in just one post and for that reason this will be a series of blog posts.

This first post is going to outline the structure of our test efforts and subsequent blog posts will be made to describe details of each individual part, always linking back to this overview. It is also worth noting that every strategy comes from the product and deployment model, so our process on the engine is very different from the process we use on our services. This blog series relates only to the Unity engine itself.

In the simplest form, our releases go through the following lifecycle:


This is what is most obvious to our users, because our version numbering follows the same structure. With this frame we can start exploring what happens at every stage of the product from a QA point of view.


Before we even get code into trunk where we integrate all the features, we do testing on the feature in a branch based off of our mainline source repo, trunk. This is typically feedback on the usability of the feature and ensuring it doesn’t introduce massive instability. How this is done effectively is a topic for a blog post of its own.


Once the feature has been tested in-branch, the developers create the initial Pull Request (PR) in which a code review is done on the code, all automation has been executed and proven to pass, a review of the test cases written is done and the Release Manager does a risk assessment before merging it to trunk. A lot of this is automated through our merge queue process, but it can involve 20-30 people to get a big feature into trunk. And remember, this process is done on every single PR going to trunk, not just one time.. All of these are blog topics for later.


In the alpha phase, it is all about integration of all the features done in the branches. Before we send the first alpha to the alpha list, we run our Release Acceptance Test (RAT), which is a smoke test covering the surface of the platforms and the editor to make sure we have human eyes on as many parts as possible before we ship.

During the following alphas we get more branches trickling in and we continue our integration testing on the builds. During this time we also get a lot of user feedback on the usability and viability of the features from our alpha users. This sometimes results in a feature being cut completely from the release.

In the end of the alpha phase we have an Exploratory Test (ET) week. This approach was  covered by Claus in 2013 and the format remains the same today.


The beta phase is now fully public, so we ship the builds directly to all users. Creating the engine with our community has been a key part of how we developed Unity through all the years and it is still an integral part of every release.

During the beta phase we do a Full Test Pass (FTP), which is a manual regression test pass of all our manual test cases, which test the various workflows and runtime features, spread across all the supported platforms, so we get as broad a surface as possible with human eyes and brains on all of it.

The FTPv2 is a special session we carry out to combine the workflows to make actual games with the build. It is a fun and intense way of testing Unity.

The Asset Store Bash is three days where we go through a list of Asset Store packages compiled from the top 500, upgrade the projects and see if they reveal problems in the builds.

The documentation bash is a few days where we go through our documentation in order to find bugs and discrepancies between the docs and the actual functionality in the engine.

We also execute upgrade tests, in which we take large user projects and upgrade them. It is surprisingly difficult to perform this test and we most certainly need a blog post explaining why this is so. We realize it is a source of a lot of user pain, so we invest a lot of effort in this.

image06 (1)

The release candidate phase is started off by an RC Test Phase where we do a risk driven pass on the engine. This risk assessment is done by the dev teams involved in each area and we use this to drive a targeted effort to get more comfortable with the state of the product before release.

We also run RATs on every one of the RC releases, because they are candidates to be released. As such we treat all of them as the last one.

Screenshot 2016-05-17 13.54.10

In the lifetime of a release we are constantly getting bugs reported by our users. Our community and users are the most important asset of Unity and we value this contribution more than anything else in the process of making a Unity version come to life. It is definitely not an easy task and we have posted multiple blog posts about how we handle this flow of bugs. Best place to read about it is The Great Incident Bash of 2015.

Throughout all our releases in the entire lifetime of the release we verify all bugs fixed. During verification we go through the steps to reproduce the bug, look around the immediate area around the fix to find fallout and then close it or reactivate it depending on the result.

During the lifetime of the engine, we also run our performance regression test suite multiple times. Sakari made a two part blog post about it two years ago and lots has happened since. It is a tough problem to solve consistently and we have invested a lot of effort into this, so we will make a part three to update you on what is going on these days.

It’s important to also understand that testing a platform is a separate discipline in itself. We are helped by having lots of our automation be able to run on all our platforms, but there is a lot of custom manual testing needed for each platform because they all have their independent functionality to consider.


Once a version has been shipped, it goes into sustained engineering (SE) mode. This team was founded two years ago and a lot has happened since. They are responsible for all the patches we send out and we will most certainly create an updated blogpost about how this team is now functioning.

I hope this sheds some light on the overall process of shipping a piece of software as complicated as Unity. We will post a lot more blogs about the details of all these parts. The automation we are doing is such a big part of our process and ability to ship all these platforms, so we will create a similar overview post dedicated to this.

May 17

Unity Beta Tips: How to participate effectively in the beta program

As part of our ongoing commitment to both stability and innovation, we are unveiling some new and improved resources for Unity beta participants. These resources will help new and existing beta testers get the most out of the program, and ensure that the next stable version of Unity works for your project.

We’ve updated the beta page to include more information about how to participate in the beta program. In a nutshell here’s what we’ve got for you:

If you missed what’s coming to Unity 5.4, head over to this blog post and check out the new features and updates you can look forward to in the current beta.

We’re very excited to hear what you think about the new features, but it’s also important that we ensure existing projects continue to work well. This is why we are encouraging you to try Unity 5.4 on a copy of your projects first.

While our engineers test each beta version with numerous projects weekly, it’s only a fraction of the projects out there that are constantly pushing the engine in new and different ways. The best way to make sure the next stable version of Unity works for you and your project is to try it out with the current beta.

If you encounter a bug, be sure to let us know. To make sure you have the right information on how to submit a solid bug report we have created a “Guide to Being an Effective Beta Tester”. It takes you through the process of using the beta and reporting a bug, start-to-finish. The guide covers:

  1. Installation and getting started
  2. The beta forum
  3. Documenting and reporting your bug
  4. Following up

With that, you will be equipped to provide actionable feedback, so we can address bugs more quickly and effectively.

We also have a quick survey to better understand why you do (or don’t) participate in the beta program. Your opinion matters. All of that information is available on the beta page, along, of course, with the beta download link

May 16

Elizabeth Brown – One of Bay Area’s Most Influential Women

Congratulations to our very own Elizabeth Brown who has just been selected as one of San Francisco Business Times’ “Most Influential Women in Bay Area Business” for 2016!

Each year, San Francisco Business Times honors a select group of talented women for their accomplishments across a range of fields, including real estate, law, technology, retail, healthcare, finance, insurance and education. Not surprisingly, Elizabeth was recognized for her leadership, expertise, and outstanding community contributions.

Elizabeth, along with all of the other recipients, will be honored at The San Francisco Business Times’ gala event, taking place on June 16 in San Francisco.

We couldn’t be more proud of Elizabeth for receiving this award and look forward to celebrating with her at the gala event in June. For anyone interested in attending the event, you can register here.

May 14

Xamarin.Forms Workbooks

As explained in the last post, it's easy to add Nuget packages to Xamarin Workbooks. My immediate reaction to this news was "I want to use Xamarin.Forms!" Unfortunately it's not immediately obvious how to get Xamarin.Forms into a Workbook... so here are the steps (for an iOS Workbook):

1. Add the Xamarin.Forms nuget (and reference the platform)

When you add the Xamarin.Forms Nuget, four assemblies will be referenced (including the iOS Platform assembly for Xamarin.Forms). The using statements need to be added too - don't forget to add the Xamarin.Forms.Platform.iOS namespace:

2. Create a Page and App as usual

In both classes it's a good idea to create public properties for elements you want to manipulate in the workbook.

This allows those controls to be referenced later in the workbook...

3. Hack the FormsAppDelegate

The biggest hurdle to getting Xamarin.Forms to run is that in a normal iOS app, the AppDelegate must be a subclass of FormsApplicationDelegate to wire up various bits of Xamarin.Forms. Peeking into the open-source, the key thing we need to do is set the RootViewController... the following code does the initialization we need to get a Workbook running:

WARNING: obviously this approach misses some of the other code implemented in FormsApplicationDelegate so some things might not work as expected. This is a bit of a hack :)

4. Run It

The public properties on the App and Page classes mean the workbook can manipulate those elements to demonstrate various Xamarin.Forms capabilities.

Try it out with the WorkbookFormsTest workbook:

Check out the more complex ListView1 workbook too:

p.s. the irony of included screenshots of code is not lost on me - but hey, it's actually a good reason to download and us Xamarin Workbooks to try these samples out :D

Xamarin Workbooks with Nugets

Xamarin Workbooks are getting better and better (check out the intro to Workbooks if you don't know what I'm talking about).

Nuget packages can now be added, meaning you can teach or demo almost anything in a Workbook :)

In the Workbook app, choose File > Add Package... to open the Nuget package explorer:

Then search for the Nuget and add to the workbook:

Try out this Json.NET Workbook example to see how it works

Coming up next - adding the Xamarin.Forms nuget!

p.s. for a video demo of Nugets in Workbooks, check out this community contribution on brax.tv

May 13

Mobile Gaming Industry Trends – 2016 Q1

Unity Analytics released the second edition of the “Games by the Numbers” report, which employs data to reveal game install trends across different platforms, devices and regions. The infographic below summarizes the findings. Enjoy!

You can also download the full report here.


May 12

The Made with Unity Showcase @ Unite Europe Line-up!

First, a big thank you to everyone who submitted to our Made with Unity Showcase at Unite Europe!  Our goal was to pick 36 unique games of varying styles, genres, mechanics, and platforms and we’re pretty darned happy with group as a whole (which isn’t surprising given how many awesome games we had to make tough choices about).  We were overwhelmed with over 160 amazing submissions and can’t thank you enough for making our selection process insanely difficult.  

We worked with The MIX to create a new area within the conference dedicated exclusively to games and content created by the Unity community.  It’s a place where attendees, developers, and press can take a break from the conference to play some games and see what your industry peers have been up to.  There’s local four player lounges for you competitive types, new VR experiences to check out, and a whole lot of games to play on PC, console, and mobile.  We’re excited for you all to see it later this month!

Here’s the line-up for Unite Europe’s very first Made with Unity Showcase!

1979 REVOLUTION:  Black Friday Aragami Arizona Sunshine Beacon Black the Fall Clustertruck Cosmic Trip Death Trash Earthfall Euclidean Lands GLADIABOTS Her Majesty's SPIFFING Hidden Folks Hotlap Heroes Hue Immortal Redneck Jazon and the Dead Kung Fu for Kinect LASTFIGHT Mr. Future Ninja Oh My Godheads Overfall Ozhi Planet Nomads Pode P.O.L.L.E.N. Rex Odyssey Shadow Tactics:  Blades of the Shogun Shadow Fight 3 Skyhill Twisted Lines Tricky Towers The Uncertain: Episode 1. The last quiet day Windlands Winter Zombie Night Terror

The Made with Unity Showcase at Unite Europe will run for three days from Tuesday, May 31 through Thursday, June 2 during normal conference hours.  

May 11

Unity Launches a Series of ‘Women in Gaming’ Workshops

We have some exciting news to share! While talking internally about programs that would empower women and encourage participation in the greater gaming community, we realized we needed to think big, because it is super important that we do our part. With that in mind, we decided to create a series of global workshops to tackle some of the difficult topics around development of women’s careers in gaming, while offering women the opportunity to network and learn from each other about topics such as career building, leadership, strategic thinking and organizational dynamics.

We have selected a range of talented industry leaders with exceptional experience in their fields, who will share their experiences, insights, and best practices on how to improve strategic thinking, influencing, and career navigation in gaming.

The five events taking place in 2016 will be held on the dates and in the cities listed below. To learn more and to register for each event, click on the featured speaker listed below:

  • June 1, 2016: Amsterdam (as part of Unite Europe)
    • Confirmed speaker: Fiona Sperry, Founder, Three Fields Entertainment
  • June 20, 2016: San Francisco, CA
  • July 28, 2016: Shanghai (check Unity Chinese website for details)
    • Confirmed speakers: Amy Huang, AVP at NetEase Capital; Evelyn Liu, CTO at Firevale; and Yanyan Xiong (Shining Hsiong), Founder of Shenzhenware
  • September 22, 2016: San Francisco, CA
    • Confirmed speaker: Nanea Reeves, President & COO, textPlus
  • Early November, 2016: Los Angeles, CA (as part of Unite LA)

All events are free and open to public. We hope to see you there!

May 10

Unity and IPv6 Support

Apple recently announced that beginning June 1, 2016, “all apps submitted to the App Store must support IPv6-only networking.” Since many of our users publish Unity games to the App Store, we wanted to take a moment to discuss Unity’s support for IPv6-only networks. Note that this requirement applies to both new app submissions and updates to existing apps.

What is IPv6?

From the Wikipedia article: “Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet.” Devices can operate on an IPv4-only network (the previous standard), and IPv6-only network, or a network with both protocols in use. Apple’s new requirement means that apps must be able to operate in an IPv6-only network.

It is important to understand that IPv4 and IPv6 networks do not interoperate, although it is possible to pass traffic from one type of network over the other with tunnelling.

Does Unity support IPv6?

Yes! WWW and UnityWebRequest are IPv6 compatible on iOS out of the box because they are based on high level Apple networking APIs. And over the past few months we have been working to bring support for IPv6-only networks to Unity’s .NET/IL2CPP libraries. Our last known IPv6 bugs related to .NET/IL2CPP were corrected in the 5.3.4p4 patch release. There is one fix pending for UNET which is going to be shipped in coming weeks. Thanks to help from great members of our community (like Exit Games) we have been able root out a number of bugs in the Unity Engine code and provide support for IPv6-only networks on the following platforms:

  • Editor: All platforms
  • Standalone player: All platforms
  • iOS
  • Android

We’ll continue to add support for IPv6-only networks on other platforms in the future.

What about older versions of Unity?

If you are using only WWW or UnityWebRequest APIs to access network resources you should be fine, though please test your games carefully.

We are also planning to backport our .NET/IL2CPP fixes to selected older lines of Unity and release them as 4.7.2, 5.1.5 and 5.2.5 updates.

What should you do?

First, test your game in IPv6-only setup to assess if all the game features work as intended. This guide from Apple goes through the setup of an IPv6-only testing network using a Mac with OS X 10.11 or later. This is the same testing that App Store reviewers will use, so it is a good place to start with IPv6 testing. Since IPv4 and IPv6 networks cannot interoperate, you must test on an IPv6-only network to ensure everything is working well. If your device has both IPv6 and IPv4 addresses, then socket operations could succeed using IPv4.

Second, audit your code for a few indicators of possible problems:

  • Look for the use of IPv4 addresses (e.g., Any use of such hardcoded addresses should be removed. Prefer host names, which can be used to look up the proper IPv4 or IPv6 address of a given device for the proper type of network.
  • Look for the use of the IPAddress.AddressFamily property. If the code branches based on the value of the property, is there a branch that handles IPv6 properly?
  • Look for the use of the IPAddress.Any and IPAddress.Loopback fields. These fields work with IPv4 addresses, not IPv6 addresses. Use the IPAddress.IPv6Any and IPAddress.IPv6Loopback fields as well to ensure IPv6 support.

If you encounter troubles beyond the ones mentioned above, please make sure you are using a build with the necessary fix in it. If a fix has not yet landed in your line (4.7.x, 5.1.x, 5.2.x), wait until we have released a patch with it. Then proceed to upgrade to this version.

Some of 3rd party native and managed networking plugins might also be not compatible with IPv6 networks, please consider reaching out plugin vendor for their compatibility status.

Finally, let us know if you encounter bugs in Unity related to IPv6. We will work hard to correct them as soon as possible. For issues specifically related to the App Store requirements, visit the iOS and tvOS development section of our forums. I’ll be hanging out there to help.


Monologue is a window into the world, work, and lives of the community members and developers that make up the Mono Project, which is a free cross-platform development environment used primarily on Linux.

If you would rather follow Monologue using a newsreader, we provide the following feed:

RSS 2.0 Feed

Monologue is powered by Mono and the Monologue software.