HN Jobs

Propeller, based in SF, is looking for great full-time developers to help change the way simple mobile apps are built. We're trying to do something legitimately new here, so first, some background: Right now, building a mobile app means: 1 (optional): Try to build a crappy version using non-native platform technologies like: HTML5, Titanium, PhoneGap, or some other solution that attempts to use or translate the web way (HTML/JS) to mobile. 2: Spend a lot of time and money building your mobile app from scratch using native API (Cocoa/Android) Apart from the pain induced when you try to do (1) before (2), this is fine if you're building a complex or involved app that merits significant and dedicated time and money for development. But, at Propeller, we think there is great demand for the ability to build simple mobile apps (which is why tools for (1) exist.) But, (1) sucks - it's not native, or it's native translated from web technologies, and becomes unnecessarily complicated. Method (2) works, but it's incredibly expensive because everything is being built from scratch. HTML/JS was a great idea when shipping code was difficult, and users didn't want to install software. Everyone had a runtime already (the browser), and so simple applications were built on that platform. First just with HTML (the <form> element) and then HTML+JS for clients that were called "rich" but just needed to do things HTML forms couldn't do. But taking this model and attempting to make it work on mobile is not only bad engineering, it's misguided! This model makes sense when you can't ship actual code to your users, but Apple changed all that by inventing[1] the App Store (straightforward) and getting users to trust it (really a big deal.) This removes the distribution problem. Users will install your software, so you don't need to target a legacy distribution stack that was originally designed for sharing documents and a really weird language with so many quirks a book title "The Good Parts" had to be written. It's bad engineering motivated by decisions which aren't relevant anymore. Building mobile applications on top of (or translated from) a legacy stack with so many workarounds, shims, libraries on top of libraries, Shadow DOMs, cross-browser compatibility, compile-to-JS, minification, XSS protections, and so on is just crazy. HTML/JS on mobile will always suck and will always play catch-up because it's built on a legacy foundation. Hell, it sucks on the desktop now too. We put up with it because the alternative isn't feasible. </rant> But, there is another way! There are good ideas here. Shipping code (and waiting for Apple to approve it) brings us back to the days when we had to release major versions and burn them to CDs and put them in boxes. It's un-agile. Developers love writing web apps because it's agile - they can change their application, deploy, and release their fix or feature very quickly. That's invaluable and should not be impossible on mobile. [2] So, our hypothesis is that there are a class of simple mobile apps whose behavior can be described declaratively using a simple JSON format that can be hosted statically, or delivered piecemeal as needed, or even generated dynamically a la a REST API. It could describe an app UI directly, and also how it interacts with a server API, and it could be rendered using native controls. Think Web apps, but instead of a legacy stack that wasn't designed for application development, a simpler and more straightforward format uniquely suited and designed for modern Internet/Web applications, taking into consideration all of the things we've learned a modern Internet application needs. Right now we're building (and shipping) sophisticated apps that are defined by our JSON format and rendered using 100% native controls on iOS and Android. We can update that JSON at any time to change the app on next launch. We can send down new JSON via an AJAX-like mechanism. We're iterating on the format/protocol, and shipping new version of the client. We're figuring stuff out around client-side views, realtime client<->server communication, data sync in general, and many other interesting things. There are enormous problems to be solved here, both engineering-wise and in API/Protocol/Architecture design. YOU: are an interested hacker who isn't content to let people build shoddy applications on a gross legacy stack, or invest way too much time and money for things that really should be a lot easier. We're looking for someone who realizes all these pain points and isn't afraid to imagine how things should be done. Think: in 10 years, will people really be building new apps on HTML? No. Come help us design the stack of the future. Ideally, you have experience in iOS and Android, since that's our most pressing need right now and likely in the future. US: a 3-person team (two co-founders and myself) trying to modernize (mobile) application development. We run Rails/Postgres/Sidekiq on the backend for the apps we host for our users, but our clients consume JSON so that's an implementation detail. In the future people can generate that JSON using any backend they want. Our iOS application is in Ruby (via RubyMotion, which has worked well for us) and some ObjC, and our Android client is in Java. We share some code between them (like our layout engine) and we want to share more. We've taken a seed round from some great investors[3]. We're very small still, so your impact would be immense. EMAIL: jobs@usepropeller.com (I'm ben@usepropeller.com) 1: Yes, I remember Linspire. I'm using "invent" loosely here. 2: Apple doesn't let you actually ship code (or, technically speaking, an interpreter, you can ship JS) but many client-side interactions don't actually need to be re-implemented every time. HTML forms are an example: client-side interactivity without custom logic. There are many other interactions that can be abstracted this way, especially on mobile, where user interactions are more constrained, and especially for stuff that just updates the UI and can be solved using a Reactive/Data Flow approach. 3: http://techcrunch.com/2013/06/27/propeller-gets-1-25m-from-a...