iOS Would you be interested in a remote Mac service?

[mccannmarc]

Myself and my business partner have come up with an idea that would potentially let anyone with any computer and OS develop for the iPhone with the only requirement being a reasonable internet connection.

The service would involve logging onto an OSX terminal server with a remote desktop application. Each member would have their own account and storage so in effect you basically have a remote Mac to use as you wish.

We have done research into the software and kit and its definitely doable, we just wanted to gauge peoples interest before we made any sort of plans or investment. The service wouldn't just be limited to iPhone development as it could be used for any sort of Mac work.

We would have multiple account templates that the user would select on account creation but for iPhone developers each user would have access to all the development programs they need for iPhone development as well as having pretty much free reign over their account within the allocated storage quota. One of the main benefits would be the portabilty, most OS's have a remote desktop app included so you could pretty much log onto your account from anywhere, we would also consider an online version for browser use. Heck you could even develop for the iPhone ON the iPhone!

Deployment to device would have to be via ad Hoc (although it may be possible to do remote USB, I'm not sure) but the simulator would work just fine.

We are thinking of a few price structures but our favourite at the minute would be around £200 for a years access, £25 for a month or £3 a day. After the period has expired accounts wouldn't be deleted they would just be suspended to be resumed whenever the user needs them again. These prices are subject to change but based on what we have proposed would anyone without a Mac be interested in such a service?

 

[dejo]

Interesting concept, no doubt. I'd have the let this idea stew some more before I could decide but let me respond to this:

Deployment to device would have to be via ad Hoc (although it may be possible to do remote USB, I'm not sure) but the simulator would work just fine.

The simulator works fine usually. But there is no substitute to actually testing your app on an actual device. Apple highly recommends on-device testing and never relying solely on the simulator.

 

[jnic]

The simulator works fine usually. But there is no substitute to actually testing your app on an actual device. Apple highly recommends on-device testing and never relying solely on the simulator.

You could create some little application to proxy the USB interface from the user's machine to your remote system.

£200 for a year seems awfully cheap. The cost of hardware + electricity + bandwidth + virtualisation setup + OS licence might be much more, and compilation is pretty CPU-intensive.

I agree though, cool concept.

 

[lazydog]

Deployment to device would have to be via ad Hoc (although it may be possible to do remote USB, I'm not sure) but the simulator would work just fine.

I'm not sure I understand, people will debug/test on the simulator over the Internet? What about audio?

ß e n

 

[Cromulent]

Good luck with that.

I imagine Apple's legal team will be on you like a tonne of bricks.

 

[uberamd]

I would imagine a bunch of compilation tasks would cripple the system. Interesting idea though.

 

[mccannmarc]

@ Dejo - I agree whole heartedly, although ad Hoc distribution would be able to solve that issue for now. We will be looking into what jnic suggested as that would be brilliant on many levels, remote usb drives etc. Maybe writing a little lightweight client that allows the user to control these aspects would be useful.

@ jnic - We are still looking into this. We would be starting out with an Apple XServe which comes in at around £2500 with Leopard Server + Unlimited seat licenses. I work for British Telecommunications in the Data Centres so I'm confident I'll be able to arrange something where storage, power, connectivity and cooling etc are concerned at a fair price. Where cost is concerned we are looking to break into the market for now so we are going to have to make a loss to attract the customers, we could limit some of this loss by offering premium services and maybe getting some advertising revenue. This side needs more attention than we have given it for now, we only thought of the idea last night so these are premature estimations for now.

@ lazydog - Everything will be over the internet, coding & testing you name it. Audio is possible, there are many RD clients that support audio mapping so this is something we would include for sure.

Thanks for the suggestions and critique people, its very useful and is food for thought... keep them coming. Myself and Robert will be running some tests with this very soon to see if the idea is plausible in reality, we will let you know when its up and running if anyone wants to spare a bit of time to test drive the mock up?

 

[jnic]

I imagine Apple's legal team will be on you like a tonne of bricks.

mccannmarc's in the UK, so that's 0.98 Imperial Tons.

 

[mccannmarc]

Good luck with that.

I imagine Apple's legal team will be on you like a tonne of bricks.

Care to explain why you think that is so? Remember this is an idea not something we have actually done anything about yet so I'm willing to hear everything you think may be a problem no matter how small

 

[mccannmarc]

I would imagine a bunch of compilation tasks would cripple the system. Interesting idea though.

I'm sure they would, what are the chances of everyone hitting the compile button at once though? By the time this was a concern we would have the resources for a larger infastracture

 

[Cromulent]

Care to explain why you think that is so? Remember this is an idea not something we have actually done anything about yet so I'm willing to hear everything you think may be a problem no matter how small

For a number of reasons.

1. Apple have a requirement that each iPhone developer be registered. They enforce this by putting the download in an area only registered developers can access.
2. Parts of the iPhone SDK are still under NDA, you will be by passing this by allowing unregistered developers access to the tools required to build and compile iPhone applications.
3. Apple have made the iPhone SDK Mac only I would imagine for the simple reason that it will drive sales for Apple Macs. Remove that requirement and Apple lose money, I'm sure they have clever enough lawyers to find a way to put you out of business if they really want.

On the other hand I may well be wrong. Your choice, your risk.

 

[mccannmarc]

For a number of reasons.

1. Apple have a requirement that each iPhone developer be registered. They enforce this by putting the download in an area only registered developers can access.
2. Parts of the iPhone SDK are still under NDA, you will be by passing this by allowing unregistered developers access to the tools required to build and compile iPhone applications.
3. Apple have made the iPhone SDK Mac only I would imagine for the simple reason that it will drive sales for Apple Macs. Remove that requirement and Apple lose money, I'm sure they have clever enough lawyers to find a way to put you out of business if they really want.

On the other hand I may well be wrong. Your choice, your risk.

Regarding points 1 & 2 - Ok, I asked for that one but then the solution is simple - we wont install the developer tools, the user can do that themselves. Problem solved, its hardly a big deal.

Point 3 is definitely the one that counts here, we will really have to look into this one at depth with our lawyer, I haven't spotted anything obvious that would prevent such a service as of yet but IANAL.

Thanks for the critique though it's all food for thought

 

[uberamd]

Regarding points 1 & 2 - Ok, we wont install the developer tools, the user can do that themselves. Problem solved, its hardly a big deal

Point 3 is definitely the one that counts here, we will really have to look into this one at depth with our lawyer, we haven't spotted anything obvious as of yet but IANAL.

Thanks for the critique though it's all food for thought

Don't many of the dev tools NEED to be installed in /Developer/ (root of drive), so they NEED admin access? On a shared environment this won't work as far as I can tell.

 

[mccannmarc]

Don't many of the dev tools NEED to be installed in /Developer/ (root of drive), so they NEED admin access? On a shared environment this won't work as far as I can tell.

Hmmm, thats a very good point. This will need some looking into, thanks.

Im not sure that any of the tools that need to be in /Developer are iPhone specific although I may be wrong. If so would it not be plausible to write a script that runs on login and changes the environment variables/symlinks per user?

 

[lazydog]

Putting myself in the shoes of a Linux or Windows user/developer: if I was thinking about developing an app for the iPhone, I might very well sign up to your system for a few days just to see what iPhone dev was like. But I think after a couple of days I would know enough to make my mind up and either go out and buy a Mac or not bother with the whole thing. I really don't think the price of the Mac is a big obstacle for someone serious about developing for the iPhone/iPod. Switching OS might be though.

b e n

 

[mccannmarc]

Putting myself in the shoes of a Linux or Windows user/developer: if I was thinking about developing an app for the iPhone, I might very well sign up to your system for a few days just to see what iPhone dev was like. But I think after a couple of days I would know enough to make my mind up and either go out and buy a Mac or not bother with the whole thing. I really don't think the price of the Mac is a big obstacle for someone serious about developing for the iPhone/iPod. Switching OS might be though.

b e n

That's certainly a very good point but its also a very personal approach (one that I took myself as I replaced all my PC hardware with Mac hardware). It really is dependent on the individual. Don't forget my ultimate goal here is to make money, if a guy signs up to my service for a few days, great! Even if my service ended up as more of a preview service it has benefits:-

1.) Apple won't want me dead
2.) High turnover rate and probably more cash in total than a small amount of long term users
3.) Less stress on the servers

 

[lazydog]

mccannmarc, I'm not trying to put you off! I'm just trying to envisage who your customers might be because this would affect your business model and server needs.

ß e n

 

[mccannmarc]

mccannmarc, I'm not trying to put you off! I'm just trying to envisage who your customers might be because this would affect your business model and server needs.

ß e n

Thanks It's all appreciated, this is the reason I put this poll on here. Its easy to be blinded by a seemingly good idea and forget or purposely avoid the potential pitfalls

 

[jpyc7]

I would not use the service, but I think the people who would benefit from a remotely hosted desktop are people who want off-site data storage and frequently work from different places. Maybe for security reasons, they don't want to carry their data with them on their laptop in case the laptop gets stolen. Of course, if the files were so sensitive, you would also have to encrypt their files. So I think there is a niche market, but you would have to find the people who use Mac OS.

Anyway, I don't think any iPhone developer would need or want to do development remotely, but they should use an off-site storage to backup their encrypted code repository.

 

[jnic]

Regarding:

Don't many of the dev tools NEED to be installed in /Developer/ (root of drive), so they NEED admin access? On a shared environment this won't work as far as I can tell.

Hmmm, thats a very good point. This will need some looking into, thanks.

Im not sure that any of the tools that need to be in /Developer are iPhone specific although I may be wrong. If so would it not be plausible to write a script that runs on login and changes the environment variables/symlinks per user?

Surely you'd virtualise an OS instance per person rather than providing user accounts? This has the advantage that:

1. Malicious users can't attempt to exploit privilege escalation to access other user accounts.
2. Cleaning up if an account gets trashed is trivial (just drop in a fresh OS image).
3. Less of a support headache from users needing you to do things for them.

 

[mccannmarc]

Regarding:





Surely you'd virtualise an OS instance per person rather than providing user accounts? This has the advantage that:

1. Malicious users can't attempt to exploit privilege escalation to access other user accounts.
2. Cleaning up if an account gets trashed is trivial (just drop in a fresh OS image).
3. Less of a support headache from users needing you to do things for them.

Funny you should mention that, I was JUST looking into that this morning. This approach is much more difficult to implement by the looks of it but its by far a superior way to do this.

I wonder if the license that you get with Leopard server would cover this kind of usage?

 

[jpyc7]

Regarding: virtualization

Funny you should mention that, I was JUST looking into that this morning. This approach is much more difficult to implement by the looks of it but its by far a superior way to do this.

I wonder if the license that you get with Leopard server would cover this kind of usage?

I did a google search for VMware and mac os x when I first read this thread. There weren't that many links, but it didn't seem as if VMWare was able to license the necessary rights for virtualization. VMWare is a fairly large company, so I think if you are a small company you might have trouble too. Then again, maybe Apple would prefer to work with a small company.

 

[uberamd]

Regarding:





Surely you'd virtualise an OS instance per person rather than providing user accounts? This has the advantage that:

1. Malicious users can't attempt to exploit privilege escalation to access other user accounts.
2. Cleaning up if an account gets trashed is trivial (just drop in a fresh OS image).
3. Less of a support headache from users needing you to do things for them.

It is illegal to virtualize OS X with the exception of OS X server. And OS X server licenses run $500 each. Seems expensive. Also, VMWare Fusion is not designed for this type of application. From what I am aware there is no web based GUI for a user to manage their virtualized OS if it crashes, etc.

 

[mccannmarc]

It is illegal to virtualize OS X with the exception of OS X server. And OS X server licenses run $500 each. Seems expensive. Also, VMWare Fusion is not designed for this type of application. From what I am aware there is no web based GUI for a user to manage their virtualized OS if it crashes, etc.

We are looking at buying an xserve with OSX server preinstalled and with unlimited seat licenses, that isn't the problem to be honest. We know 100% we can serve numerous user sessions from one OS, to make that work though we will need to really beef up the security.

Virtualization is worth looking into but its going to add to the expense greatly, it may be something we offer as a premium service but for most users a secure user account would be suitable.

 

[uberamd]

We are looking at buying an xserve with OSX server preinstalled and with unlimited seat licenses, that isn't the problem to be honest. We know 100% we can serve numerous user sessions from one OS, to make that work though we will need to really beef up the security.

Virtualization is worth looking into but its going to add to the expense greatly, it may be something we offer as a premium service but for most users a secure user account would be suitable.

How are you going to graphically hook users into the server? Via VNC or something else? How are you going to limit CPU time per user account so one person compiling doesn't hog up all the CPU cycles for hours on end? How will you protect files? FileVault is not recommended for use with programming/compilation because it slows down the process due to the need to encrypt files.

Plus a lower-end Xserve can easily run $4,000+, this seems like an expensive project. While its an interesting idea, I personally don't see how it is technically or financially feasible.