Quick turnaround time and portability between containers is a major selling point for many development shops. Having a complete application process that consists of taking a new container platform, slapping in an iframe that points to the developer servers, and loading a Flash movie can seem like a great advantage during development, but this type of development practice has some serious ramifications in the social realm.

As mentioned previously, many social networking containers impose limits, sometimes including Flash and JavaScript restrictions, on the content that is served from the small views of an application. For a developer who has embedded his application’s sole content in Flash, this means that his small view is often a glorified ad trying to forward the user on to the large view or developer site, or it’ll end up having little relevance to the actual application. It certainly won’t provide similar functionality to the large view.

Next, let’s explore the social features. Portability is not the only aspect that you should consider when developing an application for cross-container functionality. All too often, Flash-based applications silo themselves from the container’s root social features, including activity hooks to push out updates to users, friendship graphs to promote application growth, or even simple messaging systems to drive additional traffic and installs. Such applications usually have a very shallow user following. They have a high turnover and eventually fizzle as new user growth areas become harder to find. Without social hooks and relevant views, the application does not go far enough to keep users engaged.

Cross-container development should mean that developers spend time building an abstraction layer that sits between the container and an application. This allows the developer to build a single, highly social application and then just plug in the social and data hooks of any new container that is integrated into the architecture.