Our experience has been really positive building a single platform data-driven app. We’ve been able to drastically increase the number of contributors to the codebase and with minimal guidance, web-developers are able to be productive and ship features to our iOS apps.
That said, for this 3 year anniversary, I want to dive deeper into some of the less positive aspects of our transition. We think these trade-offs are worth it, and that this may be what a successful cultural transition eventually looks like for some companies.
When adopting React Native, we de-emphasized iOS as a unique platform for Artsy.
From an engineering team’s perspective, we think of it as skill de-siloing. Prior to the move, if you were on the mobile team you only worked on the iOS apps. This meant you had a limited scope to make change at Artsy. This comes from two factors:
- Skills in Obj-C and Swift are only useful in the context of Apple’s platforms.
- Internally and externally, Artsy is considered a website first.
With time, we redistributed the native engineers across many teams, with the native Engineers effectively acting as a conduit for ensuring that we keep quality high and providing guidance to the rest of that team on how to make it feel right. A simple way to think of it, is that the native engineer’s job was to make sure we still conformed to the Apple Human Interface Guidelines to ensure the user experience is consistent with the platform and the user’s expectations.
After a year of adopting React Native, the ex-mobile team used to joke that no-one enjoyed working in the native codebase anymore. They still did. Three years down the line, with most screens now in React Native, that’s not a joke anymore.
This has consequences.
De-siloing our mobile team obviously wasn’t without its risk. In expanding the scope of our mobile engineering team, and opening up the iOS app for contributions to the rest of the company we:
- Moved the engineers with a native focus to act more like platform engineers vs product engineers.
- Had iOS native platform engineers with the skills to now also work on the web’s platform.
This is what started to make our third year tricky. In Artsy, web is the squeaky wheel.
The web-aspect of the Omakase has more client consumers (1 iOS app vs 3 large websites), and its corresponding repo has more than double the number of commits per day on average. The web team has its own people running and improving infrastructure, which affects the iOS side too.
We explicitly worked towards shared common infrastructure across all front-end at Artsy. It wasn’t surprising when the aspect with the most company focus became much larger and more complex. What creates tricky constraints are that the few people with the interest and skills to work on our React Native infrastructure also happen to have the skills to work on the web problems too.
Those web problems tend to be a lot more valuable to the business.
There’s some work that can be done to benefit both, but in the last year it has been hard to prioritise iOS-specific platform work. For example, it took almost a year to get around to upgrading our version of React Native. This is a pretty risky place to be for a platform which we care about.
At the end of 2018, we came to the conclusion that this was something we wanted to work to improve. So, we specifically brought back an explicit iOS-specific culture to Artsy - when we split our front-end practice into web and iOS.
Maybe this is a small admission of failure to the idea of a purely de-silo’d team, but realistically while product work across the two front-ends teams is consistent - the platform concerns just aren’t.
Keeping up with the Jobs’
As individual developers, it’s much less important for us to keep up to date with the latest Apple developer news. WWDCs and iOS releases just kinda happen, and we keep moving independently. We still write native code to make use of any iOS API available when we need to, but right now we don’t go out of our way to try to make use of all the shiny new things when they are released.
Without a focused iOS team, it’s not easy to pitch for iOS specific projects. This means that features like moving to Apple’s new app store review API or using iOS features which don’t exist on web get spoken about in meetings, but never started. This lack of a focused team makes it really hard to implement fixes to e.g. bad App Store reviews.
That said, in the last year we did manage to ship a pretty hefty ARKit feature - which is a positive example of an iOS-specific feature which is both forward-thinking tech and a super great fit for Artsy’s product. React Native basically played no part in that.
There are maybe four communities at play if you’re doing React Native:
- React (Relay/Styled Components)
- React Native (Mostly people creating cross-platform tools)
- Native (Obj-C/Swift/CocoaPods/fastlane etc)
It’s hard to keep on-top of any one community, and it’s very hard to keep on track of four. Realistically, if you want to be writing apps at the level of quality we want to - you need to, though.
Are these the kind of problems most teams would have? It depends, with React Native at Artsy our focus on:
- Offering a consistent way to write code across web and iOS, which doesn’t water down either platform.
- Ensuring we are able to meaningfully own our dependencies across the stacks.
Means that we took on some technical and cultural debt, specifically around the platform aspect of our native codebase. There are a few levers we can use to fix some of these issues:
- Find a way to ensure clearer engineering and product ownership for iOS at Artsy.
How and if we’ll tweak these levers will make for an interesting retrospective. Till then, I’d like to finish with a showcase of some of the React Native work we shipped over the course of the last 4 months:
We wouldn’t have been able to ship this without React Native.