RiveView/RiveViewModel API is very unusual

[DagAgren]

Description

The RiveView / RiveViewModel API is very strange and goes against a lot of expectations of a view-based API.

1. Exposing a view model from a library like this feel very odd. I would expect a view model to be an internal implementation detail, and not exposed to users of the library.
2. If we do have an exposed view model, I would expect the view to own the view model and not the other way around. I would expect to set a view model property on the view, not the other way around.
3. The view model reference in RiveView is both weak and implicitly unwrapped, which means that the code that owns the view also has to keep track of the view model, otherwise it will be deallocated and the code will crash. This introduces an extra burden which seems entirely unnecessary.

[mjtalbot]

Hi @DagAgren thank you for raising this, and it sounds like we may have picked up the wrong end of the stick when adding swiftUI support to rive-ios.

I think one problem we tried to solve was letting users interact with the riveView properly, and for that we felt we needed to have the ViewModel for users to control what the riveAnimation is doing. This would let you do things like trigger play, or change state machine inputs. Looking at this right now I'm not sure we have a concrete example that really highlights this as a problem however, and I don't completely see why we should not simply be able to do that by interacting with the View directly.

Looking at some of the supplied examples:

• I suppose when using the view directly this examples onTapGesture could simply act on the view directly as opposed to the viewModel.
• I can't see our layout example running into any control issues
• We have some more complex examples that might show issues. Looking at how we build up a couple of viewmodels here to modify them from other views (the progress bar/slider/switch examples). But again It does look like we should be able to trigger those events on views directly.

Do you have an open source library in mind that lines up with your expectations a little bit better? I think we need to study this a little bit and come up with a structure that meets the expectations of the community.

I guess with any changes we should also take some minimum deployment target issues seriously and see we can make any change compatible with lower versions of iOS