* fix(apple): remove #ifdef checks in public headers
Fixes an issue where framework consumers would also have to set
WITH_RIVE_TEXT or WITH_RIVE_AUDIO
* refactor(apple): remove #if(def) from public interfaces and no-op instead
* fix(apple): fix incorrect api usage
Co-authored-by: David Skuza <david@rive.app>
Adds support for building all in _only_ debug mode, _only_ release mode, or all (both debug + release).
Additionally updates the release script to build _only_ release libs, which should speed up overall release times.
The iOS runtime expects release builds of the c++ runtime, so by utilizing `build.sh all release` we can shrink build times, both locally and for releases.
Here are some rough timings. The times are an average of three runs:
- `build.sh all debug`: 6m15s
- `build.sh all release` 5m38s
- `build.sh all`: 11m54s
This shaves off almost 50% of the build time (which makes sense, since we're cutting out half of the builds).
Diffs=
820f8fe027 build(ios): support building all runtimes by debug or release (#8966)
Co-authored-by: David Skuza <david@rive.app>
Updates `build_framework.sh` to use the `-archive` flag to include `dSYMs` to the final `.xcframework` output. This should make it easier for developers to symbolicate crash reports and give us more insight into Rive-related crashes.
This does _not_ affect device support, and does _not_ affect install size; it only affects download size.
Diffs=
2e45b9682d build(ios): updates build_framework script to include dsyms in final output (#8941)
Co-authored-by: David Skuza <david@rive.app>
This pull request adds support for both visionOS and tvOS to the Apple (colloquially referred to as iOS) runtime.
It should _not_ be a breaking change, since the only major API change is an internal one (see `RenderContext` below). I believe we should be able to make this a minor release. Developers who have subclassed `RiveView` or `RiveRendererView` should not see any changes, unless they were explicitly expecting this view to be `MTKView`, which is fully unavailable on visionOS (hence our recreation - see `RiveMTKView` below.
## Premake Scripts
The premake scripts were updated to add a few new variants for iOS:
- xros (visionOS devices; named after the internal sdk)
- xrsimulator (visionOS simulator; named after the internal sdk)
- appletvos (tvOS devices; named after the internal sdk)
- appletvsimulator (tvOS simulators; named after the internal sdk)
The majority of the work here is copy/pasting existing code, and just adding additional filters when these new options are used, primarily used to target the new SDKs / minimums for those SDKs.
## Shaders
Shaders are pre-compiled for visionOS and tvOS separately, and the correct shaders are then used later-on at compile time.
## Build scripts
Build scripts were updated to support building the new libraries, targeting the new devices, using the new options above. Additionally, they have to point to new output files.
The `build_framework` script has been updated to build the new libraries to add to the final output `xcframework`.
## Project
Example targets for both visionOS and tvOS, since these truly are the "native" apps, rather than just iPad-on-your-device. These use a new `streaming` riv by the creative team.
The tvOS example app adds additional support for remote control, since that behavior can be utilized in multiple ways during development; that is, we don't add any "default" behavior for remote controls. The visionOS app, on the other hand, works out-of-the-box with no additional changes.
## RenderContext
`RenderContext` is an internal type; it's forward-declared, so it's unusable outside of the scope of internal development. There have been some "breaking" changes here - the API has been updated to, instead of passing in `MTKView` around, using `id<RiveMetalDrawableView>`. This had to be changed, regardless, since visionOS does not have `MTKView`. The choice to use a protocol was because it forces a little more explicit initialization across platforms, rather than having a parent class that acts as an abstract class, but isn't abstract because it still needs some default values, but those values are different based on device and API availability, etc. We could've passed around `RiveMTKView` as the type, but with a protocol, there's a possibility of being able to use a type that isn't exactly a view, but might want to still act against the drawing process. Personal choice, really.
## RiveRendererView
`RiveRendererView` is now a subclass of `RiveMTKView`. `RiveMTKView`'s superclass depends on the device:
- On visionOS, this is a `UIView` with an underlying `CAMetalLayer`
- On all other platforms, `MTKView`
This new class conforms to `RiveMetalDrawableView`, which allows it to be passed to `RenderContext` types.
### RiveMTKView (visionOS)
`RiveMTKView` on visionOS is a subclass of `UIView` that is backed by a `CAMetalLayer`, providing the necessary properties of `RiveMetalDrawableView` (compile-time safety here, baby). This is quite a simple recreation of the default `MTKView`, since that type is not available on visionOS (thanks, Apple).
## Other things
Additional compile-time checks for platform OS have been added to make sure each new platform compiles with the correct APIs that can be shared, or otherwise newly implemented.
Diffs=
6f70a0e803 Add visionOS and tvOS support to Apple runtime (#8107)
Co-authored-by: David Skuza <david@rive.app>
Re-add these build scripts as they were causing some tests to error out.
Diffs=
c3f96b62a Re-add skia iOS build scripts (#8056)
Co-authored-by: David Skuza <david@rive.app>
See title. Additionally, this removes the skia build scripts and updates the major version dependency rule to v6.0.0 in the Preview app.
Diffs=
8773f56fc Update iOS contributing guide (#8018)
Co-authored-by: David Skuza <david@rive.app>
This is part 1 of the update to switch downstream rive-android to use submodule rive-runtime instead of rive-cpp
After this is merged, another PR in the downstream repo must be made to change the .gitmodules and also move submodules/rive-cpp to submodule/rive-runtime
Diffs=
345e07ecf Runtime ios switch to rive-runtime from rive-cpp (#8024)
Co-authored-by: rivessamr <suki@rive.app>
submodules should still be referenced with rive-cpp
Diffs=
455ebad60 Update rive cpp for submodules (#7932)
75e0f9aea runtime: support files with n-slicing defined (#7920)
85b28c39a Update readme of PLS (#7931)
21ecf2775 Fix actions yaml with rive-renderer (#7930)
c33d5d81b Update rive renderer readme (#7929)
b03895fcf Update pls README (#7927)
3316d15ca Refactor pls into runtime (#7914)
Co-authored-by: rivessamr <suki@rive.app>
Support for SIMD instructions for unpremult
First checkin, using rive::int16x4 instructions : 1 pixel at a time
Further checkin, using rive::int16x4 instructions : 2 pixels at a time
Last checkin, avoid computation when opaque pixels (assume there will be enough opaque pixels to warrant this)
Thanks to Chris for the SIMD instructions usage in rive
More checkins: move the decode and unpremult to the rive decoder - this requires modifications to build files. The benefits are we are now running tests on this path. However, there are some issues with decoding two images for tests:
"../../test/assets/bad.jpg" ... Apple Preview app cannot open this image, however, the current test says that it should be not null
And
"../../test/assets/bad.png", Apple Preview app can load this images, however, the current test says that it should be null
Diffs=
e992059d6 iOS images unpremult SIMD support (#7875)
Co-authored-by: rivessamr <suki@rive.app>
The Rive renderer is stable and ready for production now. This cuts the runtime size from 7.1 MB to 2.3.
Diffs=
32f7a05eb Remove Skia from iOS runtime (#6072)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Follow up to #7048!
I nuked the custom defines and the miniaudio include. I think this fixes the need for miniaudio and the custom defines @mjtalbot! Give it a shot 🔫
Diffs=
89053041a add out of band audio support ios - abstracted audio! (#7079)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
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>
Remove a couple assertions that will never be 100% gone with floating point precision. The code that handles when these conditions are true is sound.
Don't link the release librive_pls_renderer.a into debug builds. Many classes have debug-only fields, so the debug and release binares are not compatible. Instead, strip the debug build.
Diffs=
2c2ea4492 Rive Renderer fixes on iOS/debug (#5995)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Our actual framework targets 14, so this won't have any effect on clients.
This also allows us to quit targeting armv7.
And cut out arm64e as well. Let's keep our release lean.
Diffs=
05e1afaf3 Bump the iOS minimum version to 13 on native builds (#5989)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
* Build fat libraries
* Configure the bots to install python PLY
* Fix a cp command in the macosx build
* Only publish release builds of PLS
Diffs=
e53ea111b Fix the iOS release (#5967)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Adding rive text support to ios.
@mjtalbot Sorry for the shell script format churn, this is my formatter in case we want to standardize on one:
https://github.com/foxundermoon/vs-shell-format
```
"[shellscript]": {
"editor.defaultFormatter": "foxundermoon.shell-format"
},
```
Also, I couldn't test the MacOSX build thoroughly as I was getting a Metal error on run which wasn't related to the text changes. But maybe I'm running the wrong project (this is the iOS one which I thought we were sharing)? Not sure which one I should run for Mac. This is the error:
<img width="847" alt="CleanShot 2023-07-20 at 16 29 56@2x" src="https://github.com/rive-app/rive/assets/454182/6c2f70f9-c8f4-4b50-a3cb-753a861e2e0b">
Diffs=
13863bf8f Rive Text for iOS and Android! (#5634)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
draft because i need to get a todo list together.
Adds macos as a target for our ios runtime! Also adds a macos target for our example (which is a different app completely, very minimalistic right now).
<img width="331" alt="CleanShot 2023-05-17 at 20 32 45@2x" src="https://github.com/rive-app/rive/assets/1216025/7a6cadce-9763-41a3-b1a0-6d067dfc3eca">
macos, macos rosetta, macos (designed for ipad), and ios all co existing in peace, from the same runtime project
todo:
- [x] update build scripts to build supporting macos (gotta do this)
- [x] run formatter
- [x] test out builds in forked version of ios? (gotta do this)
- [ ] one more stab at catalyst? (i think we can try that later...)
- [ ] do we need a more comprehensive example setup for macos (I think we can do this later & try to pull zach's examples in)
- [ ] I think we should restructure the ios project, but i think we can do that after this as well (i just think the folder structure/project structure can do with some work, now that we add macos (and should make room for tvos as well)
- [x] probably got tests to fix
- [ ] there's probably a bunch of looking at errors in the debugger and figuring those out, but i would hope that we can deploy with some warnings here too.
catalyst problem:
we get this error:
and the problem is basically that we can target a specific library for macos, but we need one for macos and one for macos catalyst. they share the same architecture, so i dont think we can lipo them into one file...
we could change the compiled binaries before creating the frameworks I guess though? .. maybe something to try..
`/Users/maxwelltalbot/development/rive/rive/packages/runtime_ios/dependencies/debug/librive_skia_renderer_macos.a(cg_factory.o), building for Mac Catalyst, but linking in object file built for macOS, file '/Users/maxwelltalbot/development/rive/rive/packages/runtime_ios/dependencies/debug/librive_skia_renderer_macos.a' for architecture arm64` basically
Diffs=
a9f8a1c5d Macos take2 (#5258)
…rent play animation
fixes https://github.com/rive-app/rive/issues/4021
I think this addresses all issues as described, ping pong is a "little" weird, as positive playback speed will always send the animation forward (even after its ponged) in any case I don't think it really matters, this feels much better for one shot animations.
would love to get this into UAT to get confirmation on this being the right UX
in terms of where we are doing this & how we are doing this, @luigi-rosso is this a good place for it?
Diffs=
1c702838f update editor playback actions when timeline is at the end of the cur… (#5028)
… out where rive-cpp is
precursor to fixing up building recorder for rive-api.
Diffs=
f39fd75e1 use build relative folder location as opposed to git remote to figure out where rive-cpp is
Large files have problems with the text selection, so i've added a download button to just download thejson text
also added a push events viewer here, as i think people have been wondering if events made it or not... (it is all push events mind you, not just the ones for the editor... this still seemed like an acceptable place though for debugging...)
can definitely work on the data that gets displayed, but also think its probably worth seeing if this is useful in this form. so i'd rather get it in and improve if used.
Diffs=
575787669 Add event cache to see websocket messages for debugging & add a download button to the json view
… downstream
just tagging you all for visibility will pepper a few comments in here and hit merge....
Diffs=
90e1d4cf7 renamed release script to releaase & removed unused scripts
418044ebf updates to renderer build defines
a1af986be adding all the updates to make ios build from the mono repo, and push downstream
