As the leading independent real-time advertising platform, Smaato collaborates with over 90,000 mobile publishers and app developers from all around the globe. This reach enables us to tap into the expertise and best practices of highly successful mobile developers. We interviewed one such person, Shiladitya Sircar, who’s leading mobile application development at BlackBerry. In this interview, Shiladitya shares his experience of developing a mobile messaging solution, BBM, across Android™, iOS®, Windows Phone® and BlackBerry® smartphones.
Smaato: What's your overall experience with maintaining BBM across multiple platforms?
Shiladitya: BBM is a full-stack solution for mobile communication that allows content sharing, multiple conversations with group collaboration sessions or multi-party conversations, share calendars, and share tasks lists, video and voice chat etc. When we started designing BBM about 10 years ago, we sort of invented the real-time mobile messaging space. We focused on some of the critical elements of mobile messaging -- the timeliness of messages and getting a delivery confirmation -- to create the social glue for an engaging conversation that is not face-to-face.
When we built it for BlackBerry10, we also wanted to tackle iOS, Android and Windows Phone with maximum code re-usage because mobile development is quite expensive, especially when trying to migrate native development stacks and technologies for each platform. Our main architectural assumption was that in all of the mobile platforms, there would be a base layer where most of the heavy lifting -- business logic, protocol, security, data protection, privacy -- can be preserved without any platform fragmentation.
Delivering the most secure messaging solution and preserving user rights to data and privacy is our main focus. So we implemented the base layer in BBM -- the BBM core stack -- where the messaging business logic remains in C and C++ native code. It’s a POSIX-compliant implementation where BBM’s business logic resides (network behavior, connectivity interfaces, security, and message handling, secure message persistence, etc).
Smaato: On which platforms do you create platform-specific user experiences and why?
Shiladitya: Having that layer on its own allowed us to explore platform capabilities. We were able to have the same stack running on BlackBerry 10, iOS, Android and Windows Phone with minimal changes. For Windows Phone we had to use a Win32 to POSIX compatibility abstraction. We use native NDK to build our core stack for Android and on iOS its C/C++ toolchain for libC.
We use platform-specific technologies -- Java for Android, Objective C and Cocoa for iOS, C# for Windows Phone, and QT Cascades for BlackBerry 10 -- to develop the UI workflows and interactions in a platform-native technology that users were familiar with.
BBM core stack runs as its own process and the UI technology is plumbed in over a message passing technology: it’s a JNI “event loop” on Android, an Objective C “event queue” on iOS, and a “ipc pipe” on Windows Phone. The UI binds against these message passing interfaces to develop the UI workflows without having to deal with any of the protocol or business logic. The UI is stateless entity responsible for rendering data and implementing interaction workflows.
We keep the BBM core same on all of these platforms - it works like a shared library, or a static library on iOS. Platform specific implementations are notifications (MPNS, APNS, Google push), integrations with the app stores, in-app purchase etc. These platform-specific behaviors are typically interaction-oriented, which is end user facing.
Smaato: Are all the apps presenting the same UX across platforms?
Shiladitya: When we initially launched BBM for non-BlackBerry devices about three years ago, we believed in a single visual interface making the app look the same regardless of the platform. Soon we realized that we faced an uphill task because developing custom interactions and interfaces on iOS is difficult and development costs increase if you’re not adopting the metaphors and paradigms of the platform. Besides, we got very strong feedback from the market that people are not looking for a unified interface and it adds zero value for the end user to have to learn new interaction metaphor. Within 6 months, we re-designed the UI and implemented application platform-specific UI behavior. So now if you open BBM on iOS, Android, BlackBerry, or Windows Phone devices, the behavior is exactly what the end user would expect.
Smaato: Would you like to share any specific tooling that has helped you maintain your BBM core stack with the UI applications?
Shiladitya: To answer this question, let me explain our build stack. It’s a single source base native core (or native base) that generates a library libbbm.so file. The UI code is per platform: BBM app for Android has its own UI codebase, BBM app for iOS has its own UI codebase, and so on. We have decoupled the core BBM stack’s dependency with the UI to allow portability and added benefits of general software decoupling principles.
We use Git for source repository and Jenkins to build management plus numerous set of custom homegrown tools to manage. We strive to maintain a stable bases at different points in the release for each individual components. This has allowed us to release our app simultaneously every 8 to 12 weeks. We run our beta regularly composing the build from different stages of feature maturity for our release tree. Our code review and feedback process is through Gerrit and this is mostly done to share overall design and knowledge amongst our teams.
Smaato: How do you maintain the API in between?
Shiladitya: Whenever there’s a new behavior that gets introduced, the team designs the protocols first taking compatibility and security considerations. Typically we will define our interaction sequences of message passing. This we formally define and give it a structure in a symbolic language. This then at build time generates the necessary bindings of the protocol. This eliminates the need to handwrite any marshaling code or reduce if not eliminate the chance of compatibility breakage version to version. We have developed a layer that does this and is integrated with our tooling systems.
Smaato: How do you plan your rollouts among different platforms and how do you prioritize them?
Shiladitya: For our mobile applications, we deploy platforms at the same time because, in a messaging application, things need to work consistently; if we introduce a new feature and don’t support it on Android for example, it’s a pretty bad experience. So we deploy it all together, but we cannot forecast when it will be available on iOS due to its review and approval process. So we make sure to submit the application and give it a few days, which is typical for iOS apps. Till then we hold on to the Android, BlackBerry10, and Windows deployments. Once our iOS app goes through, we approve the multi-platform deployment to make it a global rollout. For a messaging application, it’s critical that all of the features are available at the same time or else the cost of maintaining it in a fragmented way is high. So typically we try to do the submission of our iOS app earlier that other platforms. We have also found that uptake of new OS version and app upgrade cycle time on iOS quicker than other platforms.
Smaato: What tools would you recommend to a cross-platform app developer?
Shiladitya: There are lots of tools available for cross-platform development (Xamarin and PhoneGap, for example); each has its pros and cons, but won’t quite work for BBM and similar applications. Xamarin allows developers to maintain a C# codebase for their application as a single source. PhoneGap is also quite popular allowing HTML5 based application development. These types of tools are managed and implemented by a third party and isn’t a first-class citizen of the platform. It is challenging to build cross platform tools since being outside of native OS environment, API compatibility and runtime binary compatibility becomes a challenge.
Non-native platform tools are difficult to use when you want to code some custom behavior that requires access to low level interactions i.e. graphics surfaces, raw sockets, crypto etc. Not all low level access is exposed in a consistent way in all mobile OS platforms. Applications like video chats, which require low level access of the raw data streams, av codecs or graphics overlays etc. makes it difficult to do in a uniform way. So it depends on the type of application you’re developing; if it’s a relatively simple data-consumption application, where the data is in the server and you’re rendering it on some screens as workflows, perhaps Xamarin or PhoneGap is good. It’s also good for quick prototype or if you already have assets in HTMl5 or C# to cross port and bring them live quickly. But you have to be mindful of the long-term costs of maintaining a solution that doesn’t depend on a first party toolchain and the commitment to support these toolchain from their providers.
We experimented with HTML5 in favor of native application development. HTML5 has lots of promises and probably the closest thing out there that runs on all platforms relatively well. However, it’s still not as crisp, fast-rendered UI experience compared to native UI yet. Perhaps because of the overhead of it running on browser - the memory footprint is also relatively high and it can’t be directly managed at your discretion. The network resource management is also really important and only so many ways this can be optimized since controls are higher level. When you develop an applications using these toolchains, your application state and lifecycle considerations are also important. For example if it only has to stay around while in foreground then may be its ok for quick time to market needs.
These tools are great to get something to market very quickly as a prototype, or trying to secure investment, or show an early proof of concept before coding it properly later on.
Smaato: How does BBM’s backend look in contrast to mobile applications?
Shiladitya: You can think of the BBM backend as a big message dispatching system. We’re handling lots of messages every day and our latency timelines are within seconds if all endpoints are available. So in order for us to maintain such a large system, the way network resources are used is very critical. Our servers are designed to be as stateless as possible. Effectively, the routing protocol needs to be lean so that these servers can route messages efficiently. We take special consideration of security and privacy on data handling.
BBM supports many features, from group collaboration, multi-party conversations, privacy and security features, live location sharing, file and picture sharing, voice and video chat etc. We improve and enhance each of these features with every new release. We coordinate our server and client deployments to ensure we maintain backwards compatibility and security. In fact, when we launched BBM on Android and iOS few years back we didn’t require our users using older BlackBerry OS or BlackBerry 10 devices to upgrade the BBM client to be able to communicate with newer version of BBM on iOS and Android devices. We maintained full compatibility of messaging feature-by-feature across very old versions of BBM running on BlackBerry OS and BlackBerry 10 devices. This was a good accomplishment for the team.