Posts from January 2017

For products that are delivered on the Web, iOS and Android, there have been myriad approaches to reducing development time and the duplication of work. Sharing code between major platforms has in some ways felt like the search for the holy grail – hope remains, but as of today, has yet to be found. As long as there have been multiple platforms, there has been a desire to write once, deploy everywhere. Developers are obsessed with efficiency by nature and nothing feels more inefficient than developing the same thing twice. In this post we look at accelerating cross platform development by harnessing serverless microservices. Based on our own experiment with AWS Lambda, we will cover the motivations, benefits, and drawbacks as well as continuous integration and delivery of this approach.

Strategies for sharing tried in the past

Leading up to today, we’ve spent time researching, prototyping and building cross platform, shared source solutions using a variety of approaches.

Way back, we started off by sharing Web views. In many cases, they lacked responsiveness parity with native views, and so were perceived as a degradation in user experience. The code was often difficult to maintain, and the Web view didn’t offer integration with native OS capabilities. They worked for single views or sub-views, but they often weren’t a solution for an entire app. Our core Hootsuite app, as of today, still has some of these embedded Web views.

Next we built using Cordova/Phonegap, which essentially wraps a Web view and enables us to have access to the most popular OS capabilities such as camera and Bluetooth. Over time, with smart optimizations, we could almost achieve native performance but we had to put in the work. Some of the apps Hootsuite has in the market right now are built this way.

We prototyped with React Native, which produces native interfaces orchestrated by Javascript. We ended up spending a lot of time on interface layouts and troubleshooting performance problems having to do with limited threads. In the end, we could get a result which was indiscernible from purely Native but it involved hair pulling and riding the bleeding edge of the open source project. It didn’t feel natural, or safe, and we felt like we were swimming upstream. We ended up shelving our React Native experiments without releasing them to the public.

We looked at using Xamarin, to write once and deploy to both iOS and Android, but we didn’t get the benefits of leveraging our large Web team or our existing iOS and Android teams. C# as a language alternative to Obj-C or Java is reasonably attractive but as a platform it felt optimized towards a completely shared user experience rather than one optimized to feel right for both Android and iOS users. Other than keeping up with latest developments, we didn’t invest in any substantive way in the Xamarin approach.

Lessons learned, the bar moving forward

After a huge amount of effort, some successful deliveries, and also a waste bin full of prototypes, what had we learned? Read More …

Every week, our product development team comes together at an all hands. Part of this meeting is dedicated to internal demos for work that has recently rolled to production. If you’re wondering what it is like to work with us, here’s another glimpse into our culture.

In this demo, our mobile team shares our product, design and development considerations for a new feature called Query Builder.