- Home /
Developing for IOS
Hi - I am currently developing a game that eventually (once I have bought an mac mini / IOS basic licence / Apple dev access license) I want to release on the app store.
I was just doing a little research - and a terrible thought has come over me; I have developed my game (so far) in Javascript - does it need to be in C++ to be compatible with IOS functions (tilt)? I don't know where to start with C++, and really don't want to have to start all over again.
Secondly - I want to develop on the PC to begin with and get the basics down, then move over to the mac when i'm getting somewhere (this beginning stage will actually determine whether I even bother to buy a mac mini at all). Can I use my IOS basic license on both machines? And can I develop on the PC in the first place?
Thanks for reading and for any knowledge offered on this.
Korpers.
Answer by Statement · Apr 04, 2013 at 11:51 AM
You only need to worry about C++ if you're writing native plugins which I doubt you're doing. Unity will cross compile your JS code to the target platform. You can't develop iOS games on Windows (Which I guess is what you meant by PC), you'll need a computer with Mac OS on it. License-wise, you can use your license on two machines that you have exclusive access of, but it still won't help you build iOS apps on Windows (or rather; non-Mac OS).
Also it is a good idea to get down with an iOS build early on (you can use the trial to test stuff out). In particular one of the things that appear to catch a lot of people off guard is that the devices have less RAM and CPU/GPU power than a typical PC so if you build your game up front and then try to get it on iOS, chances are that your game isn't running fast enough or using too much memory, so you need to step back and spend time fixing that. If you did it up front, you'd continuously keep improving the product you're making, so that is something you should keep in mind as well. Just some advice.
Thanks for this. However, I was under the impression I could develop for IOS on the PC, using the on-screen simulator of an iphone or something? I'm completely aware that to build and submit I need a $$anonymous$$ac OS - but are you saying I can't even develop the basics of the game on my PC? In which case - what would be the point of the 2 license thing? And do I now need to throw away my project so far?!
Also, please you tell me what a 'native plugin' is? I hope that doesn't mean things like the accelerator or touch screen?
See Plugins and Plugins for iOS for more info.
You can develop on PC in the Editor/Standalone if you want, but if you aren't running on an actual device you won't know how your game will perform until late into development which could become hard to fix at that stage. Some features exist only on iOS and some features doesn't work on iOS due to different hardware and input devices etc.
Sometimes you might want to make games both for Windows and $$anonymous$$ac for example, then you would probably want to have two machines for convenience. Also if your computer crashes, then you can use the other one while you're recovering/migrating your license from the crashed computer through Unity Support. Some people might only make iOS games but want to use one computer at work and one at home. There are many reasons why you'd want to be able to activate Unity on more than one machine.
Afaik, Apple doesn't allow/have simulators to run on Windows. It is nothing that we can change. Anyhow, the product of building an iOS app through unity is an xcode project, and you use xcode to build the final app to your device or simulator.
Thank you for your great advice Statement. It has covered all I needed to know. Yes, I totally agree with you on your points about using a $$anonymous$$ac OS and an iDevice on hand to test performance RA$$anonymous$$ issues etc. At the moment I am really only playing around with the basics as I'm a total beginner. I just now know I can purchase the IOS basic add on and not have to worry about pyaing for it again when my $$anonymous$$ac $$anonymous$$ini arrives.
Thanks again.