Making Meetup

Making Meetup’s Apps @ Mobile Week NYC

Last week I was fortunate enough to give the keynote at Mobile Week NYC.  It was entitled “It’s Time! What to do When Rebuilding Your App?” and is a case study in how Meetup made the exciting (and difficult) decision to rebuild and redesign our apps. 

The keynote meant to answer the big question: “Once teams are spun up and start working on a project like this, then what?”  Here are a few of the key Android and iOS engineering topics I covered in my talk.

iOS

One of the biggest decisions we had to make around rebuilding our apps was with our iOS app.  Some background on our iOS app is that it was originally built in a 3 month extended hackathon type project back in 2009 by two engineers that did an awesome job getting an MVP shipped. The problem was, it was never re-written over the course of 6 years, accumulating a lot of technical debt. We knew the code wasn’t of the quality we wanted and our test coverage was way too low for our current standards.  

Also, much of the institutional knowledge from those who had built the app over 6 years was gone, so we hired — in our opinion — the best mobile engineering shop in NYC — Lickability — to do an in-depth analysis of our codebase. Their output was a spreadsheet of every class in the app (almost 500 classes!), a recommendation as to whether or not the class was salvageable, and metrics around the test coverage.

Following such a detailed assessment, we had the data to know that we needed to re-write almost our entire model code. Naturally, in a redesign you have to rewrite the view/UI code as well, so it was a clear decision for us that in order to futurize Meetup, investing more time in a new codebase that met our quality and testing standards was the right decision for us.  Futurize is one of our company values and means: “ We like shipping, but we like investing to ship faster in the future even more.”

After making that decision in 2015, it seemed obvious to us that if we’re going to rebuild our app, Swift was the only way to go. Among many other reasons we love Swift, we especially love that it is statically typed so is type safe just like the rest of our Scala/JVM stack.

Once the decision was made to rebuild our iOS app from scratch, the next key decision we had to make was Swift 1 or 2, because Swift 2 was still in beta. We decided on Swift 2 because it both compiles and runs faster, is a great boost to our team’s morale to be able to start off working with and contributing to a the latest open source iOS language, and we saw it as a great way to attract people who wanted to make Meetup now using the future of iOS.

The second decision we made was supporting iOS 9 and above for minimum version support in the new app. We had a lot of data that showed how quickly our member base would upgrade to iOS 9 and how few members would be left on iOS 8. We didn’t like that we’d leave any member behind. But, not only did the data support it, but our engineering assessment was that building for iOS 9 and above would significantly reduce the amount of code we’d need to write — freeing us up to build and ship other features faster.  Specifically, supporting iOS 9 allowed us to use the new UIStackView class, providing an easy interface for laying out a collection of views and leveraging Auto Layout for creating UIs that adapt to the device’s screen size and orientation.

Android

The decision making process around building our Android app was very different. The foundation of our Android app was much better, the code quality and test coverage was much higher, and the lead engineer working on the app had already been working on it for several years.  

We had the institutional knowledge in house to do an assessment of the codebase and determined that we’d have to refactor and re-write significant things, but that there were parts that would serve us well in the future.  During our assessment we identified key areas we needed to address and this is how we handled them.

The biggest change we made was to go all in using RxJava for reactive programming in Android. It really helps us get concurrency under control with little effort because it abstracts everything to far fewer lines of code. This was a big deal for us because we’re loading so much data from the network using multiple API calls and our API has to support many different clients at once (Android, iOS app, Apple Watch, Web). So, it’s hard for the API to always return data to a client app in a single call that’s exactly the way each client app needs it every time.

Our Android team absolutely loves RxJava because they know that they can composite multiple calls on the client (meaning they can easily wait for both to complete, then do something in the app) in just few lines of code. They can do this without adding additional complexity (for example, composing Futures) or having to manage things like if a user tapped away from the screen.  It’s been the biggest improvement for us in the new app architecture.

We’ve also loved using OKHTTP from Square as our HTTP client. It helps us load data from the API into the app faster, save bandwidth usage, and really make our app more responsive – it just feels and works awesomely fast.  

We use Jackson for data processing and agree with the Jackson Project page that says it’s “the best data processor for Java”. It supports every format you’d want with streaming parsing and data-binding.

Last, but not least, Guava is a set of core libraries from Google that really helped us handle a broad range of things like collections, caching, I/O, and has really reduced the amount of code we’ve needed to write ourselves.

Thanks!

Mobile Week NYC was a great experience and there were a lot of interesting talks there. Thanks to the conference organizers for inviting me to speak and to everyone who attended and participated!  I learned a lot and met many passionate, smart people doing great things in mobile.