Brian:
PodRocket is sponsored by LogRocket, a frontend monitoring, and product analytics solution, which is to say, it's not really sponsored by anyone, it's sponsored by us, LogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial, we could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks.

Brian:
In the second installment of our Founder Friday series, Ben talks with Screenplay co-founders Tomas Reimers and Greg Foster. They discuss the technical details behind Screenplay, what it's like trying to get funding during a pandemic, and the Screenplay roadmap. Let's get started.

Ben:
Tomas, Greg, how are you guys doing today?

Greg Foster:
We're good. We're good. We're just coming out of a snow storm over in New York City.

Tomas Reimers:
Yeah. The sun's actually come out, which is kind of nice.

Greg Foster:
Yeah.

Ben:
For once there is more snow in New York than Boston, which I always... always a surprise.

Greg Foster:
Well, Tomas grew up in Boston, so he's familiar with the trade-offs.

Tomas Reimers:
Yeah, I find it funny, my family, we always have a little group message thread whenever the snow storms come in, because they're like, "Oh, we just got like two feet of snow," and I'm like, "It's sunny down here." So, it's weird that there's a little bit of a off now.

Ben:
Welcome to our, I guess, this is our second ever Founder Friday. We're kind of figuring this out as we go along, but the general idea is to talk to founders building early stage companies, mostly in the developer tools space. But if other founders out there are interested in being on the podcast, definitely reach out. So, you guys are building Screenplay, so could you tell us a bit about what's Screenplay?

Tomas Reimers:
So, first off, super excited to be here. Thanks for having us. Second off, super excited to figure this out with you. I think that's a thing that both of us like doing is trying new things and just seeing how they work. So, excited for that as well. Screenplay, the shortest version of what we enable you to do are rollback native iOS apps. So, when you think about the web, if you ever push out a bug to the web, it can be a big deal, but it's really not the biggest deal, right? You can sort of code a fix, push that fix, all the users upgrade instantly, life is good. If you push out a bug to a mobile app, things are a little more painful. You have to figure out the last version you released because it's usually not continuous. You need to apply it to that release. Then you need to go ahead and submit it to an app store, via Apple or Google, actually get it through there. And then after all that's done, you need to wait for users to upgrade. And that can be a much more painful process.

Tomas Reimers:
And so, what we do is we take the current version of your app, we package it with the previous version of your app. We de-duplicate all the internals so that we don't add a huge amount to your app size. And then we basically give you a server config, so you can say, "Oh, if something goes wrong, just have this behave like the last version of the app."

Greg Foster:
Yeah, just an instantaneous toggle back. And what we're doing is we're saying, hey, if you have a catastrophic bug with you iPhone app, instead of having that be live for a day or more, you can roll back to the safe version within a matter of minutes.

Ben:
Got it. Yeah, no, very interesting. And for a moment, I want to take a trip down memory lane because I think, Tomas, you know this, but before I started working on LogRocket, I worked on a project called AppHub with my same LogRocket co-founder, Matt. And AppHub was a tool in their very early days of react-native to instantly update or do rollbacks of react-native apps. So, definitely familiar with a lot of the developer challenges around updating apps, going through the app store review, getting users to actually update. And what's really cool about Screenplay is that, correct me if I'm wrong, but you can support any native mobile app not just react-native, right?

Tomas Reimers:
Yep. So, we do all of the technologies. We do native apps, we do react-native apps, we do Flutter apps. We really work at the level of abstraction that's below the specific framework. And yeah, for the listeners, Ben and I remember we talked back in the days of AppHub. It's funny because now we see that idea has really taken off in other areas. You have Microsoft CodePush and sort of apps under there. And then you also have Expo, which enables the exact same thing for [crosstalk 00:04:00] independent service, yeah.

Greg Foster:
But I think [inaudible 00:04:03] for just any surface area.

Ben:
And I guess with react-native, you do have the ability to push an update to the app. Whereas it sounds like with Screenplay, you can roll back. Are you able to do AB testing? Can you push two versions and toggle between the two versions or is that something that would come in the future?

Greg Foster:
Well, that's a good question. I mean, fundamentally something that guides us is we want to make sure we're well within the bounds of app store review policy, make sure we're following all the rules. And we kind of base all of our logic and ideology around feature flags. So, feature flags are often used as a way to gate an individual feature or function, you often wrap it like an if statement and a server will send down for any one user, are they getting A or B. We're taking that same idea, same mechanic, and we're just a applying it to the overall app level. But same as feature flags, what's important to us is that whatever functionality could run on the app is present at the time of app store review. And it's important that when the app store reviewer's going through, they can review that functionality. We're sending any code over the wire, over the network, we're not allowing any private method calls or things like that. So, the degree is you're asking, could you kind of AB test two versions of the app? It's possible, but it would just have to be such that the app store reviewer would have access to both versions, just like a feature flag.

Ben:
Yeah, that's something I was going to be curious about. When we were building AppHub about five years ago now, that rule was still in place that all the functionality had to be available for testing. You couldn't push substantially new functionality to the native part of your app, but there was a carve out in the Apple terms of service for updating interpreted code. So, with React Native, you could update the JavaScript and I believe that's still the case, but they were very clear that you can't update compiled code. But it sounds like since with Screenplay, you're shipping the app with all the potential functionality, it doesn't run into any issues with those terms of service.

Tomas Reimers:
Yeah. And I think Apple's terms of service are actually even a little stricter than that. It's you can update interpreted code, which would run in a web browser. And so that really like limits it to like JavaScript, HTML, CSS. It's not interpreted in code at large. And so, Apple is very strict on that and we want to make sure that we play within the rules there.

Greg Foster:
But so far we've had no problem. We've launched multiple apps to the app store, everything seems perfectly sane.

Ben:
So, I'm curious to talk more like a technical level, tell me a bit more how it works. How do you install or how do you set up Screenplay? What is the technical process for bundling and building your app? And one of my immediate questions was like, does this double the size of my app? But it sounds like it doesn't. So, maybe we could talk through some of that.

Tomas Reimers:
Absolutely. I love talking about Screenplay. Whenever I talk about it, unlike other products, I feel like I'm selling time travel. The question is never, "Do we need this?" Or, ""How would we use it?" It's, "Wait, is this possible?" And so, there's always the kind of conversation you have to ask of like, "Is it possible?" And we're happy to talk more on that. Then there's always the, "How do you use it? Is this incredibly painful to use?" And then after that, "Would this affect my app size?" And so, to tackle, head-on, how do you use it, when Greg and I were scoping it out the first time, one of the things we were really sensitive to was we did not want this to affect an iOS developers process. We really wanted it to be something that someone could just slot in at a company and for it to seamlessly work in the background to help protect you against mistakes that might happen in the future.

Tomas Reimers:
And so, with that, we really sat down, we looked at other developer tools. And I think one of the places we got inspiration from was early day Stripe, which was like two lines of code, you have Stripe up and running. So, we really push ourselves there with what are the two lines of code you need to get Screenplay up and running? And so for us, that's you go to a terminal, you type Brew install Screenplay. So, we use Homebrew, a common package manager, I think most people are familiar with. And then you do Screenplay and you just give it your app name. And it'll prompt you for a token that you got from our website. But once you do that, it sets it up within the Xcode project, then you're good to go.

Tomas Reimers:
Beyond that, you basically have two apps in your Xcode project. You have your original app, which works as expected, you can continue to build. And you have the Screenplay version of your app, which builds your app as a dependency, but alongside that we'll upload that to our secure store of your previous versions of your app, download a previous version of your app and then bundle those together to create your Screenplay build.

Greg Foster:
So, what that looks like is really just anyone in the company... one person's installing it, but anyone you're working with on the project, they can go into Xcode and you just get a secondary target and press the Screenplay build button, as opposed to the original, and it will, as Tomas was saying, automatically do that, saving that old version, downloading the correct versions, bundling them together, kind of all automatically. And right there and then, you can actually run that on the simulator, you can test it, you can snip out the Apple as you normally would, but we tried to keep it as simple as possible.

Ben:
In terms of the technology to shrink down the bundle size, such that it's not doubling the... having two entire versions of your app, how does that work?

Greg Foster:
So, when we were first prototyping this out, we did the stupidest thing, which is we stuffed two apps together, we got that shell wrapper, that's operating similar to a feature flag, and toggle between. The next step is you're getting I was like, okay, how do we de-dupe this down? And we went through varying levels of ease. There's the simplest things to de-dupe and it kind of gets more complicated. So, one of the simplest things we could do was just walk through both the old and new bundle, look for any static files that were the same, move those to a central location, and then symlink back to the expected bundle locations. So, any stray text files or images or things we could move into a shared folder, put symlinks in the original locations, and we were able to de-dupe those. That gave us what, what would you say, a bump on?

Tomas Reimers:
So, when we were originally prototyping this, we created a battery of 10 open source apps, which really helped inform our size decisions. So, think like Wikipedia, Duck Duck Go, Signal. These are apps that everyone's probably heard of, many of us have on our phone, but they were really useful for us to be like, "Oh, these are like pretty normal."

Greg Foster:
We can run them through the process and test to see.

Tomas Reimers:
Yeah, exactly.

Greg Foster:
So, that got to 20 or 30%.

Tomas Reimers:
Yeah, exactly. So, at that first static resource path gets us about 20 to 30. Just those ....

Greg Foster:
Yeah, the next thing we tackled was probably dynamic frameworks. So, every app, the imported variety of dial-ins or dynamic frameworks. And those actually just sit within a frameworks folder within the app bundle.

Tomas Reimers:
To the app developers out there, you're probably familiar with this if you use CocoaPods or Carthage, many of those sort of get imported as frameworks into your application.

Greg Foster:
Exactly. Exactly. So, those all exist as Mako binary files on a computer and we can't do the straightforward, just compare the hashes of those files and de-dupe them. We have to be a little bit smarter because they're actually not quite deterministically built. There's sometimes little elements from the exact path on the computer will be incorporated into the binary, might be a little bit of randomness, might be a timestamp. So, what we do is we actually just parse that binary, we understand it, we look at the headers, we look at the sections and data, and we make a decision and we say, "Hey, this is a duplicate of the old and new versions." And then once we know it's a duplicate, we can once again, move it in the bundle to a centralized location and update all the references to that. So, by de-duping the frameworks we slice off what, another 30% per se?

Tomas Reimers:
Yeah. I think that brought us down to roughly 30%. And then, from there, it's a lot of miscellany. One of the common examples is if you think about how Apple deals with images within the app, it actually compresses them into a custom archive format, which is a dictionary from like name to binary, which is the image. And so, what we have to do if we want to de-duplicate that is... Most people never actually update an image under a name, what they do is they actually add or remove. And so, we just need to merge the two. And so, that was a matter of sort of like pulling that apart, reading what are the different file types included in here, are there any conflicts? And if not, just merge the two and then put them back there.

Greg Foster:
Yeah, what Tomas is describing is what's called an asset.car file. If you make a new Xcode project, you'll often see an assets, special Apple file, and that's exactly what the assets.care is. So, custom zip, we pull it apart, perform more de-duping on that. At that point, we're getting down to 20%, roughly, left to de-dupe and the final bits start getting down to static libraries. So, at some level you're actually down to just the two different executables, the root executables of the app. So, one thing you can do is identify as static libraries that are shared between the two and dedupe on that level. And you start deduping on the linker level. Even more extreme, you can start deduping on the object file level. So, within the actual code of the application, if different code files haven't changed, you can try deduping there.

Greg Foster:
But what we see, and at some point you can't get quite perfect because you're also expecting any actual app update to have something new. So, there's always going be some degree that you can't de-dupe. But I'd say, right now, the apps we run through the system have about a overhead about 20%, 25%, depending on what they've updated. And I think we have on the roadmap, improvements to get that much lower.

Tomas Reimers:
Yeah, some of those theoretical improvements would push us down to 5% for that battery. That's a scary number. I think, especially when we tell people like, "Oh yeah, we can bundle like all the new for only a 5% increase." It's something we have yet to validate, but we see our path there and we're very excited by it.

Ben:
And does that whole build process take place on your servers or is it something you do locally or in your CI pipelines?

Greg Foster:
One of our giant philosophies is to try and run as much of this on the user's computer. I mean, that's what the Xcode does. We have the Mac computer right there. It's honestly a little bit easier for us, because it's non-trivial for us to run a large Mac server cluster anyway, so if we wanted to run the builds. So, we keep this all on the users, Xcode. Xcode allows you to kind of call out to arbitrary programs and help manipulate some of the bundle assets while you're doing that build phase. That's where we hook in and we start performing some of these operations.

Tomas Reimers:
Ben, you see this. If you've ever added a run script phase to your build process, you'll see people will add this for things like modifying the version bundle, you'll see it for cleaning up images-

Greg Foster:
Swift is one of the common, people will add a linter to their Swift code, just to kind of execute within their builds. We're something very similar.

Ben:
So, what does the rollback process look like? So, I build my app, I ship it to production. You mentioned a bit about some automatic ability to roll back if an error happens. So, how does that work?

Tomas Reimers:
So, the way that you roll back with Screenplay is actually very straightforward. You go to screenplay.dev, there you'll see a list of releases for your application. You go ahead and select the release that you want to roll back. On the right side, you'll see a panel that looks very familiar to anyone that's used a feature flag system. You basically have rows that describe events or rules that you can apply. So, for example, you could say iOS8 users I want to go back to this version. And then you have one last row which describes and everyone else that's not covered by the above, they should go to one of these versions. And so, if you want to roll back everyone, you'd simply select that bottom row and you'd go ahead and select, okay, roll them back to the previous version. And what would happen is the next time they opened up their apps, it would detect that something had changed and they'd open up in the previous version.

Greg Foster:
Mm-hmm (affirmative), nothing too fancy there. It's really, again, just a copy of the implementation of feature flags. We want to keep the interface similar to something people would be familiar with. All the magic is really in the build process.

Ben:
And tell me a bit about the business around the product? So, it's a couple of founders, both of you are founders, and then I believe there's one more founder who who's not here today?

Greg Foster:
Yeah. We have an amazing third co-founder, he's actually on another call right now, keeping the business alive and running, named Merrill, who's a fantastic... Actually it's funny, we've all known each other for, give or take, like eight years.

Tomas Reimers:
Yeah.

Greg Foster:
Just from various college experiences, classes, internships.

Tomas Reimers:
We all went to school together. And so, you end up meeting each other on campus. Greg and I were project partners in all of our CS classes, and so-

Greg Foster:
Like everything.

Tomas Reimers:
Yeah. And so, we've programmed operating systems together. We've done graphics code together. We've done too much. And then Merrill was a few years older than us, but he was still involved a lot in the startup community at school. And so we got to know him because we'd always run into him at events, at gatherings, whenever you'd have someone come on campus and speak, things like that.

Greg Foster:
We kind of parted ways. Because we were best friends, and we graduated, I went out to San Francisco to work at Airbnb on their infrastructure, it was very cool. And Tomas decided, he stayed in the East Coast, he went to New York and started working on Facebook. I feel you got a little bit more face time with Merrill. You guys were hanging out, you guys were talking about startups.

Tomas Reimers:
Yeah. Merrill actually was one of the reasons I moved out to New York the first time. He very much convinced me like, "No, the city's alive and well, it's thriving. There's a startup scene that's growing here that's worth being a part of." And so, he was at Oscar at the time. After that, he went to a few startups. And so, I moved out here and got to spend some more time with him, which I'm very grateful for.

Greg Foster:
I think, yeah, one of our hesitations was, hey, we love New York as a city, think it's very cool. We love SF, but I think we just have a soft spot for New York. But it was a question of, hey, is this city right to run a dev tool startup, something that's hardcore, low-level infrastructure focused? Or do you have to run that in San Francisco? And I've been honestly, so pleasantly surprised. It's been fine. It's been great starting a company in New York. And I actually like helping and bringing some hard tech and some hard tech startups out to New York. I think we're seeing more and more people shift from San Francisco and come out to New York.

Ben:
Yeah. I mean, and I think a lot of the recent successful IPOs, I mean, Datadog being one that, I mean, incredibly successful hard tech company in New York and MongoDB. I mean, a couple of really great businesses built in New York. So, hopefully it shows that not every company needs to be based in San Francisco to be successful in the dev tool space.

Greg Foster:
I think COVID's been terrible, but I think in some ways we got a little bit lucky in the sense that it pushed everyone to be very comfortable with remote meetings. Because we work with a lot of advisors or companies or beta partners and things, who some are in New York, but a lot of them happen to be in San Francisco or other places. And the fact that everyone is so comfortable just taking a video call, that's the norm, you just hop on and you can be in five places in five different hours, makes it so much more convenient. I think the alternative would have been, what we were expecting, which just, one of us was always flying out to SF and meeting people in person and helping onboard them.

Ben:
You raised some money recently, when the pandemic hit, right?

Greg Foster:
Oh yeah, fun times. Fun times.

Tomas Reimers:
It's a fun story.

Greg Foster:
Jeez, it was crazy. We were working on this... we were talking as friends and we're like, "Hey, we think we should really go for this." And we started the wheels, we started talking to people. And we did the proper seed fundraising round, right in like mid-March. It was crazy. We flew out to San Francisco to meet investors, we got this tiny little Airbnb, because we're like, "We're going to be beating the pavement all day, and we're going to be in meeting rooms and stuff, eating free snacks. We're not going to spend any time in this Airbnb." And at the start of the week that was true, and we're going to offices, and we're shaking hands, but at that point it was like, people were like, "Let's bump elbows. Let's be safe here." And we're like, "Yeah, elbows are safe."

Ben:
Yeah.

Greg Foster:
And sort of shifting, and by the end of the week it was like, everything was just a video call. We're in this cramped Airbnb, crouching around a laptop, two blocks from the person we're having a meeting with.

Tomas Reimers:
It's really funny, actually. The part of that week that most stands out to me is I just remember we had this Delta flight scheduled for Sunday because we had decided like, "Okay, we're going to be there for the week, then we'll stay for the weekend, say hi to some friends, angels, advisors, all the above, and then we'll come back on Sunday." And throughout that week we just kept hearing people being like, "Oh, when's your flight? You know, my friend so-and-so has a friend so-and-so, who has a friend so-and-so that heard that flights might be grounded in the next week. You might want to move that up." And so, we ended up moving our flight up by two days because every day someone would be like, "Oh no, this is the day. Flights are going to be grounded in like 48 hours."

Greg Foster:
Yeah, so we're like, "How many more meetings can we fit in before we have to jet out of here?" Yeah, so we left... I think it was the moment we got to New York things kind of went under lockdown. We finished up raising over video. Tomas and Merrill have lived here, but I moved into just a barren apartment. I'm sitting on a hardwood floor on Zoom, we're like, "Yeah, yeah, we'll tell you why you should trust us with your money."

Tomas Reimers:
Yeah, it was a wild time to start raising. It's one of those things I joked that starting a company during the coronavirus pandemic was not something we could have predicted. And so far, everyone's like... Doing a startup, you can't expect that you can't plan for it, you don't know what it'll be like. And I don't think anyone meant this, but I'm not sure.

Greg Foster:
It's been fun actually. One of the greatest benefits of starting at the time we did is, one thing, there was no FOMO. I was so concerned we'd be pulling late nights in the office, and we had to politely be telling friends like, "Oh, I can't see you, we got to just keep hustling." No, it's actually we've all... I feel like we're snowed in, in a cabin writing a novel. We've got all the time to build out the initial version without any distractions. It's actually been pretty effective.

Ben:
What does the future of Screenplay look like? What's on your roadmap? What are your plans for the company?

Greg Foster:
Well, I think we have two things we consider. We consider what is the roadmap from a business perspective, and there's also, what is the roadmap from what we're trying to build and what we're trying to affect in the tech community. From a business standpoint, we really have two main goals. One is growing the team. We've reached the point where we have a V1 of the product, we're onboarding customers, they're starting to use this product. And we don't actually have bandwidth to run new customer conversations while also hiring, while also running dev ops, while also trying to add new features. This team of Merrill, Tomas and I, at some point it's reaching a breaking point. So, we've just closed our founding designer, which is amazing. It's one of the skillsets that we don't actually have a very good knack for as founders. And then, we're actively interviewing and talking to people to get some founding engineers aboard to help expand that bandwidth.

Greg Foster:
The second thing, again from a business perspective, is really growing the user base. We have a few beta partners who are using this, their deploying with Screenplay, they're having a good experience, but we want to grow that. We want to say, "Okay, we can have a positive experience with a small number of people. Can we scale that? Can we reach self-serve, get this in as many hands as possible over the next year?"

Tomas Reimers:
Yeah. And then on the technical side, I think what we're really looking forward to is... For right now, we want to stay laser focused on iOS. We think that there is a huge, huge, huge opportunity here to make this process just incredible. And we really want to do good by that. I think once we get that done, we really want to then tackle two different areas. One is bringing all of this goodness to Android. I think it's super duper important. The other one is helping people understand when they should roll back. And so, that means plugging into analytic systems, or if people don't have any, giving them their own, where we can then go ahead and we can look at these releasesthat they've rolled out and say, "Oh hey, this one's problematic. Have you thought about rolling back?" And hopefully more than just having the like, "Oh, I can now roll back," actually giving people an ability to say, "Hey, we've detected there's a problem, would you like to roll back?" And really finishing that engagement.

Greg Foster:
Yeah, when I was at Airbnb, I was lucky enough to work with an amazing continuous delivery team. And we helped bring Spinnaker, which is an open source... I think Netflix created this, an open source tool for doing server and web deployments in a continuous fashion and in a really automated fashion. And when we saw that magic that's, I think really just starting to come to fruition on web, that hasn't come on mobile yet, because you say, okay, every release, we roll that out and we roll it out in a progressive manner. We do it safe when carefully. We scale up the population who's getting the new version. And then what's more, if there's any issues, detect those errors, say that that's a statistical regression, and roll it back. And you don't even need a human to press rollback, the system can make that call itself. All those kinds of different effects lead to a situation where you're minimizing the impact of a bug, because you've reduced the number of people it's hitting and you've reduced the time that it's live and in production. That really inspires us. We want to bring that to more platforms than just web servers, such as mobile. So, all those ideas, progressive rollouts and automate rollbacks, we'd love to bring that to mobile.

Ben:
Finally, for folks out there that are listening, if they want to learn more, get started with Screenplay, the URL is screenplay.dev, but can you take any existing app and just get started using Screenplay? Or are there any other steps you have to take before getting started?

Tomas Reimers:
Can you take an existing app and start using Screenplay? Yes, absolutely. We would love that. We have tried our hardest to make ourselves work with as many different apps as possible. It should be as simple as going to the website. And if you go there, there's a button to reach out to us directly, and would love to chat with you.

Greg Foster:
Yeah. The current process, we're essentially providing white glove service to any applications who want to get involved right now. Because we want to make sure everything is seamless, everything's smooth, if there's any questions, any hitches, we're there to debug instantly. I think within the next couple of months, we want to expand that to just general adoption, people don't need to talk to us, they can just install right away.

Ben:
Well, Greg, Tomas, thank you so much for coming on the LogRocket podcast. This was awesome to learn about Screenplay and for folks out there, go check it out. If you're building a mobile app.

Greg Foster:
Awesome. It's been a pleasure.

Brian:
Hey, it's Brian again. So, it turns out that running a podcast is maybe harder than we thought. And so, I kind of want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests, we have to find them, and don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. So, if you'd like to suggest the topic or volunteer to be on PodRocket, we'd like to hear from you. So, you can do that by going to podrocket.logrocket.com/contact-us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.