Developing for multiple platforms makes you and your product better

I often receive emails from recruiters looking to to fill an iOS or Android engineering role, but they are never looking to fill a role that covers both platforms. This has always been very baffling to me. As users bounce back and forth between devices, it’s important to provide them with a consistent experience across all platforms. Hiring for a specific platform pigeonholes the developer into only working on half (or less) of your product. In order to have true consistency across all products, does it not make more sense to have the same people work on the same features, regardless of where they are? This is the strategy we strive for, and I’ve fought to keep, at Runkeeper.

There are certainly reasons why you’d want a lead developer on a platform. Lead developers can teach new engineers these technologies. It’s someone who has a deep understanding and passion for a platform. On top of that, this person strives to spread their deep platform knowledge throughout the organization. This is absolutely a necessary role within the organization. However, it only needs to be filled by one or two people. Are all recruiters looking for these one or two people? I don’t think that’s the case. It seems that companies view developers as one trick ponies. They are looking to hire for a specific part of a project. When you do this is that you end up with two different apps. This may or may not appear at the UI level but will definitely appear in the code base. Yes, each OS has its own unique characteristics but the principles are the same.

So, what can go wrong if developers go in a different direction on a problem? Well, let’s say you are building a social feed. The Android team decides to preload the feed data by making a request to the web server on app launch. The backend team implements the servers to handle high levels of traffic during peak hours but will disable unnecessary servers during non peak hours to reduce costs. The iOS team decides to utilize background fetch. That causes data to be loaded throughout the day. This reduces the high levels of traffic during peak hours and distributes them throughout the day. However, now servers can’t be turned off because a medium amount is always needed. From the each team’s perspective these are both valid approaches. However, they have very different implications for the backend. Your backend has to be able to support a ton of request during your peak hours (Android), as well as medium levels of traffic throughout the day (iOS). If you have the same developers work on both platforms they will implement the feature the same way.

Could great communication, project planning and software architecture solve this problem? Yes. Are months of project planning and software architecture part of the Agile process? Typically, no. Are startups good at making big project plans? No. At Runkeeper, we solve this problem by training our engineers to be full stack. Our typical feature cycle involves:

1. Ideation (PM)
2. User testing (UX/UI)
3. Testing iterations on subsets of our user base on a single platform (Dev/Data)
4. MVP on a single platform, platform A
5. Iterate on platform A until we feel like is in a good place
6. Building MVP plus learnings from step 5 on platform B
7. Go back and clean up A with learnings from both A & B
8. Continue to monitor and iterate as needed

What does this mean? It means we vet all of our ideas on the first platform, typically . We struggle through the best way to make network calls, to implement the UI. We test what works. We learn what doesn’t. Code ourselves into holes, tunnel our way out. Ship it. After all this we look back and the code base and think, “AHHHH, I wish I could do that a bit different.” Guess what? You can! So we pick ourselves up, gather learnings from Android and implement the MVP+ on iOS with these learnings in mind. The second time you work on the project it’s always much faster and smoother. You really understand the feature and what you are doing. You can then take all these learnings (having shipped the feature twice) back the original platform so that you have a tight, consistent experience.

Our dev teams love this. It provides them with a deep understanding of how features in the app work. It makes the technology stack and UI consistent across both platforms. Perhaps most importantly, it means by the time I can’t stand merging an Xcode project file one more time, I get to move onto Android Studio.

OK, so I explained a lot of reasons why it’s good for the company and for the product, but why is it good for me, the developer? That’s easy.

1. It broadens my skill set
2. Makes my highly sought after for other projects
3. Allows me to clear my head and frustrations of one platform for a period of time
4. Easily able to keep up with the latest coding trends
5. I’m not tied solely to the success of either Google or Apple
6. It’s fun!

Let’s touch on a couple of those. For me #4 is the most important. I’m certainly a more skilled iOS developer than Android but I love to hear about how Android is becoming easier to develop for. For years threading on Android was a disaster. The code was ugly and confusing to read. By being forced to keep in touch with the going ons of both platforms I started listening to Fragmented. Listening to this, I was able to grasp the high level concepts of RXJava during my commute. The concepts introduced by RXJava and built for Android via RXAndroid blew me away. The sky was the limit. However, reactive programing isn’t an easy concept to grasp. There were quite a few times that a few of us stayed in the office after hours trying to understand why our flatMap wasn’t working correctly. Learning new techniques and tricks often isn’t mastered quickly. But by focusing on a single platform for the duration of a feature, the team is allotted enough time to master these new techniques and be ready to use them again the next time they are on that platform.

Moving back to iOS, we didn’t have RXJava at our disposal (however RXCocoa does exist). But we had a good sense for how the feature would work and what our process for multithreading would be. We were able to accomplish this through GCD and built the feature in half the time it took on Android.

For me, not having my skill set tied to the future of Apple or Google is also important. If you watched the State of the Union you saw Obama say that workers in today’s workforce know that their skills are going to have to change throughout their career. Get ahead of that trend right now. Become skilled in many areas. Will Google win the platform wars or will Apple? Either way, there’s no need to bet your skill set and career on just one. Learn both! They are similar.

Being a mobile developer is fun. We have the ability to ship code that ends up in millions of people’s pockets in a short period of time. The ability to work on both platforms is enjoyable for the developer and helps the company ship a consistent product. This strategy seems to be one of the special things about Runkeeper and makes it impossible for me to imagine working at a place with a different philosophy.