Courtesy: This post was first published on medium.
Yeah you read that right. I’ve been working on an app for mobiles with unity. I know it sounds hilarious. Game Engine for an app? Well hear me out.First of all there were a few fundamental requirements in the app.
It needs to be cross-platform
It has AR functionalities
Obviously for AR functionalities Unity is by far the best choice if you ask me. Do tell me if I’m wrong about that. But for Cross-Platform Development we have lots of other candidates.
I crossed out IONIC from the start as the performance was low. So I ended up with this list.
Flutter + Unity
React-native+Unity
Xamarin+Unity
Unity
Research Phase
After doing some research I couldn’t find any proper resource to embed unity with Xamarin. So I crossed it out. I found out React-Native and Flutter both had the capabilities to embed an unity player. I’m not really a fan of JS so I gave flutter more priority. After doing some detailed research I found out the unity widget for flutter was still in development and it didn’t support iOS yet. Since it doesn’t support iOS. I need to cross it out too. I was left with React-Native only now.
Then I thought. Why should I combine two bad choices together for an APP development when I might be able to do it with just one? Unity is a game engine. So imagination is the limit. I went through the requirements all over again to see If there’s anything that can not be done with unity? Well one other requirement was to show ePUB files on the screen. At the moment I had no clue what it was. Googled a bit about it. And tried to find some easy way out. Well there wasn’t any open libraries that would have done the job. So I decided to make my own if necessary[I didn’t have to in the end].
Choosing to use just unity seemed like a wise idea to me. Because I’ve to think about only one technology stack through the development cycle. Also I reduced some build time and size. Talking about size you must be thinking how big the apk or IPA would be with unity. If it was 2017 I’d never have dared to take this step. But Unity has come a long way. Now we can easily take out the packages that we don’t need. For this project. I only needed the UI elements and some web elements other than that I stripped everything out. And finally the APK was down to 10mb. I was satisfied with the number because if I did follow the React-Native + unity Route , The final size would be 10mb+4mb(react-native binaries) At the bare minimum. I eliminated that.And I did have a reference application which was way above that. Around 50MB(It was a native app,but had too much static content). I was clearly in the Safe Zone.
Development Phase
UI: The first challenge in unity was to develop the UI. Yeah. Since Unity is a game engine, It doesn’t really have any good built in UI elements. It may sound funny, But this is exactly why this is a very good choice.I had to build my own UI components. with whatever BASIC elements unity provided. And trust me this was the best thing. Because I had to make everything myself. I had total control over everything. I didn’t have to worry about which layout I should use. Because I made my own. I didn’t have to waste time on Stack Overflow. Because I knew asking questions like, “How do I make a toast on unity” or “How do I make a bottom navigation on unity” was very stupid. But Since I’ve been working with unity for 4 years I was in the known waters. I sort of made the bottom navigation in 2–3 hours. And it’s exactly how the client wanted. Since I knew EXACTLY what I need to do. I wasn’t wasting time on other features. I didn’t need to read documentations on UI elements. Funnily enough I prepared the whole skeleton of the application in 1 day. I’m sure If I used flutter I’d probably need a lot more than that because I had to learn it and understand it. Oh I forgot to mention the whole app had tons of animations. And do you know what’s a Game Engine is Good for? ANIMATIONS! I could make my own animations. I wasn’t limited by the SDK or the Libraries. Even tho I had to make everything on my own, It was definitely way faster than learning and implementing in another technology. Having less tools made me more performant. Also I should mention that, I didn’t need to Build my app every time I need to test my UI. Because I can just play and check it inside unity 😀 . That sped up the development process 10 fold at the very least. Since It’s a game engine I had to keep the scaling factor in my mind from the start. So the application had the responsiveness to different resolution by default. And unity provided this awesome TeshMesh tool that turns font into a mesh. It basically allows you to scale fonts infinitely. So you don’t have to worry about the size of the phones. I didn’t even have to work much for the Screen sizes because It’s enforced from the start. That also sped up the development process. I think It took me around 1 week to finish 80% of the UI with appropriate animations.
e-Pub: Honestly I had no clue even at this point what is it and how do I handle it. I knew I have to do it. There’s no way around it. If others can So can I. I was looking for an e-pub parser. I did find one. But it didn’t really help me much. I had to read some documentations for it. It seemed like a very hard work to construct a render widget of my own. I’m a very lazy person. I always to to find the way to do things as easy as possible. Also I never compromise the quality of my code. I thought it’s time to dissect the e-pub out. It’s a ZIPPED format in case you didn’t know like me. I unzipped it with a unzipping tool and started to checkout what it had. Soon I realized I’ve been planing this thing the wrong way. These are HTML files. And I have a file called toc.ncx which is an XML file that hyperlinked those files. Basically an index. All I need to do is read the XML index file and show appropriate HTML files on demand. As easy as pie. I needed an web view. Then I found a package that let me render an Web View on top. And I fed it the HTML files. And it worked PERFECTLY! Honestly I didn’t expect it to work so well in the first try. I made my own e-pub manager in 1 day which I thought would take at least 4 to 5. I probably would have never known what it was or how it worked if there was some built in library. I’m glad that I broke it down and made my own manager. This too sped up the development time. Because in every step I knew exactly what I was doing. Having no tools actually made me more efficient.
Compass: The app needed to have a compass. I know it’s easy. Use the magnetometer right? yep. It was as easy as to get some data out of the magnetometer. And unity actually had a nice little API for that. I got the rotation angle out of their function. and used the Rotation component in an Image and it worked just like that. Using game engine for moving elements has it’s perks. The animations were as easy as pie. also optimized by default.
API calls: Well this whole engine was built upon .net, Anything I can do in .net I can do here. And It just works. I did have to make my own small functional class to call the API’s more easily but it was done. I don’t think I got any extra benefits from the engine in this case. It was basic C# code for .net
Dynamic Content: The API’s were used to download images and e-Pub Files. I had to load them dynamically. Loading images dynamically was really easy in unity. It’s a game engine and you are supposed to do that a lot. For loading HTML files on the browser, It didn’t make much of a difference.
Multi-Threads: I’m not sure how many app developers actually use this feature. This is very important. This increases the performance very significantly. The reference app took around 3–4 minute to download all the necessary e-pubs. While my multi-threaded code took around 10 seconds. I also unzipped the files in threads. so the whole setup process was significantly better than the original application. This wasn’t directly an engine benefit. Although most codes in the engine runs in multi thread by default so even novice developers get somewhat more benefit from it anyway. But this can certainly be done and should be done across other development stacks. Just see the difference 3–4 minute vs 10 second.
Localization: The app required to have English and Arabic Language support. Unity doesn’t provide any support for that by default. If you are a native app developer you win in this case. I know how beautifully they make string resources and allow to localize assets. But I wonder how good of a RTL and LTL support is there? In Unity RTL and LTL is basically changing a bool. Still the process was a bit tedious(I think it can be made easier but I don’t have the experience yet). I kinda had to mark each static string text item manually. And there is still some work left to do. But It worked out perfectly. I can switch out fonts at run time too. It took me just a day to work out a manager class for this. I’m sure I can make it better in my next project.
Control Flow: Since it’s a game engine every component could have their own codes attached to them. It’s a beautiful mechanism. If you ever see how this works you would probably hate developing applications with other technologies (Please Don’t).
Building Binaries : Building for iOS or Android was basically as easy as changing target platforms. And unity did everything else for me. In case you can’t relate. Think this like JAVA. Unity has it’s own player for each platform. Code once(You need to do it smartly tho) and run everywhere. I’d say this made a significant difference in building application.
Constant Update: This is the most important optimization to keep in mind while making an app with Unity. Unity provides a constant update loop by default. It’s easy to use it even by mistake without knowing the cost. Do not use any of the UPDATE functions in unity. This functions run every frame or after a fixed time which is like 0.1s or so. This is certainly bad for normal Application that has no reason to utilize such power. Do not write any code in Update function.
Strip Engine Code: Unity does provide a bool check to strip unused engine code. But I’d recommend using the New Package Manager introduced in 2018 to uninstall unnecessary modules for application. This will do more or less the same thing but you will know exactly what you are doing having full control.
LWRP: The new scriptable rendering pipeline allows you to optimize the rendering to a next level.[I didn’t use it yet as it’s still experimental] The new LWRP features a 2D Rendering path. This basically removes all those unnecessary 3D rendering power from the build. Which means you can get a step closer to downsizing your application.
Async Or Co Routine: Since Unity has support for C# 7, you can certainly use the power of ASYNC methods. This will certainly increase your performance in code that needs WEB API calls. Alternatively you can implement Co-Routines smartly to get the same output.
Input System: Game Engines have a bad reputation for not being event based. The new input system is event based and also optimized. Although as far as android or iOS is concerned there won’t be much of a significant performance change.
Project Structure: Since Unity doesn’t give you a default folder structure. This is both good and bad. If you don’t know what you are doing, You are certainly going to mess up the files in the project. You need to plan and organized your files sincerely . This applies to game development as well. Always keep things organized and tidy. Things will go out of hand really fast if you don’t.
License: This is the biggest drawback. Unlike other tools, If you build anything with unity for free, They will show their logo when the app launches. This can only be removed by purchasing a license of your category this can vary from monthly 25$ to 125$ depending on your company revenue. So think twice before you start developing Apps on unity. In my case I had no alternate to Unity for Augmented Reality.
Loading Time: Since it’s a Game Engine, There will be some significant initial loading time difference. A light native app will launch in 1–2 seconds where as this will take 3–5 second depending on your device. Although this is not psychologically noticeable because the screen goes black. This can be optimized with skill and experience.
Sounds Cool Right? Planning to develop your next cross-platform app on Unity? Well hold your horses. This application was only legit because there was an unity dependency. And no matter which route I went for, I’d be adding unity’s weight over some cross-platform tech. So this is the only reason choice of this stack was legit. Otherwise, I still won’t recommend developing Apps with Unity unless you need to have AR features in it. Because the Build size is no way fair. If it was 2017 the minimum build size would have been 20mb at the very least. But Unity is being built up from the ground and everything is being turned modular. So certainly in the not so distant future you can definitely consider using unity for developing cross-platform apps. if you are thinking about monetization you can use ad’s sdk made for unity(yeah official packages). But if you are planning to use some kind of payment gateway, There’s no official support. You can certainly try to make your own. Or Use an web-view maybe. If your application is animation heavy unity is a great choice. Still if you are making a basic application that has nothing to do with AR don’t choose it. Because all the size overhead is not acceptable yet. Because you can get under 5mb with Xamarin,Flutter. Where unity only gets 10mb now. If you are willing to add 5mb for the rapid development , This could be a good idea. Because as far as performance concerned, It’s a game engine. And you get performance by default. I did notice quite a few performance increase in heavy UI animations on the unity application. If you are targeting lower end devices, this will certainly be a issue. Games are power hungry. Even after all the optimization they need more power than some random application. So obviously there’s a significant power difference between native application and a unity application. at 2019 you can almost ignore this. Because the significant power difference would be like using 10mb of more ram usage over native or the batter will drain 1–2% faster I don’t think there will be any significant processing power difference. Once upon a time that was certainly a big issue. Also since we are talking about Cross-Platform. There is certainly some downside to it. If your application needs to run some native code, You would need to write some extra wrapper classes for it. Well in that case You should ask yourself if you really need a cross-platform application. Because If you really need to make system specific calls do you really need a cross-platform app?
Since unity is being supported by .net platform. You can use any libraries from .net . Anything that you can do on .net, You can do in unity. And .net has a very wide range of state of the art libraries. Depending on the requirements I’d choose to develop cross-platform apps again.
