Q&A: Understanding the pain points of Unity developers

Alyssa Syharath, Unity Engineer: This makes sense to me. Unity development requires a high level of efficiency. 

Unity developers have to define their workflows as the engine doesn’t ship with a specified one, and so extensions to shortcut and/or make that process easier result in huge time savings.

AS: This is purely speculative as I don’t really know, but I wonder if the standardization of iOS has something to do with it. Android, I’ve found, tends to be more “bespoke” in many ways. As a result, it wouldn’t surprise me if it’s more a matter of what is readily available. That is: I suspect that the standardized iOS development environment makes automation significantly lower-hanging fruit than on Android.

AS: This one is a little more difficult to answer. “Systems and processes” can refer to a lot of things and requirements, and in many cases a developer can have a lot less power to be able to interface with them and change team processes than we’d like.
The only thing, in my experience, that can be done is to open dialogue with team members who might be able to help prioritize simplifying or automating these processes — this could be your manager or an engineer of higher seniority.

Generally speaking, I think that many to-dos or items that a developer has to make sure to do, are things that can be automated. This has the direct benefit of reducing the number of steps, systems, and/or processes that they have to “follow” because technology does it for them. However, that’s a tradeoff in many ways, as now that code has to be maintained as well.

AS: I think of this as a result of the lack of tooling implying the lack of defined workflows. This can often create a lack of parallelizable work, leaving other developers  waiting for some key piece of the pipeline to be defined and operational (getting back to the lack of helpful tooling). 

Teams with specific functions (such as an art team, a tools engineering team, and a gameplay engineering team) can’t effectively work together and there tends to be a higher dependency on the engineers closest to the “frontline,” as it were.

AS: I think this depends on a lot of factors. If I release a hobby game on the app store, I’d care more about active users. I want to know if people are using my app at all and what I can learn from that.

 If I’m a part of a larger team, with a marketing budget, etc., we’re having much bigger problems if the active user count is too low. Instead, I’d care about the app crash rate and customer complaints. I want to fix what’s wrong and make the experience smoother more than I want to grow my user base; essentially, my strategy shifts towards not losing players in the first five minutes, rather than growing with users.

Building the best possible Unity app requires a cohesive team effort, from individual contributors to managers to leadership; the entire team needs to be aligned, streamlined in process, and precise in execution.

After surveying ICs, managers, and senior leaders, we discovered that there are a few places where Unity teams are misaligned.

You can discover where and learn more about the needs of developers by downloading the 2024 Unity Mobile Developer Pain Points Report, here.