"Lite" project template for simple client apps

Hello everyone! I'm a Unity AR\VR developer with a small background in mobile games. And recently, I realized that my life requires a bit of organization. I came to the conclusion that some reminder-app with a flexible reminding rules system could significantly help me with my daily routine. I started poking around Play market for the desired app. And after several days of searching and browsing through the top~50 app, I realized that there is no app that would match my requests. I started to think about creating my own app because I'm a developer and my mission is to simplify people's lives! So as always, the first step was to find the best instrument for developing the app everybody needs (however doesn't know about it). Of course, I understood that the more people I make happy the better, so no need to waste my powers on developing a single-platform native app. After a week of analyzing, I saw that the main candidates were Xamarin, Flutter and React Native.
After several hours of Xamarin Sdk installing and trying to run it on Rider, I ended up running it on VS. Other several hours I wasted on searching manuals on how to make a bottom navigation bar. I found out that the only solution that should work was compatible only with Xamarin Forms v3 and I had Xamarin Forms v4 installed. Okay, I removed v4 and installed v3. But it was not enough, probably manual I found was obsolete or something was changed in the lib I had, but I couldn't use it. I spent almost a whole day on a simple bottom navigation bar and failed. I didn't want to spend more time learning frameworks instead of helping people. So I understood that Xamarin is garbage on my PC which need to be removed.
With this knowledge, I started to look at React Native. And saw that I had to learn the whole front-end stack before starting to make my app there. Sounds interesting and challenging, but I have other work to do, so good luck React Native...
And hi Flutter! Flutter looked like it was exactly what I was looking for. Google said that they made this SDK specifically with the idea of fast development in mind. It was cross-platform and had Hot-reload feature which looked like magic to me. And the most interesting feature was the widgets concept. I could write a good looking and animated app with only some strange nesting-hell code. Then somewhere in the description, I found that it uses its own graphic engine under the hood. And I asked myself "Why do I have to learn a new engine if I already know another one? And it's a good one!".
First thing first, I checked this forum on related topics. Sadly to say, but nobody recommends Unity for client app development. The main argument there is "Unity is a game engine, it's too heavy". I don't believe in this, I think it's only a matter of making Unity a bit more modular. As to me, it's already pretty good for the described purpose. Since I think that Flutter is the main competitor in this field, I'll compare my choice with it:

• Google says Flutter is easy to use due to the widgets system. But Unity is even easier because it has its own GUI system based on canvases, where users can create interfaces with drag and drop and have results immediately. Moreover, with Animator (or with DOTween to have more lightweight solution) users can easily create custom animations in several clicks. And using Bolt or Playmaker users can even avoid coding at all.
• Google says Flutter is cross-platform and Unity is as well. In fact, Unity supports many more platforms than Flutter! And due to its big community and maturity, Unity has plugins to solve pretty much any platform trouble you could face while developing your app. For now, Flutter can't offer this.
• Google says Flutter has great performance. Even without extra optimizations, 2D app made with Unity wouldn't irritate users with its low performance. If the programmer takes care of draw calls and uses asset packing and orders objects in the hierarchy for UI-rendering, his app will work like a charm and none of users will say that the app freezes or something. But that's not all, recently Unity introduced OnDemandRendering. I think this stuff potentially can significantly improve battery time, so Unity app could beat Flutter here too (I haven't tested it yet).
• Google says Flutter has Hot-reload. I tested an empty Unity app with Pro license and disabled splash screen on Android. The app launched literally instantly. It was pretty close to native apps. With disabled stripping, build and deploy time was 20-35 seconds. It was already running on my phone! Along with having the opportunity to run the app in editor (and short start time with Enter Play Mode Options), Unity is close or even better than Flutter is in this too.

Long story short, Google has made its engine for running simple apps. I don't understand why Unity hadn't done this yet. They already have everything any developer could desire: a simple instrument for developing, good programing language, a great and friendly community, many plugins, integration with all major instruments, and countless ways to extend the app and Editor. Don't forget about Assets Store! Just cut out heavy rendering and physics, and push it as a separate "Lite" template-type for mobile projects. I'm sure after that Xamarine will be abandoned in several years and many developers from other mobile frameworks will join our big team. And yeah, since Unity supports desktop platforms, this template could be cross-platform "Windows Forms" after polishing GUI system (layout system is still a pain there).

What do you think guys?

 

I'm using Unity for an app on tablets and it works perfectly fine as-is.

 

In the past when Unity was all I knew I liked to see this as well. It's not as simple however because the entire ecosystem of the engine is built around the idea of rendering 3D graphics and if I'm correct the 2D part of it still uses same pipeline but with orthographic camera projection. There's nothing stopping you from making an app with Unity however, the question only is how beneficial is it to the people who are going to use your app? It'll drain their battery quick and their device gets hot just because you tried to take a 'shortcut' on the development.

 

In fact, this is a very interesting thing to think about. unity has everything you need to create a fast and modern software / app.

Definitely, they should invest in it...

Many of the arguments are based on physics, and the constant updating that unity does in its interface / rendering.

This is what causes excessive battery consumption in mobile devices, but, to some extent, this is not so great if you configure the editor correctly.
By experience, we can modify the number of times the editor makes an update to the physics, we can also define the maximum refresh rate on the screen (24 fps for example for mobile devices would be enough)
Not to mention that we would not actually be creating a game, so there is no high consumption of storage / ram
Of course it would be much better if unity adopted this, but with what we have now, it is enough ...
(And as we are talking about applications, users do not want to know what tool you created the application with, they just want the application to work and be useful for them, this is what makes the difference) So go ahead

 

I think that all apps do that because there are no special GPU commands for rendering GUI on any platform I know.

That's one of the things I worry about. And even though my phone doesn't get hot and the app works smooth, I'm still not sure that this app is not hungry for users' batteries. I haven't tested it yet either, but thinking logically, I wonder why should it be? The engine has a game loop with a fixed frame rate in it, similar to what a native app has. I don't know how Unity implemented rendering in the engine, but I tend to the idea that it shouldn't take much more than a native app...

 

Thanks, stuksgens! I'm 100% agree with you. Just still don't understand why Unity is not as popular among mobile-app devs as it is among game devs? Looks like it's a much better choice than any other solution I noted above. I can understand why people use React Native if they have a web stack already learnt. But why to use Xamarin, making different UI for each platform, if you're familiar with c#?

 

Maybe you could advise me more points for optimizing the app specifically for this usage? stuksgens mentioned one that I missed:

 

Where in your code are you making updates to physics?

 

I newer use physics in my code, so I can easily disable physics engine update with:

Code (CSharp):

1. Physics.autoSimulation = false;

or make it as rare as possible configuring update time in the editor.
That's the trick

 

Another way is by not using (or using as little as possible) the Update function

It would be good to make a list of things that can improve battery consumption and keep the app stable ...

 

It's still much higher resource usage than a native or dedicated app GUI framework, while reducing responsiveness and smoothness when things do happen.

That said, I believe that in the past year or so Unity added the ability to control input and camera rendering separately. So rather than turning the update rate down I would turn it off and go completely event-driven with my code, subverting much of what you get out of using Unity in the first place.

In other words, I'd end up making my own application framework on top of Unity. So I'd think very hard about whether that was worth it, or if I should just use an existing one which other people with more practice have already been working on for years. Note that I'm not saying it'll never be worth it, and Unity have made some great improvements towards these use cases over the past couple of years. However, most of the time I hear people talking about doing this the main reason comes down to not wanting to learn another tool.

Other stuff to keep in mind is a lack of native or complex GUI controls, differences in content pipelines, and missing out on specialised text renderers.

Because once they've learned those purpose-built tools they're better for the job, because it's what they're designed for. Learning those tools is likely to take longer than the "several hours" or "almost a whold day" you say you gave it, though. I suspect that you spent longer than that learning Unity when you first started using it. Other tools are going to require a similar time investment.

That said, I do sympathise with anyone learning to wrangle other peoples' software libraries for the first time. It's complex and frustrating.

 

On this specifically, game engine rendering and native app rendering are often fundamentally different.

You're right that these days they're both hardware accelerated and likely use the same graphics APIs on modern hardware. However, the approaches and algorithms for the rendering are designed and optimised for different use cases. Following is a highly simplified explanation.

A game engine is designed around the use case of updating fully dynamic scenes constantly and as quickly as possible. Their algorithms and optimisations are designed with the assumption that it makes sense to just re-draw everything each frame. That makes sense, because it'd be incredibly complex (and expensive) to narrow down what changed and focus just on that, and many potential "small" changes would require the whole screen to redraw anyway. Eg: changing one number in your camera? Everything's gotta go.

A windowing toolkit is a completely different beast. Even though these are rendered using the same APIs under the hood, generally speaking they can easily have a pretty good idea of exactly what areas have changed. Each window or "widget" can draw to a buffer, and that buffer only needs updating if an event has caused that widget to change. Those changes come from a very well defined set of potential events, so they're really easy to track. The system can easily update just the relevant buffers, and just when there's an event which has invalidated them, and sit there doing nothing the rest of the time.

 

After spending several days trying to write my notes app with unity, I abandoned this idea and now I'm learning flutter. The reason why I did this is pretty silly - unity does not support native input fields. The build-in text input field behaves similarly to what I needed, however, it doesn't support text selection and copy\paste. And besides that, it has problems with text rendering (it's blurred sometimes). I thought TextMeshPro could solve my problems, but it can't. In fact, it works even more lame than the usual input field. It is not compatible with unity's layout system and if you use a single line input field, after finishing typing, it shows you the last text you entered instead of jumping to the beginning. And you can't easily solve these problems. And yeah, it does not support native copy\paste too. There are 2 plugins declaring that they solve this problem. And one of them doesn't work at all, even the example apk provided with the plugin is full of bugs. And another plugin works better, but the input field you get is completely uncustomizable (you can't even hide the white background image). So if you're like me thinking that use unity to write an app is a good idea, then I'm happy to inform you - it's a bad idea =) and it would be better for you to spend your time on something more useful.

 

I have used Unity to make some non-game apps. But if your app does not require any 3D rendering capabilities, you should not even put Unity on the table. Natives apps are more efficient (only renders on-demand, completely idle when doing no work), are right next to platform APIs and generally have much smaller binary size. This is also why Unity has decided to make its iOS and Android build available to integrate as a framework into other native apps -- SceneKit is not popular and Android does not even have an official 3D content composer.

 

I'm still going to try to make a list of what we can do to improve the performance of non-game apps.
It will never be as good as React or native Libraries, but unity can do better than they do in other areas.