Although most PC games are made for Windows, iOS development is still a huge driver for people to use Unity on a Mac. Though I am now focused on PC games instead of mobile, I still prefer to work on my Mac since it can build for both Windows and Mac, and Windows generally drives me up a wall.
It’s the 2021 MacbookPro M1 Max with 64 GB ram (it was the top spec when it was released). It has the latest OS version, and works perfectly in other other applications.
I haven’t checked the log files for the Unity editor itself, but I assume (maybe incorrectly) that any relevant log files are submitted as part of bug reports after Unity crashes, and I’ve submitted a few (I stopped submitting the same bug report multiple times).
But I have to say that the responses I get from Unity regarding my bug reports is less than stellar. It always feels like I’m dealing with junior employees that can’t even figure out how to set up a Unity project to reproduce an issue, even if it’s very basic steps. I don’t know if it’s laziness or ineptitude.
that is too be expected, dedicated level of technical support is a paid feature for the enterprise level plan.
the usual process for the rest of developer is to try to narrow down for them the issue so when submitting a bug report (not that automatic error report after crash but a custom bug report) this junior dev can confidently send the ticket to a particular team that works on the feature that appear to be the culprit for the bug.
so is why you need to check the logs and see if there is anything that can help you narrow down what is going on, so when you write the bug report you can say, log says X about this and that and gives this error.
offcourse this approach fails if you don’t have technical knowledge on how a game engine works and how a GPU works and stuff like that.
you can check tickets opened here. and how they are composed
problem with notebooks is that they will fail behind with their GPUs at some point. I’ve not tested unity 6 so well to give you a definitive answer but newer game engines at some point they will struggle to work on older hardware even if a few years back. because they keep adding stuff that requires a certain amount of power that older GPUs, while supporting, they can’t keep up with the demand. This is just like a trivia it may have nothing to do with your case.
One last thing that is specific with Apple is that they have a history of being hostile with anything that is not made by them, like for example limited to no support for open source graphic libraries like Vulkan or opengl just to force people in using Metal (and get a device from them so they can publish on their ecosystem). Another thing they do is to mess with their clients hardware to force you to update, I would not dismiss that some sort of driver support on apple side it at fault here, who knows. They always have plausibility deniability.
Anyway, search other tickets maybe there are other people with the same issue, try to figure out the log information
Yep, i’m here to +1
Totally agree, i would say, since Unity 5 there is a steady decline in quality for sure, my favorite version was Unity 2019 tho, for me it was almost perfect, no bugs, no crashes, a bit slow building projects but meh, i was always a big fan of unity those days but now, with Unity 6 (an 2023) i’ve experienced bugs, specially when import my own objects, Lightmaping, world building tools (i reported a bug that was never fixed btw) all that is the reflection of bad management, bad decisions, wrong vision etc… I was hoping Unity 6 to be better, like Unity 5 but nop, i made a mistake to update my game to unity 6 and now i have to deal with all those bugs, crashes etc -.-" even for the kind of basic game i’m doing and tbh i also don’t have any good expectation of unity 7, but let’s see how it goes
I’m a new user this year, and now that I’m actually trying to build real levels, even a small one, my machine hard freezes . So now I do wonder if I should move to a version prior to 6.
I don’t do complex projects that might benefit form Unity 6’s latest features.
But based on what I’ve seen, Unity 6 is simply slower and frustrating, loading bars anywhere whenever I do small changes in the script. Idk if I’m doing anything wrong.
But I don’t think I’d ever use Unity 6 having Unity 2019, 2020, which are lightning fast and are very capable.
Very well could have been. After several hard freezes in a row, posted Nvidia drivers and let them do a “producer settings”, the same project for whatever reason hasn’t crashed since. Coincidence, or video card issues. RTX2060, not super oldz
same here. unity 6 has great stuff, but stability’s been a mixed bag - UI Toolkit/USS, enter-play-mode options, Burst/jobs, and package upgrades seem especially brittle after editor restarts or domain reloads
for production I’d pin everything: lock Packages/manifest.json versions, freeze the editor minor version, and do upgrades in a separate branch with a test gate (edit/playmode tests + a smoke scene) before merging. Treat the jump from 2018 → 2022 → U6 like an engine migration, not an update - so expect serialization quirks, asset pipeline differences, and shader reimports to surface bugs that look like “your code” until you bisect
for triage: when you hit freezes, attach the Profiler to the Editor, capture a few seconds, and grab Editor.log + call stacks (disable Burst, Jobs, and “Enter Play Mode Options (fast)” to see if symptoms vanish). Strip to a minimal repro by temporarily removing packages and asmdefs until the issue disappears, then re-add to find the culprit; clear Library/ only once you’ve captured evidence.
for USS transitions dying after restart, I’ve worked around by re-attaching styles at OnEnable (root.styleSheets.Clear(); root.styleSheets.Add(ss);) or toggling the transition property on the next frame via schedule.Execute(...). A canary project on CI (headless -batchmode -nographics) has saved us from surprise regressions, and posting tracker IDs here helps others upvote/confirm. dont worry, you’re not alone, lots of us are basically doing QA, the best we can do is pin, gate, and share repros loudly
I kust wanted to say, I agree with most everyone here. Stability has always flipflopped. In my opinion, part of it just comes down to Unity fracturing so many systems over and over and not just picking a path.
We dont need 3x UI systems, 3x Render Pipelines, 2x Input Systems, 2x Particle Systems etc.
Things like XR they should have stabilized and defined a decade ago. That alone can stop someone going from 2017 to 6.x without major rewrites
I completely agree. The slow and steady decline of the quality of the editor has been remarkable. I appreciate a lot of the good about Unity, but with every SNAFU (the new pricing model, this security issue, the revamp with unity 6) the editor grows more and more time consuming – and less productive – to use. Just now, while I was typing this repose, I had the 6000.2.7f2 loading up and suddenly my computer completely froze requiring a hard reboot to fix. I will continue, for now, to develop with the previous version; simply because I cannot make progress with the, “recommended” editor version. I have put a lot of effort into developing my code base but I still have very serious reservations about making a second game with Unity. If the product does not improve greatly over the next year, I will likely be leaving the ecosystem (unfortunately).
Agree. Unity 6 is a stability disaster. It almost feels like devs have never made a game before. The mass interruptions in the work flow by the editor are just mindboggling. I’m debugging the editor as much as the game now.
Guys from Unity. If you are reading. You have to get you stuff together and fix your processes.
I mean I get it, it’s an era of vibe-everything (coding, testing) but good lord almighty, PLEASE do at least some basic tests on your LTS releases.
These releases are supposed to be stable.
How in hell the bug with unscrollable list view survived 3 LTS versions?
Now the basic UITK TextInput does not work on Web builds. And this already survived 6.3.11 and 6.3.12.
Do you EVER test anything? How is it possible that the basic functionality like scrolling of the list view and inputting a text in a text box gets broken and this lands into an LTS release? Let alone that this passes tests for 2+ versions.
And don’t even get me started on the attitude of fixing the reported issues (if they are getting fixed at all), because it is a joke.
We have 2 issues:
How on earth does fixing the first one did not fix the second one?
This is the same issue. Reproducing in the same scenario just with a different field type. What kind of work attitude you should have to take a look at the code, fix this specific case and only it, test this specific case and only it, close the bug report and say This is good. Good job me, I did well.
Are you kidding? Are you all robots? Do you even like what you do? How nobody in QA or in programming didn’t have a second thought that maybe, just maybe, this issue may also happen for a different field type or different UI system and the fact that this was reported for numbers type does not mean it should be fixed for numbers type and only numbers type.
Look, it has been confirmed and it does not work. End of discussion.
Works on your side for some reason? Good for you. Doesn’t work for me or any other person I have asked to test this. Works if “Hide soft keyboard” checkbox property is enabled. But in this case, the mobile keyboard will not appear, and the input will not be usable on devices without physical keyboard.
I have provided links in my post to the respective bugs. Basically, UI Toolkit projects of any complication are broken since 6.3.8.
6.3.8 broke list view scrolling. Fixed in 6.3.11. And 6.3.11 broke text input. So the last “good” version is 6.3.7, which was released Feb 5th.
This is not normal to have a “stable” LTS release being broken for almost 2 months.
