Non-game mobile app: Use Unity, or learn something new?

So, I’d consider myself a fairly experienced Unity developer. I’ve been using Unity professionally as my day job for almost 2 years now. I can make stuff in Unity very quickly because I know it so well.

Recently, I’ve been thinking about a mobile app I want to create, but it’s not a game. Really, it would just be UI elements - mostly text and maybe a few icons. And now I need to decide if I should use Unity to make it or something else.

I already have and know Unity, and I also have an NGUI license to help handle all the UI that would be necessary. I also don’t have any experience with other cross-platform frameworks (w/ the exception of Appcelerator, I did mess around with that very briefly a few years ago), so doing this in any other framework would require some learning curve. All that makes me lean toward trying to do the app in Unity.

But I also know that building w/ Unity would incur significant overhead loading the 3D engine, so the app load time and file size wouldn’t be ideal. Not a huge deal, but I’d also have to display the Unity splash screen (I don’t have a pro license).

So, I wanted to get some opinions from others. Would you recommend building a non-game, non-3D app in Unity? Or would you recommend learning some other cross-platform framework?

Note that I’m only interested in cross-platform solutions. Although I know Java and the Android SDK, I have zero interest in learning Objective C for iOS. I’m looking for something where I maintain a single code base. I’m also only interested in free or almost free solutions.

Thanks in advance for your input!

I have some experience in making non-game apps with Unity and it’s quite good. Might be tricky if you want to use built-in Unity GUI.

Well, like I said, I have an NGUI license and fully intend to use it if I go the Unity route.

I wouldn’t even attempt a UI-heavy app w/ the current built-in Unity GUI. :slight_smile:

I’ve used unity for a few non game related classes at university. Generally i’ve found it’s easier to work with the devil you know than try and learn something new - at least in terms of speed.

Unity being cross platform makes it incredibly easy to test the basic functionality of your app without ever actually having to have it loaded on whatever specific device you have in mind.

For example; one project I did previously involved designing a basic tourist information type touch system for the commonwealth games - like the type they use for ATM’s and stuff. Most of my class chose to make it in flash, however I did it in unity and had it loaded up onto my iPad as a mock up.

Not necessarily any easier, but I could throw myself in the deep end quicker and can reuse the work I did in other projects I do in the future, rather than having a project saved as something i’ll never open.

Not sure if this is any help or not… but at least its another +1 for non-game applications! haha.

Good point. If I do it in Unity it’s just further building my library of code that I can potentially reuse in the future for games too.

Also, it occurred to me that, since Unity’s 2D engine will be released soon, in theory it should be able to produce more highly optimized builds that are smaller and load faster since it doesn’t have to do all that stuff in 3D. So maybe this problem mostly goes away when Unity 4.3 is released…

Leaning even more towards staying with Unity… :slight_smile:

At least wait til the 2D that Unity is adding to 4.3. You can think of the 2D rollout as a stability test as it must play a large role in the new Unity GUI under development.

There are pretty significant issues with using a game engine for standard GUI apps, I wouldn’t recommend it. For starters there’s battery usage - the core of a game engine runs all the time rather than being event driven, which means that it’s eating more CPU/GPU than a normal GUI app even when nothing is happening.

Will you have intense UI’s? That’s what slows down my development, cause it’s not the ideal tool for the job. And, still, my non-game Unity apps are doing quite well, and as I’ve already released 5 of them … I’d say go for it.

TL;DR: It depends.

Gigi

Good point. Do you have any recommendations for a cross-platform framework for developing standard GUI apps?

No, nothing too too fancy. Well, too fancy to easily do in stock Unity GUI, but stuff I’ve done in NGUI a dozen times before.

Would you mind sharing a link with one of your non-game Unity apps? I’m curious to check out what you’ve done and how it’s performance/load time/etc is.

We’ve a small amount of experience at work using Apache Cordova based applications, which use HTML and CSS for the UI and the platform’s existing browser functionality (via a wrapper) for rendering and so on.

It works pretty well, there are some fantastic tools out there, it’s efficient on the device because web browsing is something they all do (reasonably) well, and write once deploy many works about as well as it does with Unity (which is to say that platform specific code is only needed where platforms actually do different things). The downside is that smoothness of animations and responsiveness is highly dependent on the platform’s and device’s JavaScript engine and its performance, so consistency of user experience in that regard varies.

Yea, for mainly GUI apps (and many non-game apps), HTML/CSS/JS is a great solution (plus a breeze to develop in). We have a… uh… ah… a fantastic HTML5 game engine that works great for apps and 2D games (to a degree). I love using HTML whenever appropriate, its a comfortable happy place.

Hello Im Faizal
im sorry to interrupted…but can i know if i can use Unity for developing a mobile apps like Indoor Positioning System?

at this time of writing Unity 4.6 is out already with its mighty UI features. As far as i know, uGUI is event driven. So my ques is

  1. Is it appropriate now to use unity to build non-game app?
  2. Suppose i want an application that uses calender/alarm; how will I implement this in unity?

Holy crap, double necro.

I cannot see any good reason to choose Unity or any other complete game engine tool solution for mobile app development.

Mobile apps and games have completely different requirements.

The reason that “Unity its easy because I’m already used too” is not a real world reason, is just an excuse for lazyness of not learn something new. Cross-platform deployment could be seen as a valid reason if there wasn’t any other cross-platform native solution out there.

As a game engine Unity packs all the tools needed for 3D intensive games, like a sophysticaded real-time rendering system, real-time physics engine, audio engine, animation engine, etc. All of this is always running in a loop for real-time updates and real-time response, consuming alot of resources to have the task of running a game in real-time done. Game engine like Unity, Unreal Engine, CryEngine, and so many others exist to face the demanding game requirements.

So, using a wrong tool for the job usually have so many down-sides. In case of Unity for mobile app, will probably be file size several times bigger than necessary, loading times several times slower than necessary, lack of user interface design consistence, big challenges into accessing to mobile specific API’s (what if you need to access user contact list, setting alarms, etc), battery wasting, bad use of resources, and much more. All of this will be felt by the end user.

Using Unity just because its the only thing you know or that you are experience with its the wrong way to go. If all the devs thought that way and most of the mobile apps where developed and publish in Unity our any other game engine, our smartphones won’t last more than 1 hour.

Hey! Lets ask Google to develop the Android default apps like Gmail in Unity :stuck_out_tongue:

For me considering Unity for mobile app development is almost the same to consider Unity for everthing else that is non-game related, like Web Development (hey! we have the unity web player so why not?) or Windows and Mac OSX development (when you run Unity a window is opened on the Desktop so why not?).

Saying this, native Android/iOS is the way to go for good mobile app development. If Cross-Platform is a must, you have excellent native cross-platform like Xamarin (written in C# by the way), that are as good for mobile app development as Unity is good for game development.

If you are a game developer and you choose Unity or any other good game engine it can be considered a good and perfactly right choice, and we had to learn it some how. So if you also want to be a mobile app developer, you have the chance to learn something new here. In this case, to learn the right way to develop a mobile app as you once did for game dev.

My final advice is…use your mobile app as a “excuse” to learn something new…don’t the opposite.

3 Likes

Don’t be so quick to assume laziness. There are people with jobs keeping them busy during the day and kids keeping them busy on nights and weekends. Maybe all they want to do is build an app as quickly as possible to get a little extra income. To them, time is a rare and valuable commodity and time investments will rightfully affect their choices.

I would say those people (and I am one of them) are far from lazy.

1 Like

Sorry! I didn’t want to judge people character. It was just a way of saying.

My point is if you don’t have time to learn and explore how to develop mobile apps in the right way, why you wanna do it anyway? If you have experience with a game-engine like Unity and game development in general, then you sould look for that extra income in a context of a game project that you actually could develop with your experience.

You will not do a good service for mobile users by using Unity3D on a regular non-gaming mobile app. Like I said before, imagine if everyone start doing mobile apps with Unity…our smartphones won’t last 30 minutes alive.

Anyway, this a very typical question that arises for game developers without any experience in native mobile development. Suddenly they want to do a non-game mobile app for some whatever reason and of course…why do not do it the same way you do a game? For me that’s very wrong…

If it’s for personal use or for friend only I don’t see a problem but since you mentioned monetizing, it pretty much is laziness. No matter what your excuse or how little time you have available, in the end it means you make a product by disregarding common guidelines and good practices just for a quick and easy cash and the end user pays the price. Bolded description fits all kinds of industries where people do stuff half-assed job just for the quick bucks.

Might I suggest that people get off their high and fucking mighty horses?

Attacking someones character or motives based on your gut feeling and massive experience of living in that persons shoes is not productive, nor is it relevant to the topic.

Now, the performance issues mentioned are quite real. Aside from those bits of the engine not stripped at build time, costing build size, startup time, and slight memory and runtime CPU overhead, game engines are built radically different than UI applications.

Commonly, UI applications sleep a lot - waiting for system events to trigger - whereas game engines just run full speed ahead, which does end up costing more processing-wise and thus battery-wise. Now you have some tools at your disposal to reduce this cost - specifically you can set Application.targetFramerate.

By default, targetFramerate is set to -1. Setting it to a value larger than zero will have Unity try to match that framerate in stead of just speeding ahead. This means a good amount of sleeping between frames - dependent on how much work your application does.

Dependent on the type of application you are developing, this can be throttled down quite significantly. And remember that you can always throttle it back up at times where you need more responsive input and / or animation.

You are, however, not going to get the same runtime efficiency as using an authoring framework built for event-driven apps. At the same time, given that you have good experience in Unity, your production efficiency compared to working with an unknown new system, will be through the roof.

Before choosing, I would consider the following:

  • How much time in total would you imagine that this application runs during a day? If not much, then who gives a *?
  • Would you estimate the production time of the app long enough to sufficiently offset picking up a new tool?
  • Is it likely that the production would benefit from using Unity code already available to you? Or that Unity-based productions following this one would benefit from its code?

If you do end up using a different toolset, I would recommend you look into the packages from Xamarin. You’ll be able to stay in C# and retain lessons learned from Unity and re-use those learned while producing this app.

8 Likes