Hi! I'm Matta, an Engineering Manager here at Threads.

We've been building Threads across platforms (web, desktop, iOS, Android) for a few years now. Along the way, we learned some practices that did or didn't work well for us.

And while there are exceptions to these rules, they vary depending on your team and priorities (but hey, they work well for us at Threads)! Here are a few of the do's and don't of building apps across platforms...

 Don’t… build different platform clients at the same time

We build a feature on Web first, then one mobile platform, and finally the other mobile platform.

We start with Web, since it's quickest to iterate. At Threads, the engineer that builds the backend also builds the web frontend for the feature.

During this pass, we establish our API contract and expose most of the edge cases.

Once that’s done, we bring the feature to a single mobile platform. We focus on how the feature’s experience differs in a mobile context. That can usually happen without major API changes.

Finally, we build the feature on another mobile platform. By this point, we have confidence in the API and mobile experience, so developing the feature takes a lot less time and iteration.

 Do… share the same API endpoints

It’s tempting to split API endpoints for minor differences between platforms. In our experience, more often than not, every client can use the same data structure and content, with minor UI changes to better suit each platform.

When we use the same API across platforms, we avoid issues where customers see different content when they’re at their laptop vs. on their phone. Bug fixes get applied to all clients at once.

Trust us — your future self will thank you for using the same API endpoints!

 Don't... mirror all functionality across platforms

Our customers don’t need (or want) to do every action on every platform. For example, they don’t need to modify their organization’s share link settings from their mobile app. They only need that on Web.

Even if we had the resources and time to build a feature on every platform, every additional feature comes at a cost. It takes up screen space, and it adds complexity to the app.

You can often find ways to break down features into smaller portions that leverage each platform's strengths. For example, our Today view list on mobile doesn't have to show action buttons as we do on web and we can instead let you swipe the items to quickly mark them as done.

 Do… use tools to narrow down which platform is causing a bug

When a customer hits a bug, it’s often hard to know if it’s a frontend issue or a backend issue, or if it’s affecting all platforms or just one. We've built an arsenal of tools to quickly answer these questions.

If content in the app looks incorrect, we use our API endpoint tester that can check whether the response is malformed and whether it’s being interpreted incorrectly.

If a customer reports a sluggish client, we check our Backend and Client performance dashboards to debug what's causing the slowdown: slow APIs or frozen app frames.

If multiple customers are reporting an issue, we query our logs and error reports by platform to detect how widespread an issue is.

 Don't... overcomplicate your client code. The simpler the better!

It’s easy to have clients do a lot more than they need to. Resist that urge!

For example, when we’re first building a feature, it’s often fastest to iterate on client code, since we don’t know exactly what an API should return yet. However, if we duplicate that logic across all clients, we end up implementing the same thing multiple times, which leads to inconsistencies, edge cases, and just extra work.

When we push logic like sorting, grouping, and paginating data to the backend, our clients will show consistent information. Client code is simpler to trace and debug. When we fix an issue, the fix gets applied across all clients.

We encourage simple clients through culture and process changes.

For example, a part of code reviews is to check that clients are not doing more than they should. When we’re building a feature for mobile, a full-stack engineer and mobile engineer pair to simplify client logic and push more of it into the API.