At BADCamp, Workhabit gave a talk about the ongoing work we've been doing with iOS and Drupal. At Workhabit, we've been working for some time to bring first class support to Drupal for devices like iPads, iPhones, and other Apple devices like the new iPad Mini. Our belief is that building first class native app experiences on Drupal websites is revolutionary and exciting, and something that we've been working on as a company for a very long time.
Obviously, we're bridging two very large ecosystems with Drupal and Native iOS applications, and the two communities don't really have a lot of overlap in terms of developers. However over the last year we're finding more and more interest in using our systems as Drupal continues to make inroads into large corporations and innovative companies looking for a powerful and flexible platform that they won't outgrow in six months or run out of money to support in their budgets during the first fiscal year.
Well, actually, this isn't the first thing we've built. We started with something we called DiOS, the Drupal iOS SDK. Workhabit invested heavily in Drupal, supporting Kyle Browning while he and other volunteers invested considerable attention into Drupal Services. A lot of this was just a desire to improve Web Services support in Drupal, because it's a major component of what we do here as a company. But we were also working to build the Drupal iOS SDK (Source on Github), a library that enables iOS features to natively connect to Drupal.
We had some really good reasons for wanting to go down this route. Some time back, we did an exceedingly large scale project for a major automotive company, and while we were working on it, we realized that REST kind of sucks at scale for iOS. The high latency of wireless networks, combined with gobs and gobs of users, tends to really weigh down a Drupal site with connections, and while there are architectural things you can do it fix it (proxies like Varnish, high io brokering services in threaded languages, nosql, etc., which was in fact what we did in this case), you can gain a considerable performance benefit for iOS devices by simply using the native XML that the phone uses, a little definition file called a PLIST. When you use a native iOS format from Drupal, you don't have any translation overhead converting from JSON or XML into the devices native format, making your application a little snappier to use and making your users a little happier. XML Parsing on things like phones is extremely taxing to the devices wee little cpu, so it is Apple official doctrine to use binary PLIST format for large-scale data. Oh, and of course the other major advantage of using PLIST is that it's binary data, which means that the data is actually stored in the way computers use it (as bits), and not as something that's easy for developers to read (like XML and JSON). This makes the information smaller, easier to transmit, and as I mentioned, less taxing for the iPad, iPhone, or other Apple device to consume from a horsepower perspective.
The second challenge we faced was trying to make a community (Drupal), that is increasingly focused on things like Responsive Design, Saas, CSS3 & HTML5, and other Web technologies that are coming into common practice for building mobile websites, aware of the fact that Drupal now has a fully native iOS support option. There's a huge bias to overcome (iOS vs Android, Native vs Mobile Web, etc) with developers, and in fact we've been doing mobile for years, build all our sites in responsive (unless specifically requested not to or if it just doesn't make sense... there are a few use cases left where desktop sites are better), and are advocates in general of these technologies, Android and other Mobile devices as platforms, and frameworks like Phonegap that let Web technologies build mobile apps. But that's not the point. The point is that native iOS applications powered by Drupal have a lot of unique capabilities.
The third major challenge we have had is actually the fact that people look us as like we have pancakes on our head when we start talking about this stuff. They don't understand the awesome capabilities that are unleashed when you can have Drupal working in your hand anywhere, even offline, but yet centrally managed in a secure fashion without having to build complex offline apps like Gmail.
How about this: you're the General Manager of a major non-profit or company trying to build a platform that allows you to reach a really large scale audience via the Internet. You've been tasked with figuring out how to take a budget, and turn it into a sophisticated communications platform that not only reaches customers, but meaningfully connects your fundraisers or sales folks, provides management dashboards for content to your executive and editorial teams, and works as the foundation for your marketing on Facebook, Mobile Phones, and the Web. This is the convergence problem. And it's becoming increasingly important, because the value of high quality content is increasing dramatically on the Internet, and as more and more organizations get better at working on the Web and integrating it into their businesses, getting the attention you'd like from people is increasingly competitive and difficult.
We've been working in Drupal since 2005 as a company, and several of us were working with it before that. What's kept us going in this direction for the last few years is the excitement we have for building a maturity into the platform to see it publish everywhere, and continue to put a massive hurt in the side of commercial competitors. The future of content management is going to move forward towards an integrated model, because leveraging content is difficult, and making content can be extremely expensive. So systems are going to get better and better at being able to click a button to publish everywhere really easily. They are also going to get much better at being able to click a button and publish from everywhere.
There's a lot of effort going into making the UI of Drupal much more intuitive. There's a lot of effort going into the engineering of Drupal to help it continue to mature and be easier to use for developers. And Acquia, our partner, is investing heavily in the grow-a-market strategy required to help Drupal continue to blossom. Where we've been putting our efforts is into making Drupal work natively with other ecosystems. And this product is one of the core efforts we've accomplished in our roadmap thus far.
So, back to our example. When you get to use Drupal as a definitive Master of Record to expose your data and content to every channel of your content through one system, you accomplish both the "click button, publish everywhere" and you also make it possible to "click button, publish from anywhere" because now you just have to make a few service calls and everything is at your fingertips! Make sure you get this point, because it's the key point. You can now take all of your big iron databases, Software as a Service platforms, and even complex systems like ERP and CRM, and use Drupal as the definitive front-end for them. If you're trying to build an integrated platform, Drupal can easily do it.
Nobody is impressed with stats, except for nerds like me. You need to have some kind of demo that makes people realize you're actually capable of doing what you're talking about, and to help them visualize how they might be able to use the technology and reach those important "ah-hah" moments. So, therefore, you need a demo. And the problem we've run into is that most of the work we've done around native applications has been something that clients are not particularly excited about Open Sourcing, and in fact many times don't even want other people to know was done by Workhabit. So, the first demo we did was the debug console (hey, we built it for ourselves, might as well give it away).
While it's a pretty awesome demo, it doesn't really blow people's minds with the possible applications of DiOS and iOS on Drupal. So, when we were approached to build the Drupal Enterprise Garden's application with our partner Acquia for Warner Music Group, there was a lot of excitement about it. And Moshe Wiseman at Acquia, along with others, really helped steer us towards being able to fork and Open Source this application to serve as a foundation for Drupal and iOS projects (for which we will always be eternally grateful Moshe). We were even able to get oAuth support into the application, and into Drupal Services, so now you can do oAuth easily.
This application provides the foundation for publishing into Drupal, and from a code perspective, has the following features that you can use as a model for any native iOS application:
Actually yes, even though the App is branded as Drupal Gardens, you can hook it up to any site that runs the mast module. We will be open sourcing this app when we get all of the branding out of it and well probably write a much more in depth blog post about it.
Obviously, there's a lot more to come here in the mobile space, but now that there's a great publicly available and Open Source model available, we're really excited about seeing more innovation in the space. There are so many possibilities for applications, such as something as simple as being able to do push notification to iOS devices (and yes, we've done this many times). This means that applications that deal with breaking news, sports and event, and key corporate information systems can send alerts to users about key things they're interested in hearing about in near real-time. This can easily be done with leading providers today like Urban Airship right from the Drupal Admin UI, or in automatic response to events, dates, and even data from external systems. We don't have it in this application, but it's an example of the kinds of integration that are now possible with Drupal.
We're working on much larger ideas for this Drupal iOS Integration stuff. Right now Drupal Gardens is a great example of of dynamically built forms for content creation, but we havnt even gotten to the good stuff. Imagine being able to completely define your Application in Drupal. Point the Open Mobile application at Drupal and its dynamically built based on your configured Drupal site. We think this is going to be huge for those small and medium sized businesses that just want content publishing to/from Drupal and we're really excited to get it out there. Thoughts? Feedback? We'd love to hear from you!