Updating a ListView while people are scrolling through the same list, without losing their places, would be a really bad user experience IMHO, but still technically doable I think. If many players are finishing simultaneously (ie, playing in groups of 10 or something, so 10 entries are added/update at once when they finish), the 'update the user interface' function that you make should process them all at once so you just do 1 rebuild there instead of 10. A message that appears somewhere saying "new entries, press X to refresh" or something would feel far better from a user perspective I think, as well as being far better for resource usage, and simpler to implement. A game usually runs 60 frames a second minimum, all players aren't all going to be pushing updates to the list every second, so you've got around 99% "no activity" and 1% "updating ListView" frames on there, even if you went with your realtime updates idea (and you can make this even less frequent by checking a ConcurrentQueue every 10 seconds or so instead of really being "realtime")- that's the "assumption" of frequency being talked about here, and by Google in the talks that they've given, and basically everywhere else- and the reason why Unity devs should just stay the course on this product. In my experience, the assumption is almost always correct, and it's what makes systems like this possible, so it's a good one to make. ListViews have apparently already been the focus of a lot of the optimization here, being one of the elements that's updated the most often (but still very infrequent), so I don't think you have a lot to worry about there as long as your usage isn't abusive. If you have a situation in which that assumption is not correct, well, I won't go so far as to say "you're doing something wrong", but you're definitely not in the "common use-case" area anymore, so you'll probably have to deal with it on your own (as with all things in game dev with abnormal requirements). As for animating... well, drag-and-dropping UI elements is also not too difficult, even right now at runtime (adapting a system yourself from UI elements), and will be much easier once they convert over the drag-and-drop system already in the UnityEditor to work in runtime so you don't have that extra work making it yourself. Animating UI elements is also very easy for simple translation (moving from A to B, swapping elements in a list, etc). Check out the graph view for Shader Graph, or Asset Graph, or any of Unity's graph-based systems and you'll find that dragging things around is very smooth and efficient. That's not structural, as said above. If you need structural changes "animated", use IMGUI instead IMHO, as it renders every frame and makes no assumptions you can do whatever you like with it. You can even make an IMGUI container as a UIElement, so that it's still slotted into the same system. Add an IMGUI container, animate it, do what you need to, then remove it, add in a new traditional UIElement to the list as it finishes (once it won't change anymore), and you're done. If you need sparklies and other "effects", use shaders, not the UI system itself, as that's what they're there for (custom shader support is being added to it now).