Tomorrow, I’ll be presenting a webinar called 5 Ways to Get Top Mobile App Developer Talent for Your Open APIs. Preparing for this webinar got me thinking about different types of mobile app and how they relate to APIs. One thing that occurred to me was how loosely the term “hybrid mobile app” is used – I’ve seen it used to define two very different types of app.

1. Hybrid HTML5/Native Mobile Apps
The term “hybrid mobile app” is often employed to describe an app that is created using a WORA (write once run anywhere) framework like PhoneGap or Appcelerator. These frameworks basically make it simple for developers to generate mobile apps using HTML5, Javascript and CSS.

In the case of Phonegap this app will essentially be a “wrapped” Web site. For PhoneGap apps, developers will often use a UI framework as well, such as JQuery Mobile or Sencha. These UI frameworks look “good enough” on mobile devices, although they should not be confused with the true native UI controls of iOS, Android etc.

In the case of Appcelerator, the generated app can actually leverage the true native sliders, scrollers, date pickers etc. of the device OS. The limitation to this approach is that a developer is fully locked in to what Appcelerator provides. Currently it offers builds for native iOS and Android as well as an HTML5 build, which could potentially be run through PhoneGap.

2. Hybrid API-Driven/Thin-Client Mobile Apps
The term is also used to describe apps that are installed on and run entirely on the mobile device – similar to how a totally native, offline game or other app might work – but which rely on a data connection for presenting Web-based resources, enterprise application functionality or other information assets.

Of course, these information assets are made accessible to the apps via APIs, which is where Layer 7 comes into the equation. In tomorrow’s webinar, I’ll be mainly focused on hybrid mobile apps that are powered by APIs and discussing aspects that are important to address when developing an HTML5 hybrid native app that is also a hybrid API-driven native app. Click here if you want to find out more about the webinar or if you’d like to register.

When a mobile app is dependent upon APIs, many new challenges are introduced to the developer. To provide the best possible user experience (UX), a mobile app should be snappy and responsive. Often though, in the reality of cell phone networks that are bottlenecked and over capacity, a dependence on a fast data connection can lead to a UX nightmare.

Tomorrow (that’s Friday November 9) at 10:30am, I’ll be discussing the challenges of mobile app UX at QCon in San Francisco. In a presentation called “HTML5 Cross-Platform Mobile Apps Integrating APIs”, I’ll be outlining significant challenges around API-driven mobile apps, as well as mistakes developers commonly make, and suggesting best practices for addressing them.

I hope you can make, if you’re at the show. Also, be sure to visit Layer 7 at booth #11.

Sometimes design concepts are obvious. We know they are implicitly understood and don’t require drawn-out explanations. But sometimes these implicitly-understood concepts aren’t executed in real life because they haven’t been explicitly defined. I’ve come to the realization that designing APIs with the developer in mind is one of those ideas that often has an audience nodding their heads but which only a few take to heart and apply to their API architectures.

We in the API design world have a great opportunity to learn from our brethren in the product design world. The user-centered design approach for products has paid great dividends for those who can understand and apply the idea to their interfaces. The goal is almost stupid in simplicity – design products that your users will enjoy. But, as always, the challenge is in translating a simple concept into real strategies, methodologies and practices that do not lose that fundamental goal while staying applicable to unique marketplaces.

In our world of API design, most of us understand that machine-to-machine integration still involves a human – the developer who develops the client code. That developer – the one who makes or breaks us by deciding to use an API – is our user. While product designers talk about improving user experience, we talk about improving the developer experience.

But how does this actually happen? What do we specifically need to do in order to create APIs that are enjoyable to use? Indeed, what does enjoyable even mean in this context? This developer/API publisher relationship is a unique one and the product-based, user-centered design and human/computer interaction models cannot just be airlifted in. They need to be massaged and transformed so they are applicable to the Web API world, without losing the potential value inherent in a user-focused design.

I hope to explore these ideas over the coming months and come up with recommendations for how we can build API solutions that deliver on the promise of improved developer experience (or DX). I’ll dive deeper into the world of user-centered design and discuss methods for translating these concepts from the world of product design into our API design domain.

Layer 7 recently partnered with the folks at AT&T, to be a frequent sponsor on their hackathon circuit. AT&T hackathons provide a launching pad for developers to come solve big problems, learn about APIs, get inspired, win prizes and possibly launch new products. Take a look at the Layer 7 site for information on upcoming hackathons and join us if you can! In the meantime, here’s an overview of some recent AT&T events we participated in.

Mobile App Hackathon, Denver, CO (August 17-18). Layer 7 brought payment APIs that gave developers tools for integrating payments into apps and we were onsite providing technical support for iOS, Android and HTML5. Layer 7 also provided Apple TVs as prizes for the team that achieved the best technical integration of our customer API. The winning app was Open Perks, designed to make redeeming digital coupons and loyalty rewards easier.

Social Good Mobile App Hackathon, New York, NY (September 25-26). Apps built over the course of this weekend aimed to solve major social issues – for example, by alerting people when blood donation banks need their certain blood type or by improving support systems for alcoholics. We were there to offer onsite technical assistance and help teams with user experience/user interface design as well as general prototyping best practices.

Hack Across the Pond Mobile App Hackathon, London, UK (October 5-7). This hackathon – produced in partnership with the MIT Sloan Business Club and the UK Trade & Investment Agency – aimed to bring together developers in Boston and London. Utilizing simulcast video streaming, developers worked together on projects at both sites. We were onsite in London, providing organizational and technical assistance.

New York City Mayor Bloomberg’s Truancy Task Force & NYC Digital Hackathon, New York, NY (Oct 12-13). Onsite at AT&T’s downtown NYC office, we were again honored to be included in a prestigious group of sponsors. We gave a presentation on How APIs are Changing the World and it was a pleasure to work with and provide technical support to members of New York’s thriving, innovative developer community.

Simple answer: no. But if you’re a developer building the next great consumer app in a hurry, it probably won’t hurt. MBaaS (“mobile backend as a service”) solves some pretty prickly problems for the start-up developer. MBaaS offerings like Appcelerator, CloudMine, FeedHenry and StackMob deliver the basic components for storage, messaging, notification, user management and so forth that mobile developers need, making it easy for developers to set up and operate the backend for their applications.

But let’s say you’re not a bad-ass consumer app developer. Imagine you’re a mild-mannered enterprise dev looking to make a solid app for your field sales organization. What does MBaaS do for you? Maybe the right question is what does MBaaS not do for you? Answer: it doesn’t get you access to the one thing you need as an enterprise developer – enterprise data.

Enterprise apps need data like plants need sunlight. It could be customer records, documentation, pricing information, inventory levels or a myriad other things. But that data is stuck in the enterprise, inside of SAP this and SharePoint that and database the other. No amount of simplifying interactions with AWS will get that information into your hands to build the super-compelling apps employees need access to.

Enter mobile middleware like Layer 7’s SecureSpan Mobile Access Gateway. Getting the stuff that’s locked inside the enterprise into the hands of devs is a middleware problem. It’s about information sharing. It’s about opening up but in a very targeted manner. MBaaS has some great ideas for making a mobile developer’s life easier. Enterprise devs want the same benefits but with the added benefit of access to enterprise data. I joined Layer 7 from a prior gig at RIM to help that happen. Stay tuned for details.