iPhreaks

The iPhreaks Show is a weekly group discussion about iOS development and related technology by development veterans. We discuss Apple, tools, practices, and code.

Subscribe

Get episodes automatically

184

184 iPS Deep Linking with Alex Austin


Introduction

1:05: Deep linking

  • Storyboarding
  • URI schemes
  • Fragmentation of standards

12:15: Examples of deep linking

  • Sharing
  • App adoption

15:15: Direct to App Store

  • Referring user information
  • Fingerprinting
  • Burrito ad

24:00: App delegate

  • Link routing
  • App.link
  • Preventing malicious attacks

27:30: Success stories

31:00: App without website

Picks:

Amazon Echo (Rod)

JMP (Alex)

Bose headphones (Alex)

Fellow Coffee (Alex)

 

hired.com/iphreaks

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Jaim:             Hey everybody and welcome to the iPhreaks Show. Today on our panel we have Rod Schmidt.

Rod:             Hello from Salt Lake.

Jaim:             My name is Jaim Zuber, I’m from Minneapolis. Today on our show we have Alex Austin. Alex, can you introduce yourself?

Alex:             Sure. Hey everybody, my name is Alex. I am the CEO and co-founder of a company called Branch. We’re based in Palo Alto, California. We’ve got about 90 people so far. I believe we’ve been around for about two and a half, close to three years now. We provide a service where we provide deep linking infrastructure for app developers. There are many, many different potential use cases about infrastructure and hopefully we’ll talk through some of those today.

                    Simply, anywhere where there is a link pointing back to your app, it should be a Branch link because we will do linking better than the developer ever should and probably most likely could.

Jaim:             Very cool.

Rod:             Maybe we should define what deep linking is.

Alex:             Yeah sure. High level description, hopefully the audience is relatively familiar with it because Apple has been doing a lot of work in this base over the last few years. The high level premise is something that people are very familiar with in the web.

Think about the use case where you receive a link to an article from a friend. You click on it and immediately in the browser that article will load so you can read it, very, very simple functionality in that world. Creating the same use case in the app world where you receive a link to an article, you have that particular news outlets app installed on your phone, you click on it, the app opens, you should see that article, and when you do, that concept is referred to as deep linking. You were deep linked to that article.

Majority the time people don’t actually build this and the app might open up and you might get shown the home screen, or maybe the browser will just open even though you have the app installed, which is a very [00:02:20] experience.

Jaim:             Definitely I’d say, experience of the deep linking, let’s say you get an email, or push notification, or text message and you click on it, it’s typically a bad experience. Most apps don’t do this well. They could get you to the wrong place and you’re not log in correctly. Having done this for an app, I know how hard it is to get it right. What are some tips to get this working correctly?

Alex:             There’s a lot. It’s incredibly hard to build. In the browser case back for websites, it just was baked into the standard. Every single page on a website has a unique URL. The browser’s job is to basically download the website from that URL, and then display it properly. In the app world, really because of the way that Apple designed Xcode and some of the app development principles, developers typically think of their app as a storyboard, one which has a beginning and an end. A deep link, you basically have to throw that story board concept out the window and think about each view controller as individually addressable. It changes the paradigm on how you build and think about the app. There’s a ton of different edge cases that you likely have to encounter or you have to solve when you’re building an [00:03:47].

Some quick examples, let’s just say, for example, the typical storyboard of your app is you have a splash page or maybe you show your logo which takes you to your home screen, and then from the home screen there’s a list of shoes people can buy. When you click on that shoe it loads a shoe view controller that will give the user all of the details of that particular shoe. To deep link to a pair of shoes now, there’s a pathway where somebody will enter your app and the first view controller they should see is the shoe detail view controller.

There are a lot of implications in terms of how you do view controller stack management. If you’re using a navigational controller, you basically have to programmatically fill the nav controller, view controller array with the splash screen and the home screen, and then the shoe detail screen so that the user gets and sees that particular view controller right away. Then you might have to add an additional back button that makes it incredibly easy on the shoe detail page to go back to the main menu page. Whether or not the user is actually seen it before. There’s a lot of different navigational features that you need to think through and to test very carefully before you roll this out, because I guarantee you’ll miss something if you weren’t careful when you’re thinking through a lot of these user flows.

Jaim:             That makes sense. On the web, we’ve got a unique URL that we can go to that brings of our app. How does this translate to the app world? We got a URL but how does our app know that we can open this type of link?

Alex:             Yeah. There’s a couple different ways. Unfortunately, this is one of the things that if you don’t use Branch you have to deal with it on your own. Describe a little bit of the inner workings at a high level, about how Branch works, and then I can describe how we try to simplify it for developers. You don’t have to think about all these complexity.

Deep linking had a long history in iOS and it’s given birth to a few different paradigms for how to think about adding deep linking and how to think about creating these URLs for individual shoe detail pages, just rolling with the previous example. The previous mechanism basically up until iOS 8, there was a concept of URI with a path. In your PList file when you built your app, set an URI scheme which could be anything that you wanted which was an alternative to http.  The way that Apple would process these URI schemes would be that, the example for the shoe one is it’s my shoe app is the URI scheme. If the deep link that is myshoeapp://pairofshoes123, Apple would process the click of that link look for an app that’s presently installed that has the URI scheme registered for my shoe app, and then pass that URI scheme path, that URI path into the app for the developer to handle routing. The alternative to that URI scheme was http links and all of those were defaulting to the browser. You click on http:myshoeapp.com/pairofshoes1234, that would load in the browser 100% of the time. You basically had to have two separate unique URLs depending on if you want it to link to the app or link to the website. This is all iOS 8 and before. It gave birth to all sorts of complexity in terms of when do you link to the app, how do you know if the app’s installed, all sort of stuff that added a ton of overhead for developers.

                    The other problem is that because it is persistent for six years of iOS development through all the way up to iOS 8, all the apps that adopted deep linking into their standards like Twitter, or Pinterest, they built this concept of app links that would promote deep linking form the Facebook newsfeed for example on top of this URI scheme standard. Then in iOS 9, Apple said, “Forget about URI schemes, they’re dead to us. We’re going to roll out this concept of universal link.” Universal link now http:myshoeapp.com/shoeapp123 could open up the app, that now the web link would correctly open up the app when it’s installed and fall back to the website when the app is not installed. There’s a bunch of configuration that you have to do and we have a ton of guides online if you’re not familiar with this concept on how to get all setup. It’s basically turned http links into deep links as well.

                    Meanwhile, on the rest of the ecosystem, Apple world is out and it basically only worked on iOS apps. Meanwhile Facebook, Twitter, and Pinterest, most of the places where your links are likely getting posted, don’t support universal links because they’ve built their entire foundation on top of the previous standard, the URI scheme standard.

Now because there’s this fragmentation of standards, developers are forced to basically implement both mechanisms. It’s one of the obstructions that we try to take away. You don’t have to worry about URI paths. You don’t have to worry about even web link paths. We store everything in the concept of like a state so it’s not just URL path anymore. You basically say, “Here’s this shoe app detail page.” The current state is that it’s been added to cart or something like that or it’s sold out, let’s say sold out, it’s a better [00:10:11]. You pass that to Branch in a dictionary of keys and values and we will return to you a short URL that permanently references that state. And then any user who clicks that link, we will handle all the routing. We’ll do URI paths on Facebook, Twitter, Pinterest, and everywhere of those are needed. Universal links in the place where those are actually compatible, and then we’ll deliver this bundle of state into the app so that the developer can actually do routing appropriately depending on the keys and values within that dictionary. It helps obstruct this concept of deep linking across the many fragmented standard that exist today on iPhone. Hopefully that helps.

Jaim:             Yeah. That sounds really basic functionality but if you’ve ever tried to implement deep linking even in iOS 9, say from push notification and pass of info on it, there’s no real easy way to do it.

Alex:             It’s crazy.

Jaim:             Yeah. You have to create your little implementation. I scoured through the documentation for quite a while like, “Wait a minute, there’s a way to this.” I just want to pass to the idea of this thing I’m opening, the shoe ID.

Alex:             Yeah, exactly.

Jaim:             This is actually a no brainer but it’s cool functionality.

Alex:             Yeah. If you tried to do this yourself, there’s I think three different life cycle of calls in the app delegate, you have to handle yourself correctly parse when that path is delivered to you depending if it’s a universal link, or URI scheme, etc., and then route appropriately. We basically just curate one call back block where you can put all your routing code, and we’ll deliver that dictionary of keys and values, and you just do it depending on what the keys and values say. Just really simplifies the implementation process dramatically so you don’t have to worry about all the complexity of if they’re coming from Facebook, this come from Twitter and to the other thing, etc., etc.

Jaim:             What are some typical examples of deep linking?

Alex:             When you say examples you’re probably referring to features that people might build. We’ve considered that core concept that I just describe of, you register a routing function with Branch and we pass in the dictionary. We consider that just sort of this basic deep linking infrastructure. We never really wanted this app too much farther beyond that because we didn’t want to pretend that we could even imagine all of the possibilities of the things that people could build on top of that infrastructure. We’ve just seen the craziest most unique things that really deliver incredibly user experiences built on top of that simple routing mechanism.

I’ll talk about some high level clusters of the concepts to help stimulate creativity. One of the most basic ones is around sharing. If you have some content, let’s say you have the shoe app, there’s actually a really good shoe app that I recommend downloading. I think its targeting folks called sneakerheads. I’m not sure if anyone seen that Netflix documentary that describes this whole subculture but there’s this app called GOAT in the app store where sneakerheads can trade this unique and rare shoes with other folks. They do a really great flow where if you go to share a pair of shoes via SMS, or Facebook, or you name it, any channel, they’ll create a deep link that permanently references that pair of shoes. When that destination user, the receiving user of that share or anyone who’s browsing through their Facebook feed clicks that link, if the app is installed, immediately open it up and show that pair of shoes. The fall back is even cooler which is something that we built on top of our platform, we call it deferred deeplinking. When the user does not have the app they get sent to the app store where the user can install the app upon opening the app for the very first time, we’ll pass that same shoe dictionary through so that new user actually gets routed right to the same pair of shoes that they clicked on even though it was the first time ever opened up the app. Really, really powerful user experience is built on top of that sharing example.

There’s another whole set of folks, if you have a website already and you’re trying to drive app adoption, Pinterest is a great example of a company that does this really well with Branch. If you are searching on Google or whatever for some sort of creative crafts project and a Pinterest web page shows up, you click on it, it’ll load their mobile site. All of the links on that page basically direct to the get the app. Upon installing and opening of the app, they’ll show you that same creative craft project that you saw on mobile web. Of course if you have the app, it’ll open up already and take you straight to that craft project. It’s helping to drive adoption of their apps through their mobile website as acquisition channel.

Imagine, there are like probably 100 other examples here. The high level concept though is if you want to link back to your app, it should be deep linked because in general users don’t really want your app. They want to engage with what’s inside. A deep link is the best way to put that foot forward, to present to them that stuff that they really want to engage with. You’ll see dramatic increases in conversions and retention by drawing your users in with the deep link as opposed to just a generic app store link.

Jaim:             Yeah. That’s a good point. We’ve all think that people are just using our apps all the time and that’s how we share a pair of shoes, my 84 Michael Jordan’s or whatever. Realistically were out the world, we’re doing things, and we’re getting stuff by email, by text, and it allows us to get into an app to see the content. One thing that’s blowing my mind is that you can direct them to the app store. After they actually install it you can actually go the correct link. I don’t know if I’m missing that point correctly. What’s involved with making that happened?

Alex:             Yeah, sure. I was an app developer before Branch and actually we built Branch as a tool when we needed it to build some of the features that we wanted. I will go answer your question I promise. The core feature that we wanted to build very simply was an app based mimic of the Dropbox style referral program. If anybody was ever affected by the Dropbox for referral program, which I think they actually shut down because it was actually hurting their business so much. The concept was you are a member of Dropbox, you’ve had a referral link. You could share it with a friend. If that friend clicked on it and signed up with Dropbox then you got free space and they got free space. Basically people were amassing these huge piles of free storage space just through this, trying to game this referral program. It worked incredibly well and drove majority of their growth over their early years.

In our app that we were working on before, I wanted to create that same functionality. To do so required me to be able to pass that referring user information through the app store. The flow that I wanted was I create a link, I share it with a friend, the friend does not have the app, they click on it, go install the app, and then immediately open it up and they associate with me as the referrer. They could see a personal welcome from me, automatically receive their credit, I automatically receive my credit, all that kind of stuff just in a very, very smooth fashion. Whereas the only way to do it today without doing this concept of deferred deep linking is with referral codes which are a nightmare to build, ridiculous to manage, and really low conversion because the user has a hard time typing this stupid code on their phones.

Anyway, how it works, how we built it was very simple. It’s this concept of fingerprinting. The way it did it, I’ll use that same user flow and I’ll describe the mechanics behind the scenes. You click on it, what we did on the click is we basically received around five to ten different parameters about you as a user, which are IP address, operating system version, device model, language, a bunch of other thing that we would collect before we redirect you to the app store. This is what happened instantaneously, it was a very quick behind the scenes thing. We’d store that fingerprint from the browser behind the scenes, then when you open up the app we basically generate the same parameter set from within the app, send the back to the server and match the two app. If there was a match, we were very confident that you just click on that link and so we would show you that personalization.

Definitely there are some concerns about accuracy rates and switching Wifis and IP address changes, and all stuff. We powered a lot of what Branch was in the early day but were not at the scale where we process close to about 4 billion request a day to our backend. What we’ve been actually doing, accumulating, and it’s one of the benefits of using our platform, is we set a cookie in the user’s browser and we’ll tie it to an IDFA or Google Advertising ID on Android. Over time, we basically amass this gigantic pool of these 100% per ins of cookie to IDFA. What that allows to do actually is not use that fingerprinting mechanism but actually use historical data that we’ve seen contributed from other apps on the platform. We create the shared pool of cookies tied to IDFAs that anyone can benefit from. Maybe you start using a Branch link for the first time, your users click on it then install the app. We’ll tell you if we know that they were click on that link with a 100% accuracy or if we use fingerprinting. You can then build things like auto login and other cool features on top of that. The Slack login links is a great example of a really compelling feature built on top of that Branch pool to guarantee 100% accuracy when that data is pass through. There’s also a really, really unique features that you can build out on top of this giant pool of data that we share among all apps on the platform. Hopefully that helps explain it.

Jaim:             That’s really cool. Now that you’ve explained it, most of our listeners should go and do it themselves. I’m imagining if they don’t want to, if it exists, how did they get this functionality from your service?

Alex:             Yeah, sure. It’s actually totally free to use. We opened up the core platform with all link creation, all that deferred deeplinking, attribution, and all that cool stuff for free. If you’re a bigger enterprise and you will end up paying us money but if you’re working on a side project, you can sign up, add the SDKs, and start creating links in about five minutes. We actually have a video on our site, we had a race of somebody how to chipotle burrito. There was another developer in the room who was tasked with trying to integrate the SDK and start creating links before the person finish their burrito. The developer won of course, otherwise we wouldn’t posted it. It’s really quick to get started.

Jaim:             Very cool. You get the SDK, you said that your app delegate’s has implementing some kind of delegate, how is that one?

Alex:             Oh sure, yeah sure. The really high level description is you sign up, you basically configure link routing. You say, “Where do I want to send users on iOS?” If they don’t have the app, where do I want to send users on iOS. If they do have the app, quite really quick configuration on that stuff. Then add the SDK which has a place in the app delegate where you register your deep link router. The deep link router is where you put that routing logic to say, “If a user clicked a shoe link, load the shoe detail page and pass in the shoe ID,” and things like that. Perhaps on the shoe detail page you can add our share sheet which is the native iOS share sheet wrapped in Branch. It will automatically put deep links in every share message that goes out. That’s where you basically insert the shoe ID when a shoe link gets created to be shared with a particular user. Those are really the three high level steps to get setup with deep link routing and deep link creation. It’s all smooth sailing from there. You can check the dashboard for all your [00:25:53].

                    The other cool thing we just did too is we bought the app.link domain. We allow anyone to actually get subdomains and create their own subdomains on app.link. For example, the Imgur team has imgur.app.link, or you name it, any sort of cool labelling on your subdomain. You want the links look like yours which is really cool.

Jaim:             Very cool. One aspect of deep links that I didn’t immediately get is that once you have a URL anyone can launch your app. Do you have any way of preventing malicious people from logs from things?

Alex:             This is a common pathway and a concern for sure. You add all of these deep link infrastructure and you’re already modifying your link and trying to basically pass user data like your private information or even just malicious date of the crasher app. What we commonly recommend is you add this code for routing, you also make sure that you handle the case where you don’t recognize certain data. If the shoe ID for example does not actually correspond to a shoe in your database, what you’d want to do is just ignore it and make sure that you add that logic to correctly ignore it, or what’s common is some folks will actually bounds users out of the app into Safari and try to load that link in Safari so that the user doesn’t show anything malicious or there’s no crash or anything like that that would occur within the app. It’s definitely an edge case that you want to think through when it comes to routing. Unfortunately we can’t obstruct that because it is so unique to each individual use case. Consider the case of what if I don’t recognize the key in this data that’s passed through, or the URI path, or anything like that. You can even create a couple test cases as yourself and create a couple links that have kind of junk data on it just to make sure that you handle those routes.

Jaim:             Yeah, that makes sense. What are some examples of apps that are doing a good job with deep linking? You talked about Pinterest which is using a library, any other success stories that able to use to model what they’re doing?

Alex:             Yeah, sure. There’s a million, million different use cases. We’ve got a bunch of stories on our site too that really try to shine examples of really powerful deep link features. The GOAT one is a really compelling sharing use case. Just download the app and share some links and things, very powerful.

Another one which is great for folks just getting started, we’re good friends with actually a number of the dating apps use Branch like Tinder and Coffee Meets Bagel. There’s this app called The League that launch about two years ago. They created a really powerful feature kind of like a gated invite system. When they launch, they actually did even build out the dating app. Maybe they don’t want me sharing this too much but they only launch actually a registration page that had a counter of how many people were on the waitlist. What you could do is share the app with a friend to move up that waitlist. They basically created this really powerful growth channel. Users line up. They were so excited to get access to this dating app. They’d share it with their friend, get them to install the app, and they would move up on that waiting list. Once they actually launch the feature, or actually launch the dating service, they added another really powerful thing where they actually they made it a long approval process to actually get in and access the dating pools. There was this source constraint that made users want it more. Any user that got in would get a really powerful deep link that they could share with a friend as a golden ticket. The golden ticket when that user clicked on that link, installed the app or if they already had it, will immediately bypass that registration and waitlist process. They saw easily in the double digits growth. That’s a really powerful use case I think. The app is called The League if I didn’t mention that.

                    Another really great ones, if anyone uses Instacart for grocery. All their emails are powered with deep links. You receive an email to blueberries on sale or something like that. You click it, it’ll load the app, take you to that page, you can add it to your cart right away. According to the early numbers, looks like it basically just adding deep links so that the app opened up. It increase their conversion, who actually buy groceries, buy like three or four apps from what they were seen in mobile web. Huge, huge impact on their actual user experience and therefore conversions. Tons of tons of other really great examples on our blog in our website that I can refer you to if needed.

Jaim:             Definitely. Put a link in the chat, we’ll put in the show notes so our listeners can check it out.

Alex:             Alright, sounds great.

Rod:             Hey Alex, I was wondering if it ever make sense, say you have an app but you don’t have a website. Does it makes sense in that case to use deep linking at all or does it not?

Alex:             Oh yeah, totally. This is sort of the paradigm that we want to try to break free of. Your app is not just an isolated place where people install it, open it up, and then float through that story board. Deep links allow you to expand to the functionality of the app beyond its actual boundaries, that’s a little bit philosophical. From a high level perspective, just adding, sharing to the app, we actually have a really powerful feature called Diffuse that we expose in it’s totally free to use where you build your app, let’s say let’s go to the shoe example again, you’ve got amazing shoes in your app. You let your user share a link to a pair of shoes, you can enable deep views for that link or for all your links. What Branch will do is when that link is clicked and the app is not installed, we will actually show a mobile web rendering of that shoe. It’s actually a mobile website that we dynamically create an host on the half of the developer. That with a big called to action to go download the app. The benefit of that is that when the user clicks on that link. They don’t get sent straight to an app store page, they actually see the content that they clicked one. It’s just a much better user experience. The cherry on top is that we know because it’s a better user experience, most of the time people see increases in install rates from a clicks for those links because the user basically gets a preview of the thing that they’ll get in the app, and then they’ll go in and convert and download, and then engage with it more regularly. Whereas the alternative is you click a link, you get sent to an app store page which loses that context. If you click on a pair of shoes to get sent to an app store page is rather jarring from a user experience perspective. Having that preview really helps people convert. To be perfectly honest, we actually built the majority of the platform for users that don’t have apps. Lots of lots of powerful use cases for that context.

Jaim:             Very cool. Anything else we should cover before we get to the picks?

Alex:             No. I think you guys covered it all. If anyone wants to get started with Branch, you can just head to branch.io or find us in Google, all the usual stuff. If not, we’re happy to advise you on your own deep linking strategy. Just send us an email at integrations at branch.io. We’ll be happy to help you figure how to build it on your own too. With just more people, deep linking because there’s an industry benefit when we get the entire ecosystem adopting this tech.

Jaim:             Yeah, definitely. Since iOS 9 were directly supported by operating system so if you go to different app you can still go back to where you came from, which makes it a lot easier for [00:35:47] internal apps. If you’ve got your shoe seller’s app and your shoe buyer app, they don’t need to be the same app because the buyer doesn’t really care, generally. You can go back and forth and it’s a lot smoother process than used to be. Deep linking is a huge opportunity though, just improve your workflow, whatever your app is supposed to be doing.

Alex:             Yeah.

Jaim:             Cool. Let’s get to the picks. Rod, what do you have for us?

Rod:             I just have one pick this week. I got an Amazon Echo and I’ve had a lot of fun playing with it. I’ll just demonstrate. Alexa say hi. “Hi there.” That’s it. I’m enjoying that, that’s my pick.

Alex:             Nice.

Jaim:             Rod’s pick is setting all these data to Google, including the entire part of this podcast. Alex, do you have picks for us?

Alex:             I sure do. I’ve got three of them. They’re my crutches in life that honestly I couldn’t live without. I couldn’t function as a human being. First one is I love data and data analysis. One of the powerful virtues of Branch is we do attributions so you can tell where your installs actually came from, on top of all the deep linking functionality. You basically can really dive deep into growth and re engagement, and figure out where you use your server flowing from and flowing to, and all that kind of cool stuff. The tool that I use to all my data analysis, because I find that it’s incredibly easy to join tables, add filters, plug grasp, do everything, is the tool called JMP. It’s a bit pricy but they do have pretty cheap student version you can get. You can also do a free trial. Honestly I could not live without this tool. I probably use it I think two to three times a day. I don’t have demo but you can check out JMP on Google and just see what the tool is like. It’s essential for me.

                    The other thing that I recently bought, I’m a super cheap person, this was a really big move for me, is some of these really nice noise cancelling headphones. I got some of the Bose headphones. They’re like decorously over priced at $400. But honestly putting them on, you just feel like you’re in a totally different world. People can be talking around you, you name it, that could be music going on, and you can’t hear any of it. It made such a dramatic impact on my life as a whole. To be able to actually go into my headphones and just avoid the rest of the world. When you make that check out, you’re going to feel that pain of that cost but I guarantee, a month later, after you’ve been living in the headphone world for a while, you’ll be happy you did it.

Rod:             I do co-working so I’m with much different people. Without noise fencing headphones, I’ve got hear Bose too, I wouldn’t be able to do it. There’s so many distractions that keep you away. Definitely, if you use it while you’re working, they pay for themselves many times over.

Alex:             Yeah. It’s a no brainer. It’s like we’ve got to have it, it’s a crutch. The last one is actually a friend’s start up. I’m in bit of a coffee fanatic. I basically have to make all my coffee in the morning. I don’t do anything ridiculously crazy, really complicated process but I like the coffee strong and effective. One of my friends worked at basically a bean seller, a bean roaster for a few years. Just started a company around a new kind of coffee maker. That’s actually a mix of a French Press and pour over. He calls it a Coffee Steeper. You can find his site at, if you just look Fellow Coffee from Google you’ll find it.  What I do is you put in your ground coffee beans, you put in some boiling water, and you just let it sit for five to six minutes. Here’s a bunch of recommendations on temperature and ground quantity amount, and all that kind of stuff. Honestly, probably you don’t need to get into all of these details. Pour over, let it sit for four, five, six minutes, drain it, and it is super strong, really smooth, and just a very delicious cup of coffee and easy to make. I’ve honestly couldn’t live without that in my life either. Coming in with an espresso maker in the office, it’s just nowhere near as effective as the Coffee Steeper. I highly recommend it.

Jaim:             What does it do? Say if just the French Press?

Alex:             It’s nice because it actually has a filter. You don’t have to worry about a bunch of very hefty grains getting caught in there. You’ll basically get actual clean coffee. You won’t be buy bean coffee, tea or up. It’s the pour over with a filter but also the French Press kind of style and taste which is awesome.

Jaim:             Ah, very cool. I’ll check it out.

Alex:             Yeah.

Jaim:             Thanks Alex.

Alex:             I highly recommend it.

Jaim:             Thanks for stopping by. We learned a lot about Branch. If you’ve done deep linking yourself into these apps, you know it’s a pain so I think Branch is a great way to simplify a lot of our lives. I’ll definitely going to check it out next time I have to do some deep linking in an app.

Alex:             Nice. Thanks so much for the opportunity. I hope everybody adopts it as quickly as possible because the possibility is once you do you’re endless.

Jaim:             Very cool. Alright, we’ll talk to you all next week.

 

x