We've just spent a few months writing a component of our stack that uses Objective-C/Cocoa, because it's the only environment that supports a very specific API that isn't available on any other platform to same the level of quality.
We used an HTTP server[1] around it, exposing an RPC style interface. Our app exports metrics with a StatsD client[2] we wrote.
The good news is, it's just what hoped it would be. The app performs incredibly well, and having access to the APIs like GCD and so on is great. The downside is that it's a pain putting the application into production. Being forced to use Mac hardware is incredibly annoying. (We knew this would be the trade off.)
All our dedicated Mac Minis came with 10.7 on them from the hosting company. Upgrading to 10.8 required someone to be present, or attached to the KVM just press next on an iCloud wizard before it boots back in, and I'm always worried that a point release might do something odd.
VMWare ESXi 5.1 supports running OS X 10.8 on top of Mac hardware (legally), so we're leaning towards using that to make the managing the machines slightly easier - being able to snapshot and rollback if an upgrade does something odd or drop into the console if we lose remote access.
I am a product manager that oversees a good amount of ObjC code. I oversee many other code-bases and dont know all the details, ins-and-outs, and quirks of each -- just the high level architecture.
I say this because your landing page makes it very difficult for anyone but a semi-expert to understand the benefits of this. I'd advise you that your target buyer may not be as intelligent as you -- dumb it down for them.
The long opening paragraph has a lot of nuggets in it. I'd recommend you boil it down to this:
- We help you scale your (distribution/development)
- We save you from (cost/failure)
- You'll gain (efficiency/ease of mind)
Stuff like this makes me wish Apple would bring back the Objective-C version of WebObjects or at least release it as open source so it could be brought into the current era.
Great idea! Nice job bringing it to the world. I hope you find great success with the business side.
The biggest problem selling to developers is going to be developers telling you how they would make it better. My advice is listen, but prioritize by following your instincts and the paying customers!
It's not very reassuring to check the FAQ, and to see important questions like, "Is it possible to prevent unauthorised people/clients from using my services?" being answered with a very vague answer like "Yes."
I hope to see more complete and detailed answers for common questions like those.
Fantastic idea, I'm an Objc developer from Hamburg, so seeing that you guys are from Lübeck makes me smile! Good luck! (I've also registered for notifications as I can see some usage scenarios for this already :) cheers
Have you considered making a version without the Apple's frameworks integrated, i.e. the core Obj-C runtime, so you can run on Linux (then you can scale more efficiently on EC2 like Heroku).
I think there is a demand for people who need close to C performance without the need of messing with pointer explicitly and with sane OOP support as default. Your user base is large due to the number of existing iOS developers, and able to interop with C libraries is also an advantage.
The problem is, if Python is a language with batteries included, then on non-Apple platforms Objective-C only comes in kit form -- with certain critical components you have to supply yourself. To wit: due to changes made in the Objective-C runtime made by Apple and backported to the GNU runtime (which, mirabile dictu, is now MUCH more API-compatible with Apple's stuff), the Object class is now only the barest skeleton of a thing, and no longer has +alloc, -init and -free methods in its own right. To get even constructors and destructors without the Cocoa framework, you will have to implement them yourself. Not that hard to do, actually; there are API calls for that. But the average developer is going to wonder what sort of bush league he's operating in where the language runtime doesn't even provide constructors and destructors.
As a rule if you are going to use Objective-C, you are committed to Apple.
While there is certainly some truth to what you say, why do you tie your assessment to the Object class? Object has been on its way out for well over a decade now, and all the alternative toolkits like GNUStep and Cocotron have good support for NSObject and friends.
GNUstep-base is pretty solid if you're looking for an open source Foundation (constructors, destructors, container classes, networking, etc.) that's compatible with Apple's implementation.
ObjFW is much more lightweight, although it does have its own set of conventions. Fortunately, +alloc, -init, +new and -dealloc are all present and accounted for.
Having ported significant code-bases to both Linux and Windows with both GNUStep and Cocotron, I'd say this is possible today, though how easy it is depends a bit on the scope and complexity of your codebase.
What I like about Objective-Cloud (apart from the name!), is that it allows you to go to a hosted solution quickly, and then when there is a further scaling requirement you can decide wether doing a port is justified to lower costs.
I also really like your succinct summation of Objective-C benefits: close to C performance [..] with sane OOP as default (not sure about the pointers...)
I've blogged a bit about Objective-C web performance, for example compared to Ruby and Node.js here:
You know, it seems like you could use MacRuby to write the web bits and possibly also to talk to the Obj-c libs you would need. Then you get the already made nice Ruby things like Sinatra for writing your HTTP services, and still use Obj-c for specific libs or things you would need to use.
FWIW - Glancing at your website, I am not immediately sure what it means to Push Objective-C to the cloud? More specifically, what is the pain point you are solving for me?
Something similar I've been using: http://webappkit.org
"WebAppKit is a BSD-licensed framework for creating web applications using Cocoa and Objective-C, running on Mac OS X."
Quite neat to use Obj-C and all the great frameworks on the web as well.
The big problem with using Objective-C for stuff like this is that you almost have to host it on Apple Hardware, which is quite expensive and hard to do by your self in a cloud-like fashion. With the Objective-C in the cloud service you move the hosting to them of course, but it is still a problem lurking when (and if) they are going to scale it really big.
As someone who has used both GNUStep and Cocotron, I have to say this is less true than you probably think, and yes, there are people actually doing it.
In fact, one of my recent gigs was moving an Objective-C code-base from GNUStep/Linux to Mac OS X (and then with Cocotron back to Linux).
Objective-Cloud seems to be a perfect bridge between those worlds. After all: worry about scaling problems once you scale, because chances are you won't ;-)
And if you do scale up so amazingly that you outgrow Objective-Cloud or hosting your own, I am pretty certain that the transition will be less involved/painful/drawn-out than, let's say, Twitters move from Rails to Java. :)
Well, technically it doesn't have to be Apple hardware. They could be running hackintoshes, which would obviously be against the EULA of OSX. Another possibility is virtualization. Somebody correct me if I'm wrong but I think the OSX Server EULA allows virtualization since 10.7. So setup any linux server off the shelf and virtualize OSX Server instances on it and you have your cloud building blocks.
The Apple Software License Agreement for OS X Mountain Lion[1] is not your friend here.
…you are granted a limited, non-transferable, non-exclusive license:… (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using OS X Server; or (d) personal, non-commercial use.
So development, testing, running OS X Server, and non-commercial are the legal uses.
The Mac OS Server license is more restrictive, a single copy on Apple branded hardware.
The license does allow virtualization, but only on Apple hardware running Lion or later as the host OS. So there's still no way to run OS X on commodity hardware without violating the EULA.
There's opensource Obj-C compilers by both GNU and LLVM/Clang available for windows and linux, so it doesn't have to be hosted on apple hardware afaik, but when you start using library frameworks, that I'm not sure about.
This would be amazing for code reuse when integrating with a Cocoa app front-end, much as using node.js can let you reuse JS code between server and client.
I like the idea a lot actually. Using Apple's frameworks for web apps could indeed be useful. I just wonder to what user numbers such a service would scale, given Apple's limited hardware offerings. Didn't Apple promote using VMware boxes on commodity hardware for some while? Is this possible now with OSX Server licences?
There's less of a performance hit at runtime than using a scripting language like Ruby/Python/Lua/Perl/PHP, since the generated code uses a fair amount of compiled C.
You can use Smalltalk-style messaging that C++ and C alone wouldn't give you. So you can query objects for methods, variables, and other things that they may or may not have without causing your entire app to crash.
You wouldn't have to wait at runtime for a VM to startup, since Objective-C has no VM. :)
One use-case I've encountered before is to take your models from your iOS/Mac application and directly reuse them on the web. In my circumstance, it was compiled and run on Linux, though this seems to use Macs which could be useful if you have a Mac-only API that you use.
Yeah you're really quite tied into apple hardware here... I wonder if it would be possible to run mac os x server instances on VMs? Good luck anyway... I often wanted to use cocoa server side since it's such a great platform and xcode's pretty great too.
I generally find the hardware cost is not dominant with respect to bandwidth and physical placement costs. So even if you pay almost twice as much per compute cycle[1] it is still buried in the other deployment costs.
The bit that keeps me from using Mac Minis (and I have a huge software reason to do it) on my server end is that I don't trust that I can manage them remotely. If I can't get to a console and reboot with remote media I'm not willing to commit to it in production. If you are big enough to have 24x7 staff colocated with your hardware then things are a little different. Then they'll just cuss at you for making them drive a little cart with a monitor and keyboard around the place.
EOM
[1] It isn't that high for one unit, compared to reasonable quality commodity gear, but when you look to comparing, say 16 Core i5 processors of power there are some nice commodity solutions that are much cheaper than 16 minis.
There must be remote management systems that will capture DVI output and provide mouse/keyboard commands over USB. Modern Macs all do netboot so that takes care of the remote media. Probably isn't cheap, though.
Thanks. I am sure that it is possible to do the same thing we do by running OS X in a virtual machine. We decided not to do it like this. Let's see how it works out.
If I'm not wrong Tim Cook did hint at a revamp Mac Pro in spring 2013. I believe it will be build for server farm as Apple itself needs hardware for their own server farm.
Maybe. He's said they will have something for pros, which most people take to mean a revamped Mac Pro. But it could also be just a variant of the Macbook Pro, or something else entirely.
I wonder if there's any clever trickery can be done here to let web services get access to iCloud APIs. (I suspect not, due to the authentication nightmare that would be involved)
Apple's apps are at a real unfair advantage, here.
Say I wanted to replicate Apple's Notes app: I can write iPad, iPhone and Mac apps that all share the same storage (and update in the background without the app running). But there's no way for me to create an equivalent of icloud.com that lets users edit their notes on the web.
You will be able to do that with Objective Cloud. We will have a distributed storage service that you can use. You will be using Core Data like you are used to.
One possible improvement (and maybe it's not feasible—you've obviously spent a lot more time thinking about this than I have) would be to accept any object that implements NSCoding, rather than strictly NSDictionary objects.
Depending on how you're isolating instances I could see how that might open up a huge can of worms from a security perspective.
It is really cool to see services like this. Specially since we are actually working on the sibling of this, but instead of using Objective-C we use C# (http://iknode.com).
I can think of a couple of ways we could work together. Are the founders on HN ? Drop me a line.
While the dictionary to http mapping is a nice touch, will it be possible to deploy our own http servers?
While CocoaHTTP isn't bad, I've got my own lib that is not only around 3 times faster (request/response), but also has other benefits I'd like to keep.
The bandwidth pricing is way off. With the 99$/month plan, you only have 35 GB of traffic included, and each subsequent GB costs three dollars! Madness.
We are thinking about the pricing constantly. The problem ist that we cannot predict how people might use their access to Objective Cloud. These prices are very conservatively and might go down quickly.
Put a cache on a machine in EC2 with your static assets. Your dynamic, uncached work is unlikely to take much bandwidth. Especially if you JSON it in from pages served on EC2.
We used an HTTP server[1] around it, exposing an RPC style interface. Our app exports metrics with a StatsD client[2] we wrote.
[1]: https://github.com/mattstevens/RoutingHTTPServer
[2]: https://github.com/newspaperclub/statsd-cocoa
The good news is, it's just what hoped it would be. The app performs incredibly well, and having access to the APIs like GCD and so on is great. The downside is that it's a pain putting the application into production. Being forced to use Mac hardware is incredibly annoying. (We knew this would be the trade off.)
All our dedicated Mac Minis came with 10.7 on them from the hosting company. Upgrading to 10.8 required someone to be present, or attached to the KVM just press next on an iCloud wizard before it boots back in, and I'm always worried that a point release might do something odd.
VMWare ESXi 5.1 supports running OS X 10.8 on top of Mac hardware (legally), so we're leaning towards using that to make the managing the machines slightly easier - being able to snapshot and rollback if an upgrade does something odd or drop into the console if we lose remote access.