few bits to sort out
- [x] make our mix of simulator/emulator consistent, settling on emulator
- [x] passing the factory in works great for just in time asset decoding, but its not amazing when you want to decode ahead of time.
- [x] couple of places left to pass this function signature through. (Question) is there a neater way to get this done, feels a bit like we are going back to parameter explosion a bit?
- [x] should do a few examples, i think the complexity grows quite a bit in this one as you add caching, or callbacks
- [x] should get the cached images/fonts to draw on init as well, either warming up cache, or jitting
- [x] examples loading assets from the bundle (also there seem to be actual asset things too? should we use those?!)
- [x] add test
- [x] re-add "preview" project & rev the preview project once this has been deployed. (do this after new ios deploy)
- [x] fix up race condition (see comment)
https://github.com/rive-app/rive/assets/1216025/2c14330f-e8a4-481b-bc27-4807cabe3b82
(simple example, both swift ui and standard)
Diffs=
fabb7f97f Ios out of band (#6232)
Co-authored-by: Gordon Hayes <pggordonhayes@gmail.com>
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
This is similar to the Android PR that added build variants to make it easier to build the example apps, see: https://github.com/rive-app/rive/pull/6088
With this PR we're now making use of additional targets that shares code with the parent examples (iOS and macOS respectively). Then there are two new schemes that you can select when playing `preview` and `preview (macOS)`, which will use the above mentioned targets that uses the hosted Rive dependency instead of the local one.
This works well, but is not as smooth of an implementation as Android, where it was simply switching out a build flag. With this implementation we'll also need to semi-manually bump the hosted version - see the additional docs in `CONTRIBUTING`.
There might be a way that we could make this smoother. It'll only be a headache for examples that make use of new features. Where after we release, we'd then need to do another PR that updates the minimum version for the `preview` targets. We could likely look into automating this by scripting the change in the Xcode config.
Diffs=
d78a6561a feat: add preview target to ios and macos runtime example (#6096)
Co-authored-by: Gordon <pggordonhayes@gmail.com>
