Expo

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Transcript

I’ve got some closed source and open source royalty here in front of me, Charlie Cheever who has founded both Quora and Expo, two pretty large and successful projects in their own right. Welcome, Charlie.

Thanks so much for having me. It’s fun to be here.

{{divider}}‍

For those readers who don’t know what either of those projects and businesses is, do you want to give us a little bit of a rundown of how you started in technology and where you find yourself now?

When I was a little kid, I wanted to make video games because I love playing those with my neighbors. I saw a book at the library about how to make your computer games. The first page of it says, “You need to know how to program in BASIC to use this book.” I went and got a book on programming BASIC and start typing those programs into the computer at school. Eventually, I learned how to program mostly on TI-85 calculators.

Later on, I attended Computer Science in college. After college, I got a job at Amazon. I worked as a programmer doing early big data stuff that probably makes it sound sexier than it was. It was mostly writing Perl scripts to count how many packages were going to be late. Eventually, I got convinced to go work at Facebook when it was still a college site because I had been a teaching assistant for some of the people who worked there in college.

I worked at Facebook for four years. I worked on a whole bunch of different things. Probably the most important ones where I was one of the first people to work on Facebook videos where you could upload videos. That’s become a pretty big thing now, and also the login with Facebook and the platform thing where there were games like Farmville, etc. which some people remember fondly and some people remember as an unpleasant interlude. After that, I left to start Quora with another guy. It was a question and answer website. The idea there was there’s all this knowledge locked up in people’s heads.

When you looked around and saw there’s LinkedIn for uploading your resume, there’s Yelp for uploading restaurant reviews. There’s YouTube for uploading video clips. Where’s the place where you can upload everything that you’ve learned and everything you know about in your life, whether you’re an expert on insects, programming, rocketry, immigration or whatever it is that you know about? We worked on that for almost four years. One of the things I did there was I saw everyone using their phones all the time.

We started building a website in 2009 and released it publicly in 2010. When we first launched the website publicly, the people liked it a lot and we were able to raise as much money, win some awards and get popular pretty quickly. We had a funny thing inside the company that was totally serious. If we had started working on it 6 months or 9 months later, it would have been pretty obvious that the thing that we should have been building was a new iPhone app because that was where all the opportunity and exciting unplowed earth was. We decided that we should build an iPhone app for this thing and we had a pretty decent mobile website.

I decided that what we would do was wrap our mobile website inside of a native tab bar. Basically, the product would be the mobile website and we would have this native tab bar wrapping it. I thought that would take a couple of weeks based on my experience doing web programming and things like that. We assigned some people who’ve done good, quite fast quality work on it on other parts of our product before. It took them nine months to get a V1 into the app store. That was shocking to me that it took that long when it felt like what we’d done was extraordinarily simple but it went pretty well.

People liked it. Probably the first month, it was 11% of the traffic to the service, then 12% the next one and 13%. Lots of people asked for an Android app, so we started working on that pretty soon after. I thought, “We’ve already solved these problems on how do you get a WebView to communicate with native code around it, solve the design problems of mapping navigation from instead of a URL bar to four different stacks based on the four tabs and design problems like that.”

Since we’d already figured all this out, I thought, “This will only be a couple of weeks,” but it turns out Android is more fragmented and gnarly in a bunch of ways. It’s a bit better now, but then that was particularly true. It took ten months to get this Android app into the Play Store. Even after all that, we had this problem where we had to have a small iOS and Android team that had to stay in sync.

Even though we wanted to have the exact same product across both those devices and pretty much the same product on the mobile website, we ended up with two additional teams to our web team that had to stay in sync via communicating with the designer, product manager and couldn’t move independently that easily.

There are lots of things that were frustrating and annoying about this full setup. Layered on top of all that, even though we had all these problems, we had tried to avoid them by using the web to render everything, to begin with, to try to maximize code reuse and make our programming as simple as possible. We weren’t even getting that. We still had to have a bunch of separate iOS and Android people taught and worked. At the same time, we also didn’t have the gestures, animations, look and feel that people want from a native app, so that was too bad.

It didn’t matter too much in the case of Core, because so much of the content there is mostly text with an image here and there that’s fairly static. It’s not a terrible experience overall, but in general, talking to people working in other startups, sometimes they would try to build one version in native and one version in some web rendered thing so that they can move quickly.

Over and over again, different people found that users qualitatively report liking the native version better and also quantitatively their retention statistics and all those metrics would be better when they were using the advanced. After I left Quora, the only thing I could think of that would be interesting to make was mobile-first. This is very recent. If you think about everything that’s changed our consumer technology world in terms of software over the last ten years, there are no websites. It’s all apps.

Think about TikTok, Clubhouse, DoorDash, Uber, Snapchat and all these things. They’re very much like apps and not just websites. Every idea had was I could build this app, but I knew that it was so hard and so time-consuming to build an app that worked across iOS and Android. If you wanted to add a lot of complexity to your app, it would take a long time. If you look at the landscape of mobile software, there’s an interesting thing that’s happened where a lot of the things that were successful early were things like WhatsApp, which even to this day is probably like four screens or something like that. It’s mostly a couple of rectangles of text.

Twitter originally started as a website, but very quickly the mobile app became the prompt number one way to access it. Now, it’s a bit more but mostly an app that’s about four screens with one content. You can imagine it wasn’t super complicated to build those as native apps. Over time, all of the opportunities for super simple and most basic apps have been taken. Instagram came out and then there isn’t room for another person to make a photo-sharing app that’s like a feed of photos.

The need started to arise around this point in time in 2012 and 2013, where if you wanted to build something that was successful or interesting, you needed some new way to build stuff where you could build an app with complexity and would work across iOS and Android but give you the animations, gestures, look and the feeling that you want it. I took a bunch of time off and was thinking about this. I eventually got my friend James Ide to quit his job at Facebook and start researching this with me.

We started looking into stuff. We spent a bunch of months trying to push HTML5 to the limit. We’re trying all kinds of techniques to see if we could get stuff to feel better than anything else I’ve ever felt before. We pretty much came to the conclusion that if you weren’t on the Safari or Chrome teams, there’s not much you could do. There’s a hard limit on how good you could make the experience.

{{divider}}‍

I was running an agency at the time and I always found it surprising how bad the experience of web apps was. It was like they were astonishingly bad and hard to write for, which is before the app store. That was Apple’s intention. Although I don’t know if that was ever their long-term intention. For those of you that don’t remember or didn’t have to work in that, it was a nightmare. It’s awful.

There was a little bit of at the time like a siren song where the idea of writing something once using technology that you were familiar with and having it work on every different device and being easier and faster was amazing. A lot of people tried it and even Facebook famously invested a bunch in making their apps with this issue of five approaches. They found that users didn’t respond to it well. There was a big announcement from Mark Zuckerberg that it was the worst mistake the company had ever made, he made or something like that. Looking back on it, there’s a couple of reasons for that.

One is the hardware profile of desktop and phone is a little bit different. Now, phones are pretty fast. In fact, in a lot of cases, faster than computers, but for a long time, that wasn’t true. It was hard and took a lot of work to get them to be as fast as they are and to make it all the most power-efficient. That was part of the problem.

Another part of the problem was that when you’re using a phone, you’re touching the screen and feel like you’re touching objects on the screen. If you’re dragging them around, you expect the latency to be super low. Whereas if we’re using a computer, you’re usually using a mouse or a trackpad. When you use a mouse or a trackpad, you have a lot more tolerance for a frame being dropped or something lagging a bit like a frame or two behind the dragging of your finger on the touchpad. People’s expectations were higher because of the way they were physically interacting with stuff.

Over time, those problems may have gotten a bit better except for Apple. Once they realized that they liked people making native iOS apps that only worked on iPhone and then making an Android app six months later or having a contracting team in India or Eastern Europe make a bad copy of the iPhone app. They felt like they had mixed feelings about making Safari better in those ways.

Even now, to this day, you can see that Safari lacks a bunch of features that would make it a reasonable app delivery platform. One of the most basic ones is every other browser out there implements push notifications for browsers and Safari doesn’t. There’s a list of 10 or 15 things like that wherewith the proper set of stuff, you could potentially make a pretty realistic delivery platform.

{{divider}}‍

It was ironic given their original position before the App Store was released, which was HTML5.

People change their minds and learn new things. I’m not sure that was some malicious plan from the beginning or something like that, but it certainly is the way it is now. Every person out there that we talked to now pretty much knows that when they’re making a new product, they want a website, an iOS app or an Android app.

For the most part, people now want the same product across all of these. Ten years ago, people thought, “Maybe I want a different product for my website and my mobile website. I want a different product on Android and iOS,” because iOS users expect something different from Android users. If you think about the Slack mobile app or the Dropbox mobile app, those were pretty different across iOS and Android, where they clearly had separate design teams who were told to embrace the native design language of the platform.

Google’s directives are a bit different from Apple’s directives. One example of this is when we were trying to get the Quora Android app into the Play Store, Google called us up and said, “We’d love to feature you. We like your service. This looks like a good app, but in order to feature you, we’d like you to move your tab bar from the bottom of the screen to the top of the screen because it looks too much like an iPhone app now.” That thinking is completely gone. If you look at any popular app, it’s like pixel for pixel, the exact same thing across Web, iOS and Android.

The biggest thesis in a lot of ways of what we work on an Expo is there’s a ton of people out there that have a dream of what they want to make. They have an idea in their head of some product and they want to deliver it to their users and those users are going to be an iOS, Android and the Web. We let them write one codebase in a way that’s familiar to people who know React or have web developer level skills, but then can deliver a great product that matches users’ expectations that feels native to iOS, to Android and the Web.

We’ve made a ton of progress towards that. If you’re a web developer who knows React, you can build something using Expo that feels awesome on iOS, on Android and works well on the Web too within a couple of hours of starting to use Expo, which is there’s some more work we can do, but we’re pretty proud of what we’ve accomplished so far.

{{divider}}‍

You were researching where the market or the technology was around 2015, is that right?

We started researching around 2015.

{{divider}}‍

For those of you reading, I was looking at the history of React, not React Native. React was open sourced in 2013 and they released React Native at the start of 2015. The whole technology market around that time was still fragmented. React Native was new and it was iOS-only as well. There were a bunch of competing frameworks and stuff that we’re trying to achieve the same thing.

There’s a lot going on for sure. We like React a lot. I had built something similar to React for Quora. It wasn’t exactly the same, but it had a lot of the same ideas. The most important idea in React is that you have some concept of the abstract state of the world. The React system takes care of making the UI match that state of the world and you write it as a declarative function. By doing that, you’re going to have a greater level of consistency automatically, etc. fall out of that.

A lot of older web frameworks didn’t approach things this way. You had a lot of things where you’d click a button and then it wouldn’t be synced with what’s going on the server or the rest of the UI or whatever and a lot of weird, quirky bugs that happen or you’d write code to render stuff twice. It wouldn’t be completely aligned. People don’t deal with that stuff anymore because pretty much every modern framework now, whether it’s React, Vue or Svelte, something else solves this problem for you, but React was the first one that got popular.

James, my Cofounder has also worked at Facebook before and is pretty familiar with React. That was already on his radar screen even before it had been open source. When we were researching this problem before React Native came out, we discovered on our own that we wanted to push around native views using JavaScript. We started doing that one day and when we were frustrated with our experiments with web stuff, immediately within five minutes, we were saying, “This is obviously the answer that we should be using JavaScript to push around these native use.”

This feels totally different and completely better. It feels like the same as the native stuff we’ve been building with Xcode. It’s awesome that we can make changes quickly in JavaScript. We built a whole system that was like React Native, but iOS only and a separate implementation built by us. We had opened sourced it, but we didn’t have anyone else using it except us. We were building a first prototype app with it and then React Native came out and got released and got 50,000 GitHub stars overnight. I don’t remember the exact number, but it immediately became this huge project.

We knew they had 40 people working on it, had an Android version coming out soon and had this marketing power of Facebook. We said, “Instead of trying to compete with this thing that’s pretty similar, we know some of the people who were working on this. We get along with them pretty well. Let’s take this open source technology and build everything else that we think needs to happen around it to make it usable by people.” We dropped our own thing and started building around React Native.

Since then, we’ve built a standard library for React Native and a whole set of tools and then now a whole set of cloud services that make it. It’s always come back to this idea of when you have an idea for some app in your head, how do we get the distance between that idea and coming to life in the hands of your users, customers, yourself and your friends. How do we get that as short as possible?

{{divider}}‍

Did you think or know that React Native was going to stay as it is? It’s not a full-stack framework. You can decouple components, change the state management system and you can pull in and out. Did you have a worry that Facebook was going to start traveling in that direction and start covering the surface area that you guys were building out? It’s interesting to me that it stayed quite unopinionated and quite normal if you’re building a React Native application like not an Expo that you’d have a bunch of other components on a part of the official stack that you’d leverage.

We didn’t worry about what Facebook was going to do at the time, because we saw there were so many problems to solve and whenever you’re doing any project, you can’t worry too much about whether somebody else is going to solve the problem ahead of you or not. Maybe they will, or maybe they won’t. It’s hard to predict. It seemed like there were a lot of problems to solve. It felt like if we solved a bunch of them, there are still a bunch that was left and if somebody else wanted to work on them, that’s great.

I do think that one notable thing about the React Native project is that a good and bad thing about it is it’s very much built-in a practical way for Facebook, now Meta, to solve their problems. The good part of that is it’s not like a science project for them. It’s a way to build things like Facebook Marketplace or chunks of Instagram. Almost everything new that they build, when they can build on React Native, they do because it’s so much faster to develop. It’s also easier to make a larger application and deliver any updates over the air, etc.

This is one of the reasons why they like to use it. It’s battle-tested by being in production at scale across a huge range of devices to a wide range of users across a wide range of use cases. When there are performance problems that affect their users, they respond to that and make it work. It’s not a demo. It’s a real thing that powers a lot of real applications. The flip side of that coin is because the number one focus of that Meta Facebook or whatever the goal of React Native is to help themselves build their software. It’s less of a priority in some ways for them to make it usable for everybody else.

As a company like Meta Facebook or whatever, they don’t have a giant developer services business. When they open source things, it’s mostly doing a favor to the software development community. A lot of these things where some developers on the team who are like, “Can we open source this?” Nobody stops them more than the super strategic thing and it later can get justified. It helps with recruiting, it helps people who know React Native ramp up more quickly.

There are good reasons to do it, but it’s mostly probably driven by developers wanting to make this stuff open source. Whereas in contrast, some of the projects like Flutter at Google, they’re imagining they’re going to build a developer. They already have this Google cloud business, Firebase and all these other kinds of things. There’s a pretty direct business reason to get a bunch of developers onto your app platform that you can later monetize on one of the most powerful monetization ways that your company works.

That’s an interesting thing about React Native. I do think it’s meant that there was more space left for us to work on. Flutter was not usable until probably 2017 or 2018. If we had tried to build a company around Flutter or something like that, that would have been hard because Google had more people working on it and more opinions and also wanted it to take over all of the solutions and solve those problems. Maybe that’s wrong, but that’s my impression of the space.

{{divider}}‍

When you were thinking about what Expo is now, did you have a clear path to build a business around it or was it something that you were interested in intellectually more?

I wanted to solve the problem because I knew it was a big problem as somebody who would try to make and successfully make apps that worked on iOS and Android and see all the challenges with that. I felt like it was one of the biggest problems for people like me who want to make things. I wanted to solve that. It’s pretty reasonable to do a new project with the mindset that if you solve significant problems for people and add a lot of value, that eventually you’ll be able to find a path to monetization for that, even if it’s not obvious on day one.

For us, we didn’t have a clear idea of exactly how we would monetize. It took a bit of time to figure that out, but it did reveal itself where at first we built this Expo Go Client that everyone had called the Expo app, but now it’s called Expo Go. You download this app from the App Store and then it can connect your JavaScript that’s being served from your computer or from the website. You can develop this native app the way you would have a web app.

After that, people would come to us and say, “I loved using your tool. I’ve got this whole app together now and I want to put it in the app stores,” and then we’d say, “You could tell users to download this Expo app and access it that way.” They were like, “Our users definitely want to get this through the app store. We were serious about this. We want to put it in the app store.”

The first thing we did, we said, “Here are ten pages of documentation that explained to you how to take your code and pull it into an Xcode project and Android Studio project. Follow these instructions.” A lot of people would say, “That’s very confusing,” or they would say, “I only have a windows machine and it’s too expensive for me to get a Mac here in Southeast Asia. Is there something else you could do for me?” We built a service in the cloud that would build an app for you like the binary that you can submit to the iOS app store and the Google Play Store. It turned out that it was important for people.

For a bunch of things like this, we realized like, “There’s something that we need to solve with a cloud service.” Another one of these small things was notifications where people wanted to send notifications, but because they were building their Expo apps without thinking too much about whether people were on iOS or Android, we found it was so hard and annoying to set up notifications, especially on iOS and it was also a little bit tricky on Android. We ended up building this notification service that takes five minutes to set up instead of five hours or a whole day. That was popular with people. People were probably sending over a billion notifications a day now.

As we kept working on the project, it’s being pretty clear that there was a lot of demand for these cloud services and people would also email us and say, “Can I please pay you for this? I want you to stay around and I feel like you’re doing something so valuable for me. Can I send you a donation? Please charge me for this.” By listening to what our users were saying, we’ve iterated into having this cloud business.

We formalize that. We rolled out this thing we call EAS, which is enterprise-grade versus the new cloud services, the build service and submission service. We’re going to roll out the EAS update, which will let you update your app over the air to fix bugs or make tiny tweaks without having to do a new submission of a binary. That lets you develop your app in a modern way comparable to the way you would do continuous deployment with a website. You can now do that.

{{divider}}‍

I was going to ask you, does it feel like it’s becoming feature complete in terms of the core stuff there? Because it feels like phones have plateaued in terms of they’re powerful enough, the screen fidelity isn’t increasing and the iterations in the operating systems are becoming less noticeable. Did you feel like things are going to be done at some point?

Not soon. I had a funny conversation with one of the people that work on it several years ago, who asked the same question that you did. They said, “Doesn’t it feel like we’re pretty close to being done with this project and then what are we going to do?” There’s a boring answer to that, which is, “There’s always small changes in iOS and Android, new versus React Native and there’s some maintenance and updating work to do.”

The real answer is this always comes back to this thing I was saying where the point of Expo is when somebody has an idea, dream or a vision of making some piece of application software, how do we make the distance between that idea and the reality as short as possible? When you look at it from that lens, just because you can write a bunch of React code, include some native code and eventually use our service and get something into app stores doesn’t mean there’s not 1,000 ways to make that a lot easier, faster and better.

Eventually, one thing that’s obvious is whenever you make a significant app with Expo or even if you don’t use Expo, this is pretty common where you have a frontend and a backend. Where you’re writing with React code that’s your frontend, but then you need to store some data in some database and you need to have some server doing some logic. At some point, to keep solving this problem, we’re going to need to make it much easier to have a backend and some logic that has persistence and business logic in it.

You can certainly do that now, but you have to figure out which provider you want, whether that’d be Firebase, Supabase or running your own Postgres database, running a Rails application, connecting to a legacy application, running a node server or using cloud functions from one thing or another. There are all kinds of ways to do it. We’ll always let you use whatever way you want. That’s one of the things that’s worked well for us is knowing that developers need to connect to all things, have all different needs and whenever we go out of our way to give people more flexibility and more power that pays off.

We also find that a lot of people come in saying, “I don’t want to make decisions on my own here. I want to have the fastest possible setup that works pretty well.” I know that if we give people something built-in that’s already configured where the backend is connected to the frontend. You don’t have to set that up yourself and there’s already some persistent setup that works well out of the box, people would love that.

That will be a lot of work to build eventually, but that also brings you one step closer, but there are still 100 more steps to make it so that you eventually and maybe one day you start working in GPT-7 or something like that. You’re thinking of ideas and then the computer is writing the whole application code for you. We don’t think of ourselves as a React Native company or anything like that. We try to help people use Expo and bring their dreams to life where they’re applicable.

{{divider}}‍

That’s an interesting way of thinking about it. In terms of the open source community, did that grow rapidly or did you have to work at that?

We have learned a lot over time about how to better work with the open source community. Anybody who works in open source, this is obvious to them, but if you haven’t done a bunch of open source stuff before, it’s not obvious. There’s a big gap between making something open source like taking a GitHub repo and flipping the switch to public and running an open source project where you have contributors who contribute. It takes a bunch of work to make a repository and open source project workable for people to contribute to it. I can think of a whole bunch of examples of things.

{{divider}}‍

Did you know how to do that at the time?

I have some idea of it or at least some ideas about how to not do it because we’d open source some stuff when I worked at Facebook on some of the platform stuff. We naively approached it and didn’t build a good community around it. It also used a bunch of open source projects and made some contributions to them here and there. I had some ideas from that, but we still didn’t nail that right away.

There’s a tension as well. It takes a whole bunch of work to get a project to a state where people can contribute well. One small example of this is a lot of times, if you have a server, you have to run to do something or some service you connect to. You might have a bunch of API keys or other credentials that have to be inserted into your project, but you don’t want to put those into your public repo.

A lot of projects especially if you involve servers or native apps that need Google Analytics or some Apple developer key, they can be hard to run for somebody that clones the repo and sets it up. If you want to make it easy for people to contribute, you have to do a bunch of work to make it so that the README file at least explains what to do or maybe you even have some set of code paths that says like, “If this is not set up, then either don’t use this analytics service or don’t do whatever, but still make it run so that somebody can go try to fix a bug in one corner of it if they don’t need this thing.”

Whereas if you take your internal code base and make 90% of it public, it’s going to be a mind-numbing headache to uncover all these spots that you need to fill in something, get your own credentials and stick them in place. Similarly, another example of this is we generally have worked with pretty big monorepos for a bunch of different reasons.

One downside of that is if someone wants to make some small change to one library or one part of your docs and they have to clone some giant thing, they don’t want to wait 37 minutes for seven gigabytes or something to get downloaded from GitHub and then dealing with the rest of your codebase when they think, “I want to make one small change to this one thing.” I could probably go on for 45 minutes about examples of things that you can do to make your codebase more friendly.

We haven’t done all of them because we’re always trying to balance building open source community around what we’re doing, but also we don’t have a big team, so how do we keep it so that we’re able to build stuff quickly? Most of our community is not making open source contributions to us. They’re using Expo to build their own software. If we move too slowly to do that, we’ll miss out on some opportunity there. Over time, we’re generally becoming more and more in the direction of being a better project to contribute to with stronger remains, better docs and better ways to contribute.

{{divider}}‍

Do you find that the bulk of the core code is still built by folks that worked for Expo?

Yeah. In general, we try to make it so you can use your own libraries and your own things instead of having to make a PR to Expo and wait for us to approve it. People can do a lot of things on their own that customize and build things the way they want to be. We do also take contributions certainly. The way that most development happens is that people or a company needs something and somebody at that company makes a PR or something.

They may forget and run their own version for time and the PR makes it upstream. That’s how things work with Expo or somebody might discover, “I need this switch to be at it like this new feature of cameras and releases on iOS and Android has this option. I need to access that option, but it’s not part of the Expo standard AV module, but I’d rather use that, so I’m going to make my own fork of it and then I’ll upstream it.” That’s pretty common. Also, fixing bugs in the documentation and things like that. That’s pretty straight forward and people make lots of contributions like that.

{{divider}}‍

I’m looking at your stats and you’ve got a pretty active repository, issues list and pull requests. Is that quite a large cognitive load the team that works for Expo has to take on or is it the community? How self-sustaining is it as a project?

We bear the bulk of that load. That’s probably the most efficient way to do it if you have the resources to do it that way because we have people and our job is to wake up in the morning and take care of the actual project. Whereas most of the people who are open source contributors are using Expo to build some other product. Making Expo good is a little bit reactionary for them, a tangent or a side job. We do try to set it up so that people can contribute and when they do things like report issues that happen in an efficient manner.

We ask people to use a certain template when they file GitHub issues and not file GitHub issues for things that aren’t issues with the source code of the project itself. We have a forum site where people can ask questions like, “How do I do this? Can somebody help me with this thing that I don’t know how to build?” We have a voting board on something called Canny, where people who have feature requests can put up feature requests and comment on them. We take that seriously in the sense that we’ve probably cleared out the top 75 issues that people have ever put on this voting board.

They have not been removed from the board, so there are new top issues or whatever, but lots of people say they want something, we usually do it, unless we have a good reason not to. Every couple of months, we’ll deliberately say we’re going to do a Bug Bash now. We’ll triage lots of issues and clean them up. That’s mostly driven by us and because we are a company that’s appropriate or if there’s a different direction this path could have gone where we could have said, “We’ve made this project that’s open source.”

Instead, we’re going to go off and do something else, but the project is still going to live on, but it’s going to have to be an open source community that takes care of it. Things would play out differently. We’re at a reasonable point in striking that balance. This is also true where most open source projects that stay healthy and alive are either fairly static or they’re driven by a company that has funding, is trying to make money and has people paid full-time to move them forward. For example, it has a company behind it and most of the big changes to it are made by people that worked there, but certainly, there are open-source contributions as well.

{{divider}}‍

That’s been a recurring theme from the folks that I’ve spoken to for this show is that in almost every instance, like the core or more than the core like the bulk of the actual code that’s in the repository is written by people that are paid to do it. It seems like that works for everybody and all the people involved in that. Have you had any experiences where there’s been a technical decision made about using one library over another that has been contentious in any way? It’s quite an opinionated world like React development.

That’s certainly true. We haven’t had any major issues, mostly because when people don’t like the choices we’ve made about how things work within Expo, they can just not use it and that’s a lot easier than getting into a big fight with us. This is true in a bunch of different levels or, at the highest level, people who don’t believe in React Native at all. There’s certainly a bunch of people out there. They go and write something with Swift or they go use Flutter if they prefer that.

Even if there’s some problem with the Expo AV library with something you want to do or something with a video that you can’t do, you can either swap out a different library. A big part of the work we’ve done over a couple of years is it’s now very straightforward. We can make it even better, but you can now use any native code with an Expo project and we can still build it in the cloud for you. Most of the things that are good about Expo will still be good. You have a lot of choices there about what libraries to use if you don’t like one of the libraries that we put in the Expo SDK standard library.

If there’s some small thing missing from one of our libraries, you can fork that and go use your version. We often will accept upstream PRs if they make sense but if they don’t, you can still use your fork version. That takes a lot of pressure off these debates, the fact that people can always do there. You can also use the React Native library without using Expo. We’re doing a good enough job that we’re mostly on our way to becoming the standard way, or maybe are already the standard way to use the recommended library for starting a new project.

There are certainly people out there that use React Native library in their app. The most common reason for this is that you’re not starting a new project and that was optimized for starting a new project from scratch using our tools. If you have an existing Swift and Kotlin app out there and you wanted to integrate React Native for one screen, it’s probably easier to use the React Native Library instead of trying to use the whole Expo set of tools.

{{divider}}‍

In terms of tracking your progress, are you still tracking the open-source metrics of the business or are you now focusing more on revenue or notifications sent or something like that?

We track a bunch of different things, but the three most important that we pay attention to are how many developers used Expo stuff in the last week. That’s a hazy definition, but we have a list of things where we track stuff. It’s not absolutely complete because you can opt-out of this usage reporting, but we can still get a sense of whether it’s going up, staying flat or something like that. How many end-users of Expo apps are there? That’s even more hazy because it’s pretty common to opt-out of those things, but we can at least tell directionally how that’s going based on people who are using our update service and notification service.

The third thing is we track our revenue like any SaaS business. Those three things are the core components of what makes a healthy business and ecosystem. If we have a bunch of developers making stuff for a whole bunch of people, they’re paying us a whole bunch of money and those are all going up, then that’s good. If those things aren’t happening, then we’re probably doing something wrong.

{{divider}}‍

My last question is in terms of the documentation for a project like yours because I would have guessed that’s super important. Was that the focus of the project from the outset?

We’ve always known it was pretty important. I’ve rebuilt our dock site 2 or 3 times and invested a meaningful amount of energy into it. I still think it can be better. We do know that one thing that we do periodically is to find some developer who is interested in making something but hasn’t used Expo before and then watch them go try to do stuff. Whenever we do that, it always is a good reminder that there’s plenty of room for improvement in our docs, especially for new people, even though we have put a lot of effort into them. That’s a general theme.

Whenever you work on a project like this, when you get deep into working on it, you get so familiar that you forget what it’s like for somebody to come in for the first time and it’s hard to keep that like blank slate mindset. You do need to reach out to people who are inexperienced and see what their experience is like. Another challenge around docs for us is that because of the way that React Native, the app binary and the App Store work and things. We’ve had to launch in different versions. We need to preserve this as well.

At any given moment, we have ten different versions of our docs available. That makes maintaining them a bit more of a pain in the butt than you might otherwise like them to be. We’ve built a system around that and it’s not too bad. Mainly you make changes to the newest one and then backport them to the old versions that it applies to. We accept changes for the docs and things like that. We try to make it easy for open-source people to contribute and also anyone on our team.

For our biggest customers, we have a team of people within the company that works with those customers to make sure that they have everything they need and that we’re building the right things for them, etc. They get feedback a lot of times from those people about spots they found confusing or whatnot. We’ll go revisit the docs during that. There’s still a bunch of different ways we can make this better. Adding more video content to these things would be another way that we’re thinking about.

We’ve been starting to add this here and there. One thing I miss about PHP is documentation. If you’re an old person, you might remember this. They had this user-generated comment section where people are giving comments on how to do this and that. It’s somewhere not that high on our to-do list, but something I would love is if we can add some stuff like that.

The third thing is we built this whole thing called Snack that’s like a JSFiddle, CodePen or CodeSandbox type thing for Expo in large part so that we can embed it in our docs so that you could try out any given library very easily. That’s been pretty successful. A ton of people use that every day to try different things and to learn what Expo is and what React Native is. We have, throughout the history of the project, been thinking a lot about this, but there’s so much depth to making docs really look good that I know we can do a lot better.

{{divider}}‍

It’s a super hard problem, and I totally agree with you. It’s impossible to clear your brain to try and re-experience it from a fresh. We’re talking about a similar thing like doing usability testing with engineers to sit on their shoulders and see where they hit brick walls in terms of getting stuff set up because, especially in your world, I find Xcode terrifying. There are a lot of places you can stub your toe and get into Hello World.

One of the tensions of our product is there are two groups of people that we want to serve well. The people that wanted things to be as easy as possible like, “I don’t want to deal with Xcode. I don’t want to deal with Android Studio. I want to get something up and running and the minimum number of minutes possible. I’m on a super tight deadline. I only know web programming, and I don’t have to learn that much more, etc.” We also want to support people that want to do the coolest, most interesting, and exciting things. It’s a tricky balance to make things configured and straightforward enough that the beginners and the people who are in a hurry or lazy can get through things as easily and as quickly as possible.

Also, using the same set of tools, people that want to go say, “I want to go write a lot of my native code here because I want to do something very weird out there, complicated or super high-performance in a narrow way. I want to build this on my machine. I want to set up this or that.” All those things are possible, and that can still use Expo. A lot of the thinking that we do has to balance those two things or try to make them both fully possible. We talk a lot about working for people at both ends of the spectrum as one of our main goals.

{{divider}}‍

That’s pretty interesting. That’s impossible to get perfectly right every time.

Although in a funny way, they’re not even different sets of people in the sense. Cameo is one of the more famous apps that’s built with Expo. It’s a service where you can dial up like a celebrity and get them to make a happy birthday video for your brother or something like that. Video is a huge thing for them. They needed to do some customization to the Expo video models. When they first started, they were a bunch of people who are some business person that had an idea and got some developers together and was like, “Can you build this as quickly as possible? I want to see if this idea works. Let’s try this out.”

Things move over time from being in a hurry, “I need it to be simple.” If they keep going and growing and stuff, then they start to need all these advanced functionality and features. You do need to support both if you want to be the most interesting or powerful. If you want to be the backbone of the most interesting things out there, you need to capture both of those, even though it’s hard to do it in the same project.

{{divider}}‍

Before we go, are there any names, contributors or team members that you want to say thanks to or a new feature or release that you guys are working on at the moment?

One of the best people from the community is a guy named Fernando Rojo, who is the CTO of BeatGig. He’s made a bunch of good contributions to Expo and also made a bunch of great libraries like Moti that let you do cool things with animations or other things that he’s found to be important. There’s a guy named Michael Wood in our community who is great about answering questions that people have and helping them solve the problem. Without him as part of our community, we would probably have four times as many GitHub issues that we would have to deal with and pull down and things like that.

We’re lucky that we have a nice and helpful group of people. We have more people do great things and help each other than we have people who are toxic or a nightmare. One thing that’s nice is because Expo is a tool for builders, there’s naturally a camaraderie or helpfulness that people who want to build things or make things have. That helps keep this community being generally positive and helpful.

{{divider}}‍

It’s been super interesting listening to that story and I look forward to seeing where you guys take it. Desktop apps, maybe.

We want it so that when you have an idea of a piece of software that you build it once as easy as possible and it works everywhere. Our focus is iOS, Android and Web now, especially because Meta Facebook has announced that desktop is a big priority for React Native. That was something we always wanted to do but having other people helping with that will make that a lot easier for us. That’s something that you should expect to come down the pipe.

{{divider}}‍

Thanks again for your time and have a good day.

Thanks, Ben. This is great.

{{divider}}‍

Take care, Charlie.