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!

 

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.

 

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...

 

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

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.

 

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.

 

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 F***ing 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.

 

Some time after I wrote this original post, I wrote an article that was featured on Gamasutra about why I chose to use Unity for a non-gaming app. I actually did a pretty thorough assessment of my requirements and my options before coming to a decision. You can read about my process there. I still stand by that decision today.

In the time since I did that research, I hear that Xamarin has become a much more attractive option for cross-platform app development. At the time, Xamarin didn't have shared cross-platform UI code and I vaguely remember IAP and file I/O being a pain to implement on Android. Those, and the limitation on code size in the free version, were the reasons I ruled out Xamarin at the time. If I were to do this again today, I would probably give Xamarin another look.

I also don't think using Unity does users that much of a disservice. Sure it bloats out the final build a bit... but with fast wi-fi everywhere and tons of storage on mobile devices, a lot of people won't care. Sure it uses a bit more battery power, but in my tests I saw no noticeable difference. If people aren't using your app for hours at a time I doubt they would ever notice. In the months since release, with thousands of downloads, I've never once received a complaint about app size or battery use.

With that said, I don't think Unity is a good solution for all non-gaming apps. I think it would be silly to try and build a file manager or notepad app using Unity, for example. In those cases, sure, try to learn something new. I did actually try myself for a short while. But if, like me, you try to build something in a different framework and find yourself thinking "This is a huge pain. I could build this in half the time in Unity." then, I say, use Unity.

 

Coolio Glad to hear it all worked out.

 

Actually I think this is a very healthy discussion has it also promotes s

Meanwhile I also still stand for everything I said as I strongly disagree with this kind of option and arguments. I just hope that not to many developers out there identify with this kind of easy and careless thinking about what they are doing for users where they don't care about nothing else then as you said:

"Maybe all they want to do is build an app as quickly as possible to do a little extra income."

This was your only real requirement since the beginning so I am not surprised than more than 1 year later you still don't understand the right process for non-games mobile development. As I said before, it seems you lost a good opportunity to learn something new in the process.

My advice would be if you only know Unity and don't want to learn something new, the right way to do certain things or expand your knowledge as a developer..please invest your time in game development instead because I assume that was your first reason to learn Unity in the first place.

 

See my post above and the Gamasutra article I wrote. I did a fairly detailed analysis of my requirements and options at the time. My reasoning was not merely "I know Unity. I don't want to learn anything else."

 

Well the article is done well and great analysis. The app you mention there looks like a game/media app where Unity fits perfectly or better than native solution at least based on the video. I however based my previous reply on your original post which gives a totally different impression and has a description of a lot different app (maybe it was a different project?) where I would strongly disagree using Unity or any game engine.

For future readers I will explain why. If you mimic any kind of native looking app with a game engine the battery issue is one of the problems for the users but not the biggest one. Biggest issue is that your app wont comply to any of the platform features by default which can include things such as copy&paste, UI controls visuals and gestures, UI flow forward/back (buttons or gestures), accessibility features and so on.

For multimedia, children story books, visualization or any type app that has greater need of visuals than usability a game engine is an option. For iOS most of the badly made stuff gets stopped at the review process but still a lot of stuff get past em. Android is a wild west when it comes to these and there are a lot quickly done apps

 

Hey Try this Boiler Plat code out. It's easy to start : https://github.com/namanrajpal/Unity-Mobile-App-BoilerPlate
Fine place to start non-game app dev with Unity

 

From a business perspective, I would say that if you know Unity well and are fast with it, and it can do the job, use it first. Your problem right now is that you have no product to validate. If Unity lets you build and validate faster, by all means use it. Ship something, get feedback, and optimize once you have a real need to do so.