Official Unity Support on Native Platforms
JanOwiesniak opened this issue · 20 comments
Unity as a Library
Unity 2019.3 will add support for using Unity as a library controlled by native Android/Java and iOS/Objective C apps so you can easily insert AR and other Unity features.
https://blogs.unity3d.com/2019/06/17/add-features-powered-by-unity-to-native-mobile-apps/
Android Integration
https://forum.unity.com/threads/integration-unity-as-a-library-in-native-android-app.685240/
iOS Integration
https://forum.unity.com/threads/integration-unity-as-a-library-in-native-ios-app.685219/
Thoughts
Depending on the new official Unity as a Library feature could result in a more stable react-native-unity-view library and should be considered for version 2.x.x
Related Flutter Issue
Very interested in this, though i think the library has fallen out of maintainance from the original author. I would love to see if there are people interested in collaborating on support for this?
Also really interested in seeing this become the go-to way of integrating unity with react native applications. We're currently investigating a better way of doing UI work compared to doing it all in Unity for our applications, and using each tool for what they were designed to do (UI vs 3D) is the way forward for us.
@DanForstinger do you have any experience with this kind of integration? In any case if I look through their documentation, it should be doable to integrate unity as a library in a native iOS app (no experience with Android, I'm afraid) and then expose methods to RN components.
Yep I definitely think it's doable. We are probably going to look into getting the integration, but if the change is big enough we would probably abandon this project (seems like it's rather dead now anyways) in favour of our own integration, which we would probably open source.
yeah - lots of manual tweaks are necessary to get this one to actually build anyway, at least that was our experience 😬
In any case, you can contact me if you'd like to cooperate on an open source integration - we're almost sure to look into creating our own open source solution as well once dev time allows it. So perhaps it's beneficial to coordinate our efforts :)
@DanForstinger @ambewas If you guys have not noticed, the amount of PR for this projects has been 0 for a long time. You don't need to create something new. Create PRs for this project. I have been using this library for a year now, and it is working very well for my AR projects.
With only 4 PRs ever (and only 1 merged), along with the state of this project not working for 6 months on the current release of Unity (2019.1) for iOS at all, the amount of tweaks required to get this package working out of box (looking at common issues for workarounds was quite a pain), and the main/sole contributor @f111fei no longer maintaining it (at least from what I see from a quick glance) it may be best to just work off something new that is stable and adhere's to Unity's newly released guidelines (giving this project doesn't look to be maintained for the past 7 months, referring to not just code updates but issue management as well). Without the main contributor delegating or helping pinpoint the cause of these issues to provide a higher level of quality than what the Unity team provides, I just don't see this project sustaining with a new standard being released by the Unity team.
The only downside to working with the new Unity standard of Unity as a library appears to be the requirement of an alpha version of Unity. I plan on spending the next few days exploring and determining my groups course of action on whether we will want to attempt to make this project compatible with 2019.1+ OR working to make the new Unity standard for 2019.3 backwards compatible to 2019.1.
@zbagley correct - some tweaks necessary to make this work with unity 2019+.
However, it's not too terrible to be honest - albeit frustrating to figure out.
In my experience, the things below are definitely broken right now, and I'm fixing them after linking the library (for xCode anyway,.. haven't gotten around to the android part) ->
-
Make sure to merge
unityConfig.xcconfigwith any xcconfig files you're using. In our case (and for most people, probably) that was everything fromexpokit -
delete reference of: DynamicLibEngineAPI-functions.h && DynamicLibEngineAPI.mm from xcode project. For some reason, these break - and deleting the reference was the suggested resolution here
-
then in the library project itself, the header search paths need to be corrected, for React headers to be correctly resolved: add
$(SRCROOT)/../../../ios/Pods/Headers/Public(or whatever relative path to that folder you've got) to library header search paths - set it torecursive.
Anyway, as far as I've taken a look at UaaL I do believe adapting it for RN would be a complete overhaul of all the work done in this package. It would be nice to get it working, but since @f111fei is no longer actively maintaining - a fork would probably be able to iterate and evolve faster, no?
@ambewas For Android we also had to update our build.gradle as it missed packages. Another member on our team did the integration but also mentioned a couple other settings that were fairly straight forward to fix, but were Android compatibility bugs as well (sorry they didn't log, if I reimplement at some point will do and get them as issues here as needed).
cool - we're looking into an android build this week. Will also document any fixes we need to do.
@ambewas After nearly a full week of exploring AR using this library, and being unable to reach any level of compatibility for iOS, we're likely going to abandon exploring this repository (see #126 (comment) for details). The next step will be to explore UaaL for compatibility. If it appears stable, we'll attempt to implement into a basic RN project. Depending on how it goes we may create a public template for merging RN with UaaL, and I will likely post here as an update.
If anyone here ends up pursuing RN + UaaL and starts a repo to target this please feel free to post and keep me in the loop.
@zbagley that's great news! It will more likely stable and less hacky (in terms of compiling and build) because it would use generated library officially from Unity. I once would like to explore it too, but I don't really know much about either RN and Native. I'm interested how you'll create messaging bridge from RN to UaaL. Please nudge me when you started to create the public template
@ambewas Maybe it has to do with RN 0.60, or 2019.1.N 🤷♂ . I ended up including the library with more missing symbol problems, but didn't put much more time into it due to all the other overhead required prior.
Side note: I've built a project out with RN as an integration and Unity as a library, linking both from the root view and was able to get a project running in two days from scratch. This allows Unity to be run on the highest thread as UaaL is built for, while still allowing all UI besides Unity to be built out directly in React. I'll be focused on a different project this week, but will return to this next week and hopefully have at least the foundation of a template for both iOS and Android working with 2019.3.0a2+ and RN 0.60+.
"This allows Unity to be run on the highest thread as UaaL is built for" - @zbagley This sounds impressive!
How did you implement the communication bridge between React and Unity? Can you share boilerplate project? 😅
@zbagley that sounds really nice! Curious to see how you're handling the communication between unity and RN. Did you develop a similar <UnityView>? Is everything handled with the same kind of message communication you'd do when working with a web export of a unity project?
.. so many questions ;-). Would indeed be very interesting to see a working project or at least something resembling a template 😄
@alisherakb @ambewas
Currently I'm using Native to load in, and working directly with the RCBridge and Unity's Native Calls protocol. I have it set up to communicate only between button clicks (click to load RN as well), and plan on auto-loading RN as the primary view on both platforms for initialization. General idea is that the native code is acting as the RN/Unity bridge. Once I get a better foundation implemented, I will gladly share a GitHub repo template both here and on the Unity forum links above.
@alisherakb @ambewas
Currently I'm using Native to load in, and working directly with the RCBridge and Unity's Native Calls protocol. I have it set up to communicate only between button clicks (click to load RN as well), and plan on auto-loading RN as the primary view on both platforms for initialization. General idea is that the native code is acting as the RN/Unity bridge. Once I get a better foundation implemented, I will gladly share a GitHub repo template both here and on the Unity forum links above.
Any progress on that?
@alisherakb @ambewas I have minimal viable up and running for iOS. Minimal viable for Android is definitely on the plate for the near future as well, but iOS has temporary priority. Hoping to continue to expand on the base form, lifecycle management, subclassing, and general project structure down the line. Will likely also make branches to show examples for common packages. Feel free to watch/star/contribute https://github.com/CGS-Canada/react-native-unity
@zbagley I made a fork and I managed to connect Unity and Android with IL2CPP, armeabi-v7a, arm64-v8a, so it can be achieved. I haven’t done any communication yet. It was just for tests, so it is quite messy, yet it can be a starting point. In next month I will have more time for it.
Vuforia Engine v8.5.8 introduced experimental Unity as a Library (UaaL) support.
Unity introduced official support to include Unity as a library in native Android and iOS applications with Unity 2019.3. Experimental Support for this feature was added in Vuforia 8.5.