The Top 5 Mistakes When Updating?Unity

Hi. I want to share insights from my experience on avoiding mistakes when you update the current Unity version.?

Why do you have to update Unity? For example:

• Compliance with store/platform updates. Like the recent compliance from Apple for 2024, to be able to submit new versions.
• Access to the new features and improvements. Like Accelerator corruption detection or Splines Package for 2022.1
• Access to New Technologies. Like support Magic Leap 2

The most frequent reasons are when we must take new versions in mobile game development because Google has requirements to support recent API versions for new submissions, for instance, or you can try to fix some crashes or bugs. My context of experience is based on mobile games with 1 Mln DAU, a studio size of 150–200 people, and a project life of more than seven years in production. We take only LTS versions and try to decrease updates as much as possible.

Taking the newest LTS?version

Any new LTS, or even a minor Unity version within one major, is super dangerous for your stability in production. Please carefully read the summary of the release changes. You have to get significant reasons and benefits for updating the Unity. Not all releases will give a value for you. Minor updates will be more straightforward because you usually do not break remote content or third parties.?

But any new LTS, or even minor, will be able to make your crash/ANR metrics in production dramatically worse. The advice for the Unity minor version is to take a new version between your current one and the new one when you see Known issues in the change logs and no active threads in the Unity forum about your target Unity version for update. When Unity releases a new LTS version, it does not mean you should take this immediately. Let's wait for 9–12 minor releases within the LTS in your production to avoid as many surprises as possible.

Update Unity without?VCS.

Nowadays, it is hard to imagine working in a team without VCS and synchronizing work increments. But for Unity updates, working with VCS and backing up your project and history of changes is essential.?

Because a new Unity can easily break your code or assets when reimporting them and upgrading the code. The modified project can become incompatible with the current Unity. The primary advice is that you have VCS for a project.

Updating Unity without any?plan

Your plan should include rolling out the new Unity inside your studio and gradually opening up your production.?

Have you scheduled a time slot in your product roadmap? Are all artists and level designers ready for the update? All tools for them are working correctly? Have you synchronized the update with CI/CD? Do you have a rollback plan in case of issues in production? Do you have regressions suitable for such an update? Any Unity major update stresses your people in the studio, especially when you support old clients without forcing them to take the new client version.

The most tricky thing is an effort for your Life OPS team to operate content for old and new clients. Yep, it is easy to break prod by mistakes from Life OPS, and building a plan for them is crucial, too.

Updating Unity without proper?testing

When taking the new Unity version, you can easily break any dependency in your project or some third party. Usually, for major LTS, you have to test everything: all third parties, all remote content, levels, the full gameplay, etc.?

Let's start checking a new version from the developer side. Upgrade one ci/cd agent for building content and clients. The developer can verify critical paths in your development cycle, update all dependencies, and prepare a technical release. Next, specific tools should be verified by artists/level designers/tech art, etc. Finally, QA can make all deep regression tests on supported platforms to verify the most important third parties like Appsflyer and parts of gameplay.

You must incrementally update a new branch with the new Unity version with all changes from your regular development, avoiding too many changes at the end with too many risks.

Production Rollout without Technical release

Even if you have 30 QA specialists and good regression test cases with automation, it is impossible to get all possible variations of troubles without production and a piece of your DAU. For instance, there are so many combinations of Android devices with OS versions and hardware worldwide. I published material on How To Make Safer Mobile Roll-out Releases. The primary advice is to have a technical release before the full production rollout.

Have the fastest, most stable Unity updates without production incidents!

If you liked this article, please show your support by ?? this article or follow me to get the latest publications in the future.

Thank you for reading!