Native Mobile App Development on Drupal


These are my notes from a talk given at Drupalcon Denver 2012 by Kyle Browning. You can follow Kyle on Twitter @kylebrowning. [My other notes from DrupalCon Denver]

Why/Why Not Native

Why Not: Options like Titanium support multiple devices. Developing natively may not be something that you want to do. Rapid prototyping is sometimes easier with JavaScript and Appcelerator. It's also not as hard; developing things quickly is a lot easier!

Why Native:

  • Faster performance on the device
  • Any issues will be supported by the OS maker
  • Manage errors on side of the stack
  • No waiting on API updates
  • Games work well
  • Personal preference

Development Process

The development process usually flows from idea to wireframe, design and development.

Getting the idea on paper will help with all future steps because you're not chasing a moving target. It's easier to fail at the idea or wireframe stage, and it also helps you lay out the app and understand all the types of content you will be using with Drupal. Use tools like Briefs or Omnigraffle.

During development, you'll determine which features are prerequisites for others and build the API communication. If things are constantly changing, write unit tests. Tackle the harder tasks first.


Services are a standard solution of integrating external applications with Drupal.

Servers define what you want to accept and the response types, for example "I will only accept application/json." The server will call authentication methods and executes the actual function call. You can use the standard services resources. For example, the node resource allows you to execute CRUD functionality on the node

Authentication is session-based and can work with OAuth. Using singletons for authentication is a good idea. Doing user update stuff is the only time you would update the singleton object.

The Endpoint is the URL that gets generated when you start setting all this up. It's basically a configuration object. You enable servers and resources on them, as well as what authentication methods and response formats you will accept. This is where you can do some cool things with versioning and separating developer control.

One of the problems you'll run into building this API is that you'll break something. Your app on the appstore will break because, for instance, you added a required parameter. You don't want that happening. Versioning allows your client code to request a specific version of the API.

Services Views has been in a weird, experimental state for some time, but it has been cleaned up recently. There are no issues in the issue queue. If you use Views, you can break your app by removing a field, for example. You really want to make sure it doesn't change; use something like Features (for lack of a better module.)

I highly recommend using imagecache. In Drupal 7 you don't even need to install it.

Tools and Libraries

Examples and Demo

The remainder of the talk concerned a demo, which involved a lot of UI screens that don't lend themselves well to transcription!

Did you enjoy this post? Please spread the word.