iOS development in Hackhactons with unknown devs?

Question

I falsely proposed closing due to similar thread here but now this thread is totally different, related to fast development events called Hackhacktons, where you meet unknown people with misc devices. Usually, we develop with Android because not wanting to leave anyone out but iOS would be very cool, now trying to make it possible. With new Mountain Lion and ScreenSharing, it is apparently becoming possible to develop iOS apps without actually owning an OSx.

Unsolved

III. Mountain Lion and VNC: Is there any difference with this option to the hassle of buying non-virtual Apple -products such as Apple Airs? Debugging has no difference over VNC, no?

V. My friend is saying that Mac Mini is actually very powerful so by it I could get Xcodes to many unknwon developers in hackhactons where we don't have time in installations. Correct?

VI. Does the Mac Mini without server have some limit for the amount of users? I want to offer Xcode and debugging tools to my collaborators not owning a OSX -device.

Solved

I. [bames53, yes] What about running Apple server in powerful Apple Desktop Mac Pro -computer closeby the workstations? Can the workstations run anything such as Windows, Debian, Ubuntus and OpenBSD for example? So devs could keep their own machines without any transition costs to Apple -products, possible?

II. [bames53, no] Do I need to pay $99 per annum if there is 10 developers using the Apple server or $99 times 10?

IV. [bames53, no] Is there any Apple product with 3G like x220 that I could use as a hotspot in hackhactons?

Answer 1

It sounds like you're asking about the client limit on OS X Server.

There used to be a OS X Server licenses with a 10 user limit and the unlimited client licenses were more expensive. The new versions don't have any limit; they're all for unlimited clients now.

What about running Apple server in powerful Apple Desktop Mac Pro -computer closeby the workstations? Can the workstations run anything such as Windows, Debian, Ubuntus and OpenBSD for example? So devs could keep their own machines without any transition costs to Apple -products, possible?

I. You can log in to OS X remotely using software available on all platforms. I've never tried to have multiple users logged in to different accounts over VNC but this says it's supported as of Lion.

Do I need to pay $99 per annum if there is 10 developers using the Apple server or $99 times 10?

II. Presumably you're referring to the $99 dollars per year cost to sell on the iOS or OS X app stores. You don't have to pay that at all if you're not selling on the app store, and if you are I believe you only need to pay $99/yr for the entire organization.

If I have OS X Lion on any Mac computer, any amount of users could login and start using Xcode without buying any Apple -product? If it is true, this could greatly speed up development in iOS, without having waste time with all kind of installations. Is there any difference with this option to the hassle of buying non-virtual Apple -products such as Apple Airs? Debugging has no difference over VNC, no?

Yes, it sounds to me like you've got it correct. You probably wouldn't actually want 100 users trying to run Xcode on the same machine though...

I am trying to find a way to develop Apple -apps in hackhactons where most people lack Apple -products. If I could buy a small Apple Mini running a server and acting as a hotspot with 3G, it would be much-much easier to develop Apple -things with limited time. I do like running x220 laptop because of its 3G, not in Apple laptops, so moving to Apple products not really option for me. Then again buying a small Mac -mini may be more useful with VNC, people have displays in their laptops and iPads but-but hw-encoding must be supported so easy to add many displays or slow-slow.

[M]any users on the same hardware will be more resource constrained. I don't know of any differences besides the normal ones that apply to any VNC session. And no, there are no OS X systems with cellular access build in yet, unfortunately.