Blog Post

You shouldn’t need a computer science degree to write a mobile app

Just like a drunk boyfriend, the web is unreliable and not always available to apps. That means that mobile app developers need to think differently about building for the mobile experience as compared to the desktop experience. And figuring out how to do that is hard for all the people out there who may want to build a mobile app without knowing how to set up Facebook authentication or manage a collection of virtual machines on Amazon Web Services.

“There’s no reason developing an app has to be something esoteric that requires a lot of knowledge,” said Kevin Lacker, the CEO of Parse, speaking at GigaOM Mobilize in San Francisco. “Someone else should be doing that boring work for you.”

Parse is that someone, and because he sees a lot of applications, Lacker also offered up a few tips for aspiring programmers to use in their apps to help with getting them picked up and keeping users involved. First, to help drive adoption of your app, or at least distribution, he recommended integrating with Facebook. He also said that to keep users coming back, implementing some sort of push notification could make sense.

If Parse or other platform plays like it are a success, then mobile development and supporting those apps could be as easy as setting up a Tumblr. Imagine what kind of world that would be.

Check out the rest of our Mobilize 2012 coverage here, and the live stream can be found here.

11 Responses to “You shouldn’t need a computer science degree to write a mobile app”

  1. One more thing, as Paresh pointed out above, internet connectivity is every reliable! Saying that it’s not is a strawman argument. The only reason you might not have an internet connectivity is 1) you’re out of your cell providers coverage zone, where in that case you won’t have cellular connectivity either, or 2) you’re getting close to exceeding your data plan limit and you deliberately turn off your data connection. Both reasonable conditions to account for in your app, but to say that data connectivity is unreliable is a canard.

  2. I’m all for simplifying redundant layers of noisome middleware, but as the old saying goes, “easy to do is easy to say”. This is basically a sales pitch. Now back to your textbooks, class.

  3. “He also said that to keep users coming back, implementing some sort of push notification could make sense.” — But I thought someone else should do the boring stuff for you?

    “..recommended integrating with Facebook.” — Have yet to hear anyone suggest steering clear of Facebook.

    “…the web is unreliable and not always available to apps.” — When 90 trillion emails are moved through the web each year, source: and 81 trillion of those are created by people who truly don’t need any type of a degree because there are platforms designed to do the boring stuff of sending 3 – 6KB content to a list of thousands one by one.

    Let’t not get into number too much, but don’t you think the internet that is in place right now is in fact reliable and always available? If the roads are closed outside due to bad weather, stay indoors until it clears up. The application that decided to end itself rather than just let the user know, “hay no network! Just check back in a minute, please”, has nothing to do with anything else but the application itself is not reliable and now not available because it has passed out like an drunk boyfriend.

    Building desktop application you had to think about network connection problems no matter who’s fault it was, and your statement suggest that desktops never really relied on the internet like mobile devices do today. Just that face there is not a RJ-45 connected to your device when you walk abouts in the world should be a good indicator that you need to think differently. Anyone who could make a phone call knew how reliable the mobile effort was going to be.

    It’s great you want to help simplify the effort to get peoples brand on the market where people spend money and time today, but you would not be in the business of developing a framework to map to many other frameworks if native content and code was not valued in the marketplace.