Interview with Beepeers, social apps provider

As part of  the HTML5Apps project work, the team is trying to gain a more detailed understanding of the barriers that developers from European SMEs encounter, and what the subsequent reasons make them avoid or prevent them from developing mobile apps using Web technologies.

In addition to participating at developer events and interacting via social media, we are also conducting a few one-to-one interviews with developers with the goal to dive in more details in some of these barriers.

The first of these interviews was conducted in June 2015, with Fabrice Castellon and Alain Prette, the co-founders and leaders of Beepeers, an SME based in the South of France, specialized in the development and publishing of social applications.

Hello guys, can you tell us more about your company and its business at a high level?

Beepeers was founded 3 years ago in Sophia-Antipolis in France. We provide a platform for building and publishing white-label social network applications, typically used inside enterprises, or for specific events. We aim at enabling widespread use of mobile technologies for a social usage, thanks to a brand-new line of social apps, available on-demand.

Our customers include radio and media companies, some local administrations and event organizers. We have focused on a product-based approach: our customers trust us to build a response to their specific needs, rather than seeking an all-encompassing (but likely ill-fitting) solution.

What platforms does your development target? How much relies on native technologies vs Web-based ones?

Our two main targets for mobile devices are the iPhone and Android-based phones; we can also support Windows phones and have deployed applications targeted at the iPad devices. Early in the life of our company, we experimented with using HTML5 technologies to deliver our services on mobile as we were receptive to the idea it could help us reduce our development costs. But in the end, we made the decision to only focus on native.

Could you elaborate on the reasons that made you move away from the Web technology stack?

There were multiple reasons behind that decision:

• Some of our customers had a negative experience with the UX quality of HTML5-based development on mobile, and were thus not very open to that solution;
• We also ourselves came to the conclusion that native had a better return on investment when it came to building the most fitting user experience on a given device; building the equivalent with HTML5 required a lot of efforts, with non-trivial maintenance costs;
• While there is a cost in maintaining our code base across these different platforms, the expertise we have in building these specific solutions is an added value of the service we provide to our customers; each platform comes with its own UX language (navigation patterns, sharing actions), and being able to stick to that language has proven not only useful in building good UX, but is also proving a good source of inspiration for further evolutions;
• Presence on application stores remains a critical part of the marketing and communication needs for our customers; that is where many of their users will end up looking for the app they seek to provide;
• Although our apps don’t have ads per se, they need to show sponsorship inserts, and we found that it is much easier to integrate those in the native UX flow;
• Some of our features require a reliable offline system (e.g. downloaded tickets for an event), which is a much more simple story in native;
• Likewise, the ability to use push notifications is a critical piece to get users engaged, especially for event apps, where they let us build momentum ahead of the actual event;
• In most cases, the users of our apps sign in via a separate existing social network (e.g. Facebook, Twitter, LinkedIn) — it saves them the need to create and manage a new account. The workflow to integrate smoothly with these 3rd-parties is much better done with native technologies.

Is there any role for Web technologies in your product?

Yes. There are still some pieces where we are using Web technologies as fitting some of our requirements, even though most of the pieces exposed to end user by our apps are built using native technologies. For example:

• For integration with third-party services (e.g. ticketing): HTML5 gives the right interoperability we need to display interactive content from other parties; but we keep the interactions to a very limited subset (e.g. no navigation);
• The CMS that our customers use to publish their content to their users is Web-based, and is used to aggregate and broadcast content from other Web sources (e.g. other social networks, RSS feeds); but the content so gathered is transformed before being displayed in our apps, it’s not served as-is;
• In some of our apps, we integrate a Web view that lets users see linked content while remaining in the app.

So, in summary, you don’t see the Web playing any additional role on mobile for your company?

Actually, we have started very recently re-investing in a Web-based mobile solution for some of our customers. First, today, you cannot afford to provide a Web service that is not also mobile friendly, and in most cases we have already been providing a Web equivalent to our mobile apps. Since getting Web content mobile friendly is costly no matter what, it makes sense to get this mobile-friendly Web site to bring an alternative experience to our native apps.Second, and more importantly, we have started to invest in pure client-side applications (based on the Angular.js framework), and we are seeing very good results out it with some or our customers. In particular, it has enabled our more advanced customers to have more control on the service they provide to the users, since they can easily customize the templates through which their content is displayed. Compared to a traditional server-based approach, we have found the client-based approach to represent a much more reduced investment, and this is making us look again at our return-on-investment analysis. It is not our priority development, but we do see it as a promising direction to explore.Native apps also come with their own costs: getting an app reviewed and accepted create delays and risks, and while managing it participates to the service we provide to our customers, having a Web presence allows for a quicker turn around. But overall, in our opinion, it is not a matter of native winning over native or vice versa: it is a matter of providing the right UX to our customers users.

What are the main features you would like to see coming to the Web to improve your Web-based product?

Push notifications is the number one feature we’re interested in! It is great to see them coming to the browser, and we plan on investigating that possibility. Likewise, support for offline operations via ServiceWorker is promising. Being able to store tickets off-line, and to synchronize data with our servers in the background would help a lot!For ticketing, one specificity is that what we need some level of guarantees that the stored content cannot be tampered with, even by the users themselves.In our native apps, we have used interactions with iBeacon to facilitate integration with local marketing, and that is not available on the Web today.As alluded previously, being able to integrate smoothly with social connectors is also very important for us. Overall, having a very responsive user interface, with immediate reactivity is critical to building the kind of UX our customers want.For any new feature, of course, we will need to evaluate their impact on the user experience; for instance, find out if “permissions requests” are not too intrusive.

Thanks, great input! A number of these features are already under development in W3C, and we’ll look into what it takes to get the others started as well!