So with UnityEngine.QualityLevel being obsolete, does this mean we have to hard code magic numbers?
before:
now:
read docs.
var qualityLevel = QualitySettings.GetQualityLevel ();
and
QualitySettings.names
Behaviour essentially identical. Bit more work, lots more flexibility 
It looks like we have to hard code numbers for the example I wrote above…I am trying to avoid hard coded numbers.
You can always make your own enum; there’s never any need for magic numbers.
–Eric
I was hoping that Unity would enforce this but of course anybody can go and make their own enums. Thanks for your input.
Honestly it never made sense to have a fixed number of quality levels. Having 6 might be OK for one project, but another would use 3, and you’d still be stuck with the same 6 built-in QualityLevels (and if you needed more than 6 for some reason, you were out of luck). It’s a lot more sensible just to make your own. You definitely don’t need to hard-code numbers in any case.
–Eric
The only thing I don’t like about this system is that I know a lot of people will go and use magic numbers without making their own enums. Then if Unity decided to add or remove quality levels then their code will behave completely different than what they intended. With a game engine like Unity where there are a lot of newbies I could see this being a problem…but your point is well taken.
Well, I can’t see how they could have a built-in enum, considering the number of quality levels is totally arbitrary now. If Unity adds or removes default quality levels it will have no effect since it’s per-project.
–Eric
I see what you are saying now. It seems like the whole Idea of having Fastest, Fast, Simple, Good, Beautiful, and Fantastic quality settings is out the door. These are just placeholder names that could be changed and deleted by the user. Got it. Thanks.