Search Unity

How hard is it for an intermediate windows unity developer to start with iOS?

Discussion in 'iOS and tvOS' started by monkeybrother, May 27, 2013.

  1. monkeybrother

    monkeybrother

    Joined:
    Oct 14, 2010
    Posts:
    83
    Hi. I work with architectural visualization and I'm the Unity guy at my workplace. Today an architect asked me about developing an iPad app that she can show her clients (click on a house, zoom in, get info, maybe walk around a bit, things like that). The problem is that, so far, I've only developed for web player/windows (don't hit me) and have no idea what it takes to get started with iOS development.

    How long does it generally take to set up an apple developer account, for example?
    What do I need to think about in general when switching from desktop to iOS?
    I'm not a hardcore programmer, I'm a 3D artist that happens to know JavaScript: will I have a hard time switching?
    How can I install the app I'll create on new machines? I've understood that iOS is a lot more closed than android.

    I know these are pretty general questions, but I would really appreciate your input so that I don't get in over my head.

    Thanks.
     
  2. Glockenbeat

    Glockenbeat

    Joined:
    Apr 24, 2012
    Posts:
    669
    In general developing for iOS is not that much of a deal if you know any other platform. Also it seems like you don't have a choice. ;)

    You will specifically need to take care of some things, which are also the most important things:

    • UI/Aspect ratios: The aspect ratios of the displays on mobile devices are often different to what you are used to on the PC. For example, up to iPhone 5 the iPhone had an aspect ratio of 3:2. That makes a difference if you build your game controls.
    • Input. Input is handled differently on mobile devices than on PC - so far that should not be a suprise. Unity is quite easy with that though and you can basically switch from a mouse/keyboard driven control type to a touch based control type in a minute. Or let's say hours.
    • Now the important part: Hardware limitations. Compared to mobile devices, the PC has nearly infinite power. Mobiles still play in another league, though they caught up a bit and it's not as difficult as it was about 2-3 years ago. Still you have limited computation power and will need to take care of that, meaning:
      • Keep the draw call count low!
      • Share materials wherever possible (to further reduce draw calls)
      • Take advantage of optimization techiques such as occlusion culling and similar.
      • Have an eye on your memory consumption. Mobile devices don't come with 8 GB of RAM plus 1 GB of VRAM, but instead depending on the device you are looking at 100 MB will need to be sufficient (e.g. iPhone 3GS).
      • Don't use heavy rendering techniques, overdraw, too much of transparency and so on.
      • Have an eye on the vertex count. That's still a limiting factor.

    These are of course just the basics. Most techniques you would use on a non-mobile platform to get the best performance out of your application are of course also valid for the mobile platforms.

    Also, getting signed up for the Apple developer program is mostly a question of minutes. As far as I can remember that process was fully automated on Apple's side. Once they get your money, you're in (and they only accept credit card, so it's basically in real time).
    Don't confuse that with App submission times though. Once your app is done and you submit it to the app store, you can take some days off (ranges from 2-14 days, depending on the workload on Apple's side of things).

    As for the installation on devices: You can either add your devices as development devices and then just publish your app to those, or you can decide to go for "Ad hoc distribution" - just look that up on Google/Apple, you should find all the details you need. In short: It allows you to install the app on up to 100 devices.

    One sidenote: Developing for iOS requires a Mac. No way around that.
     
  3. monkeybrother

    monkeybrother

    Joined:
    Oct 14, 2010
    Posts:
    83
    Thanks Glockenbeat. That's exactly the kind of answer I was hoping for. I might have to read up on optimizing my scenes, on desktop it usually works if I optimize the mesh, but that probably won't be enough in this case.

    Thanks again.
     
  4. Lukas H

    Lukas H

    Joined:
    Jan 16, 2009
    Posts:
    394
    Like Glockenbeat said, its not that different from Unity desktop. He gave some very good advice already.

    Just a few notes from my side:
    - Architectural visualization means probably a lot of high res light maps. Keep in mind the iPad doesn't support textures above 2048x2048. Also you generally have around 100-120MB memory in total, thats for everything like textures, models, engine, sound etc so thats probably not a lot for what you are used to.
    - If you don't need fancy multitouch gestures for input, just Input.mousePosition and GetMouseButtonDown(0) as those translate to the first touch
    - If recommend NGUI for handling gui stuff, it has great tools for anchoring and scaling. The learning curve is steep for beginners though.
    - When you can, don't use dynamic lighting but lightmaps or use vertex lighting only.
     
  5. OceanBlue

    OceanBlue

    Joined:
    May 2, 2013
    Posts:
    251
    Keep your textures square (1024x1024, 2048x2048 ) for best compression.
     
  6. Glockenbeat

    Glockenbeat

    Joined:
    Apr 24, 2012
    Posts:
    669
    Eliminate the "best" - there is no compression at all for NPOT textures.

    edit: I see what you mean - and thus you are right. Though I don't know if square textures are really compressed in a better fashion than non-square. You can still use a non-square format like 256x128 though and still get compression. Yet if you don't have these power of two values you will get no compression at all.
     
    Last edited: May 29, 2013
  7. orb

    orb

    Joined:
    Nov 24, 2010
    Posts:
    3,037
    Different-length sides on textures should make no difference as long as they are powers of two. Some searching around the web tells me most agree there is only a tiny performance-hit (on OpenGL ES 2.0 devices, at least) if you use NPoT-sized textures[1]. Individual elements at odd sizes inside a PoT texture should be fine. But if you're doing mostly buildings/furniture the materials are probably unwrapping to nice squares anyway?

    Another tip for those new to the platform: Get to know Xcode and Instruments. Know the flags, experiment with settings, break as much as possible so you're prepared :)

    Also read the most up to date introduction to development on Apple's developer site, as a lot of the clunky old ways are no longer valid. Fortunately :)

    [1]The engine or the OS may treat NPoT textures differently, though, making them use much more memory!