Is it possible to use Unity Remote for iPhone while developing on Unity free version in Windows environment?
No
As you can not develop for iOS on windows, you can not use it as remote either
i think, the only thing you could try is
- run virtual macOSx on your Win7. I think VirtualBox had less trouble with EFI boot, than WMWare
- use BrassMonkey, no image on phone, but controls can be used on PC
1 Like
I’d like to see this change.
UDK’s iOS remote works on PC, and bonjour works on Windows, so no reason not to (and lots of reasons in favour of it).
If you’ve got a Unity Android license + an Android device, you could simply use the Unity Android Remote to get the same result on your PC.
If not, go to the Android forum and search for UMote, see if it works for you. Hope it helps.
Good luck
So if i develop for an android mobile then while porting to iphone i wont have to worry about the input for it? Of course i will be testing it on an itouch but atleast my development time will be saved if this is possible.
Thats a theory, cause android multitouch is such a topic on its own …
As for the iOS remote being able to work on windows: right, that would be possible. But unity does not allow any iOS authoring on windows so offering it is meaningless, without a mac you won’t do any iOS development, that simple it is and restricting the remote ensures that people don’t forget about it (and don’t conclude from the remote for android that you can do more than 30-40% without an actual android license and won’t get beyond ~60-70% without deploying to device … you will otherwise find out the hard way how wrong the assumption was - the same holds for iOS)
The remote is no way to avoid working on the actual device as what you see and what performance and experience you get on the editor has really little to nothing to do with the actual device, the remote is just so you can test input etc without waiting for the build each time
Thanks for the quick reply 
. I am asking this because i am in a dilemma whether to go for iphone dev or android dev and whether there is a way to reduce the porting time between the two. For now i can afford only one dev env cause i need to buy everything needed for either of the dev env. For android: mobile, android basic license. For iphone: itouch, iphone basic license, mini-mac.
The porting from Android to iOS is, given you don’t use plugins, normally the easier and faster one than in the other direction, because the Android side is the more troubled platform (top selling devices in 2010 like the HTC Desire don’t have fully correct multitouch handling, performance is worse, more hardware and screen size fragmentation, very limited maximum app size on the android market), so when its all fine and working on android, going over to iOS is commonly pretty painless and straight forward, a handfull of adoptions for screen size for example and its done.
Thanks.
Controls are one of the most important things for any application. Not being able to test them because of the lack of a license isn’t the best reasoning. I can plug and use a PS3 controller without having a PS3 license, so why not an iOS or Android device? It might also get people without Macs to think about making the shift to develop for iOS, once they get an idea of what’s possible.
More seriously, as someone developing in Unity on PCs and Macs for both desktop and iOS, I’d like the flexibility to test from either platform. Sure, it’s only really going to be useful when prototyping, but crucially most of our prototyping occurs on PC (where 99% of the content creation side occurs) and moves to Mac for the real thing. We’ve also got designers here who’re exclusively on PC and don’t understand why they can test controls from a PC in UDK but not Unity; it’s fair to say that each one of them represents untapped potential.
I’d like to +1 this feature… Ran into the need for prototyping controls and touch behaviour whilst on my pc, figured it would just work… was wrong 
Can someone please try this out and confirm?
And its exactly as meaningless if you do this as it would be to use the iOS as remote without a license to test on device aka completely meaningless. Also you can’t do it. if you hook up the ps3 controller to the pc, its a pc controller, not the ps3 one anymore, it has characteristics and behavior as any other pc controller.
The same holds for the remote, the experience you get has little to nothing to do with really running on the device as the performance normally is worse, more laggy and different as NOTHING is running on the device. The remote only renders and image and sends input and the image it sends is directly what you see in the game window, not the resolution the mobile would have etc so without a mobile license not even the resolution might be right / meaningfull.
Its fine to do initial input testings, but anything that goes beyond fast prototypes to test something requires deploy to the device to experience the input.
The pc is not able to replicate the ps3 or iOS behavior, performance and memory limitations, if there is a problem with reasoning here then with you missbelieving that remotes etc allow you to develop for mobiles without mobile licenses and testing on device.
Also, as long as you don’t have the corresponding license, you are just not developing for the mobile. You are thinking about and potentially preparing to go to mobile, but you don’t develop for it. Argue with that point as much as oyu want, but cheapsaking and doing half arsed work like this (doing mobile dev by remote, laughable), is the reason why Apple tried to shut out middleware from iOS in 2010, to avoid exactly this kind of stance which results in software thats not opted and making the best out of the device.
If you don’t want to get a mobile license, then please do no mobile development, cause you have no itnerest in it at all obviously, otherwise you would be eager to get it running on the device as fast as possible ot get an idea if the experience is of any use and playable at all (usage wise and performance iwse)
I personally didn’t welcome the fact that UT made the Remote working on all project types instead of only mobiles, it has lead to exactly this kind of total unrealistic assumptions on what kind of use it has at all.
Also, just to clarify that as you brought up the PS3 controller comparision: The PS3 controller is a control device that can be used anywhere on windows as its just a game input.
The remotes only work inside the unity editor. The recent addition only changed that the device remotes are no longer limited to their explicit platforms (android remote in a unity android project, iOS remote in a unity iOS remote), you can not use them in games or anything.
The touches and accelerometer API in Input is also limited to the mobiles
Currently you can use Android device as a remote input device both on Mac Windows and you don’t need any Android license for that. iPhone remote currently is available only for Mac (including Unity Free licenses), Windows support will come later.
Dreamora, normally I agree with your posts, but on this I think you’re just being a little wilfully stubborn. None of this affects you, and if you’re offended by it; that’s your problem.
As it is, I have an iOS Pro license (that’s all it says in my Sig in fact). I don’t care about that, I care about how I work and what makes it more productive and efficient for me and mine.
You’re no stranger to asking for improvements and features that will make life easier and increase flexibility in your working patters. If you want things included in Unity to suite your needs, you can afford to take a step back and respect what other people feel would be useful to them. We’re both paying customers.
Nice one, thanks for heads-up 
This is really strange, I don’t have an android device and frankly it is a bit ridiculous to buy a device only for this matter. It should be like a piece of cake for unity team to develop a unity remote for iphone which work BOTH on windows as well as mac. UKD did it so it means that it is possible.
Hmm, does this work? If it does, I might have to look into this. What is the basic idea of virtual macOSx?
I think the same.