Unity for entire business app or just part of it?

We're currently in the process of deciding the tech-stack for our project and would love to get some pointers and suggestions from you guys.

It's a business oriented app with a twist. One of its main components/screens will feature a “mini game”-like function with some 2D-objects/animations that have physics applied to it. As far as we’ve seen, there is no other platform where you can easily create the same look and feel as you can in Unity.

Problem is that this is just 20% of the app. The rest of the app will be more business-/productivity oriented with functions such as direct messages to users, dashboards with custom graphs and statistics, modals with different fields, sliders, checkboxes, datepickers etc., leaderboards and more. These functions should have a more “native” feel to it and don’t look like they do in games. Examples attached in the bottom.

We’re aware that this is something that can be done in Unity, but is it a "good" idea? Especially if you consider the look and feel of the “business-/productivity” part of it and how it would work in the long run.

We’ve looked at perhaps using Flutter/React Native as a base and then embed the Unity/mini game part into it but haven’t really found any good examples of this? Are there any you know of?

Other things that might be good to know: App will talk to Firebase/NodeJS where the majority of data is handled/stored. Implementations to other 3rd-party APIs will also occur. Size of the app is not a concern. Rather complex logics will be done in the app. App needs to be responsive and don’t feel sluggish, heavy.

What is your take? Build the entire app in Unity or are there alternative solutions that would be feasible for a project like this?

Are there any good examples of business/productivity apps that in 2022-2023 use 100% Unity?

We’re aware that some of these questions has been answered in some older threads but perhaps something has changed in the last 3-4 years since those threads were created.

Thank you for reading

Kind regards

Some examples taken from the web of functions that might be in the app.

 

then use unity as library https://unity.com/features/unity-as-a-library for the "20%" part, and something more sensible for the rest

problem solved

That said you could build this relatively lightweight using UI toolkit and unity for 100% of it, and it could be just as good. Or you could forgo unity entierly, this stuff is perfectly possible with just react native etc.

Its really up to you how you approach this, and that should be based on the competencies of your team. Do they know unity and have used it professionally in past jobs? If not, then do not involve it as its a massive undertaking to learn an entire game engine on top of build an entire app.

Involving a game engine adds serious maintenance considerations going forwards, unity is absolutely going to cause you more trouble than its worth unless you have compentent unity-specific developers to handle that part of the app going forwards .

 

Thank you for your valuable feedback, really appreciate it.

We will hire a company to do the entire app and back-end for us, we just want to know our alternatives from people who have experience, without asking someone who has a "dog in the race", if you know what I mean It's easier to find a suitable company when knowing what tech-stack would be the most appropriate for a project like this.

Do you perhaps have any apps that you can think of that is similar to ours, that is made 100% in unity?

Thanks again

 

Well in the startup that I am the CTO at, our app is completely made in unity by a small team. But we have a clear use case for unity and strong competencies with unity. I dont want to post details here for privacy, so I will DM you the details

 

I would not recommend using Unity to make a mobile app where the user spends the majority of time interacting with app-like UI for a few reasons, most of which come from the fact your the entire app is just one large 3D viewport with zero native UI elements:

1. No native support for accessibility features. This includes matching the system's dark/light mode/theme, high contrast modes, modified text/UI sizes, screen reading, password managers.
   
2. No native direct text input. Whenever a user taps a text field Unity will open a popup where the user can edit/enter text instead of editing the text in place. This also means no selectable text either.
   
3. Increased battery drain. Everything is being redrawn all the time, unlike native and web apps which only redraw areas of the screen where something changes/moves (and even reduce the amount of drawing while scrolling by reusing visible image data).
   • Overall your app will be "heavier" than "normal" apps due to this and will run worse on lower end devices.

 

Do NOT use Unity to build a "business app" unless it is fully 3D. The sole reason being that it will drain the user's battery faster than they can scream "realtime". By default Unity will redraw the entire screen 60 frames per second whereas native UI libraries only redraw what has changed when it changes. While you can reduce the framerate of Unity, say to 30 fps or even lower, that will also affect how smoothly the user can interact.

The "Unity as a library" approach is viable but depending on the game AND the expertise of the developers I would be tempted to just use a simple 2D realtime rendering software, possibly native or Metal (with a common platform agnostic wrapper if necessary) or another simple 2D game engine like Cocos2D. The benefit of that being that embedding Unity will probably increase size of the app and memory usage more than more limited, focused library for 2D rendering, especially if it is a native framework.

And if the devs have no prior Unity experience, you will probably save time implementing the library the devs have experience with. If there is no realtime game rendering experience whatsoever on the team you should prototype two or more frameworks and pick the one that's giving you the least pain.

 

No, it isn't. While you can make UI application in unity, it was not made for this, plus you'll end up with a bigger more power-hungry application compared to what you can create using traditional means.

Haven't said that, you need to take a look at this:
https://docs.unity3d.com/Manual/UnityasaLibrary-Android.html

If you integrate unity as a library, this should allow you to use unity for that 2d comonent, and keep normal components for the rest of the app.

 

Pretty much agree with this. Personally, I found the performance and organization of a React app extremely good. I also feel the app I made in React could easily be handed off to a new team because it was organized so logically. I don't think the same is true for a Unity UI-heavy app, there just are not going to be as many people familiar with how to use UI Toolkit, which I agree would be the best fit for your designs.

I don't know of a 2D physics library that you could embed with React, but it seems likely something exists that could do the 20% game part.

 

Personally i'd be wary of relying on UItoolkit for this, every time I check on its progress there stll seem to be a wide range of show stopping bugs and lack of features. It was only last year that they extended the api to allow for the sort of line graphs and more fancy styles that the OP showed and in the main thread for it, there were a number of obvious bugs that users had found that would make me uneasy about using it ( no mention that the bugs have been fixed in the thread ). Further more AFIAK there is limited to zero support for animation beyond simple translation of elements.

I'd be happy to be proved wrong if anyone has any demo/sample or threads they can point to.

I need to do more research but at this point i'm still not convinced the UItoolkit is even a better choice over UGUI beyond the obvious ease of allowing designers to implement the UI with minimal coding. It might not even be much more efficient, even though it should be - again i'd be happy to be proved wrong, would love to see some good complex UI comparisons that show worthwhile gains either in performance or memory.

If it were me this would be another reason for embedding Unity and going with a native development system for the app using as you suggest something like react native.

While I do not disagree with your conclusion, I feel it should be pointed out that a few years ago Unity introduced 'OnDemandRendering' where input can be decoupled from rendering framerate. This means you can effectively drop rendering down to just a few fps, yet still get instant response to input. In reality you probably wouldn't drop the framerate that low, since you want the visual response to feel snappy to when a user does interact ( I need to do some proper testing to confirm this ), but it will greatly reduce the power usage and heat build up that running at 60 or 30 fps would cause.

On top of that I'd be tempted to run Unity with dynamic scaling and on high DPI displays keep it lower when interacting when it is likely less noticeable. I've done a few projects recently where I used a custom dynamic scaling system using built-in renderer and it made those projects feasible on both lower end devices and devices with 'insane' dpi.

For what you have described probably not.

Whilst 'embedding' the Unity portion into another app is not necessarily simple or advised, the design you present is likely the best case scenario for such an approach since its pretty much using a self-contained embedded Unity module, with little to no communication ( and no realtime communication ) between the app and Unity.

If on the other hand you were trying to drive the Unity module from the business app and wanting two way realtime communication I'd argue it would be a much harder decision, simply due to the complexity and upkeep overhead it adds. Frankly I find pushing new builds stressful enough as it is to the app stores, having to deal with two different development environments could be a nightmare.

So if you can keep the Unity portion self-contained with minimal communication with the business app then its probably worth a go, though I'd likely build in some redundancy and make sure the Unity module could be stripped out or disabled 'at will' should you run into show-stopping issues to releasing or updating the app.

Heck depending on the purpose I might even suggest a different approach and keep the business app to a native IDE and simply implement the 3D portion as webGL ( on a website, but not sure how well mobile support it ) or even as a separate app you can download. There should still be some capability for minimal non-realtime communication between the two, but you'd have to look into that.

 

I was under the impression that they'd addressed this, by adding support to separate input from the update loop?

That said, Unity-as-a-library is an even better way to support this kind of thing, as it addresses the other downsides which @CodeSmile has raised. There's another one, too: loading time for a game engine can be a bit long up front compared to other types of apps, as a broad generalisation.

 

We've done both for a existing app that wanted to add some AR experiences which used Unity as a library approach to launch the specific scenes. Done Unity only and added Unity to an existing app.

Doing it all in Unity requires less expertise I'd say, otherwise you need a native ios, native android, plus unity dev. But it's clunkier, and if you're using native device features you then need a plugin and things like interacting with the device's image gallery can be a pain in the butt. The Unity app is sandboxed where a native one can just do whatever it needs. There are native plugins on the asset store but it still has pain points.

Unity's build size is larger, example existing app had really high resolution images that were much smaller than comparable Unity textures.

 

Just wanted to add that there might be another way to accomplish this.

I was cleaning up the repositories on my system and came across Unity's UIWidgets repro. Its a weird one, that is not entirely clear in terms of its full capabilities or even usability, but apparently it has been the basis for the Unity Connect App ( never used it, not available in UK ) and uses Flutter. Except for basic 2D UIs, developers are also able to include 3D Models, audios, particle-systems to their UIWidgets Apps.

Whilst its unclear it almost feels like its Unity integrated with Flutter ( or vice-versa ), perhaps even acting like 'Unity as a Library', but with the benefit of being able to develop fully within Unity Editor.

However a word of caution, version 2.0 of UIWidgets can ONLY be used with specific versions of the China version of the editor. Version 1.0 can be used in non-specific versions of the editor, but may not be supported beyond 2019 LTS ( its unclear ). With the main change in version 2, being that all Flutter content is rendered natively into textures verses version 1 which uses Unity Graphic API's, so its more performant.

UIWidgets ( 1.0 )
UIWidgets ( 1.0 - 2.0 )

Sadly I don't know enough about Flutter to evaluate the package and I'm more than a little wary to rely on something so niche that its only developed and supported by Unity China. Though I guess being an open package, it has all the code necessary for a development company to maintain it in the future, except for the question of what is in the china version of the editor that is needed? Perhaps if one were to stick with version 1.0 it has less hooks required by the editor to work, I'm not sure.

Another concern, especially with version 2.0 is that the prebuilt native libraries for different platforms are pretty large ( requires git LFS ) with Android 80MB and iOS 250MB. If they have to be embedded 'as a whole' into an app then that is pushing the default size pretty large. Maybe install size with compression would be reasonable, but if the entire library is loaded in to ram that might be more problematic.

Its a really intriguing package and could make sense for a number of previous client job's I've worked on, but the lack of information and learning materials, along with the strange China Editor requirement ( does that support language packs to even use the editor? ), plus having to get up to speed with Flutter and maybe other API's makes the time investment necessary untenable for myself. Its a shame as it feels like it could be the ideal bridge for someone like the OP and other developers wanting more native integration with mobile devices.

It appears this package has been used to develop a version of the Unity docs here as some sort of javascript container app? Sadly it's Chinese only, switching language simply boots you to the html site.

If anyone has more knowledge or experience of this package, it would be interesting to get some feedback.

 

This is wild.

Looking at the source code this is an actual port of Flutter for Unity. The Flutter engine was brought over as a native C++ library with rendering routed through Unity via its native rendering plugin API, while the Flutter library was ported from Dart to C#.

This is a crazy amount of effort for something used by just two apps and has been getting regular commits, the last one being from last week. The project seems to be an initiative of Unity China.

It's amusing finding out there's a fourth Unity UI library that's hidden away in China likely due to corporate shenanigans.

Still, I would be very careful in basing an app around this. There's no guarantee of support and you'll need to be ready to muck around with its internals should an issue arise.

 

Agreed. I think this is the biggest sticking point, especially with version 2 being somewhat tightly integrated with the editor in some way that is unclear and undisclosed.

Its such a shame as I could see this being really useful to a subset of developers. If the whole codebase was open and if it had better visibility/marketing I would be interested in using it or at least testing it out. Tying it to a specific region version of Unity feels a bit weird too - wonder what that is about?

 

Could imagine that is part of some enterprise support project. The repo is set up by Unity, but possibly it was initiated by some Chinese company who does pay for that development.