Stop pretending mobile is the web (and vice versa)

Summary

Highlights

• Theo discusses the misconceptions developers have about web and mobile platforms. 🤔📱🌐
• There are significant challenges in deploying mobile apps compared to web apps. 🚀📱
• Infinite Red is praised for their React Native expertise. 🔥📲
• Theo critiques Apple and Google's app store dominance and monopolistic practices. 🔍🛑
• The navigation stack on mobile adds layers of complexity not present on the web. 📚🔄

Key Takeaways

• Web and mobile are fundamentally different platforms; don't confuse them! 🌐📱
• Deployment on the web is easy, but mobile requires navigating app store hurdles. 🚀📱
• Apple and Google have a tight grip on app deployment, affecting developer freedom. 🍏🤖
• Navigation paradigms differ significantly between web and mobile, affecting user experience. 🔄🧭
• The future might bring smoother mobile deployments, but there's work to be done. 🔮📱

Overview

Chapters

• 00:00 - 00:30: Introduction: Web vs. Mobile Platforms The chapter "Introduction: Web vs. Mobile Platforms" focuses on highlighting the differences between web and mobile platforms. The author emphasizes the importance of understanding the nuances between them, rather than viewing one as a lesser version of the other. The discussion aims to delve into the philosophy of developing quality software tailored for each platform, addressing misconceptions held by many developers. The chapter is not centered around specific technologies like Flutter, React Native, or Native, but rather on the broader principles of app and web development.
• 00:30 - 01:00: Fundamental Differences Between Web and Mobile The chapter discusses the fundamental differences between web and mobile platforms. It targets both web developers building for mobile and mobile developers building for the web, aiming to provide a foundational understanding for each group on effective development practices for these platforms.
• 01:00 - 02:00: Today's Sponsor: Infinite Red The chapter discusses the benefits of collaborating with Infinite Red, particularly in the context of developing and refining React Native applications. Infinite Red is portrayed as a highly capable consultancy with deep community roots, offering a range of services from onboarding boot camps to full-scale app development. The chapter highlights their expertise and reliability, especially emphasizing the involvement of community-focused individuals like Jamon.
• 02:00 - 06:00: Deployment Complexity: Web vs. Mobile This chapter explores the complexities involved in deploying web and mobile applications. It highlights the expertise and recognition of Infinite Red, a company that has collaborated with prestigious brands like Amazon, Expensify, and Starbucks on various projects. The author emphasizes the credibility and trustworthiness of their acquaintance, Jamon, who is a significant supporter and deeply involved community member. The chapter underlines the trust these brands have in Infinite Red's capabilities, as evidenced by their recurring patronage, and suggests trusting the author's positive opinion of the company.
• 10:00 - 13:00: Legal Challenges and Platform Restrictions The chapter discusses the legal challenges and platform restrictions encountered while developing a mobile app for T3 Chat with the help of Infinite Red. The author expresses strong trust in Infinite Red, showcasing their reliability and commitment to the project. They highlight the significance of routing as the primary difference in their project, with a promise to elaborate further on this aspect.
• 28:00 - 33:00: Monopolistic Practices in App Stores In this chapter, the focus is on understanding the nuances between web platforms and mobile platforms, particularly in the context of monopolistic practices in app stores. Key differences are highlighted in terms of platform capabilities such as interfacing with cameras and storage, and the background abilities of applications. Furthermore, the chapter delves into the challenges of deploying and managing different versions of applications, which are distinct from web platforms. This exploratory dive aims to shed light on the complexities and frustrations associated with working with app stores.
• 34:00 - 60:00: Routing and Navigation: Web vs. Mobile The chapter 'Routing and Navigation: Web vs. Mobile' starts by highlighting the importance of routing and the complexity involved in the topic. The discussion kicks off with deployment processes for web applications. The speaker assumes the audience has a basic understanding of web development or has at least built a modern website. For those unfamiliar, a quick walkthrough of deploying on the web is provided, beginning with basic HTML structure.
• 71:00 - 72:00: Closing Remarks: The Future of Web and Mobile Development This chapter discusses the intricacies of deploying web and mobile applications. It highlights the simplicity of web deployments, even when projects become more complex, due to straightforward deployment pipelines. In contrast, mobile development presents a higher level of complexity in deployment. The chapter emphasizes that while initial projects might seem simple, the underlying difficulties in expanding and deploying them, particularly for mobile platforms, reveal significant challenges.

Stop pretending mobile is the web (and vice versa) Transcription

• 00:00 - 00:30 We talk about the web a lot on this channel. We talk about apps occasionally too. Not enough though. And today I want to try and balance that out a bit. Not by just talking about apps non-stop, but by trying to highlight some of the differences between how apps work and how the web works. This is going to be a bit of a deep dive on the philosophy of how to build good software for different platforms. I find that a lot of developers think that one platform is just a worse version of the other and seem to fundamentally misunderstand some of the nuances between them. This isn't about Flutter versus React Native versus Native. This isn't about how we should
• 00:30 - 01:00 embed web apps into our mobile apps. This is about the fundamental differences between the platforms. So, if you're a web dev building for mobile or mobile dev trying to build for the web, this might be a good starting point to better understand how to do the right thing for these different platforms. I'm really excited to dive into all of this with you, but before we can do that, I need to get paid. So, a quick word from today's sponsor and then we'll dive right in. I need to be honest with y'all. It's never been easier to build a web app. But mobile apps, as much as they've improved, it's still nowhere near as smooth to get started and it's way too easy to get things wrong. That is unless you hit up today's sponsor
• 01:00 - 01:30 first. Infinite Red will get you going the best possible way with your React Native app. If you already have a React Native app that you're trying to polish up and make easier to work in, or you're trying to build one from scratch, or you're trying to move a native app over to React Native so more of your company can contribute, there is no better group to reach out to. They'll do everything from onboarding boot camps to building the app from scratch for you guys directly. And if they were just some random consultancy, I'd understand the concern, but they're not. These are some of the most deep community people I know. When I first switched the sponsor model over, Jamon was one of the first
• 01:30 - 02:00 people to reach out. He's been a good friend of mine and one of my first supporters forever. He sees basically everything that we do. He's been a deep community member. Ask any of the people who are regularly in chat. They probably watch Jamon's podcast. He gets it. You don't have to take my word for it either. Look at the incredible list of brands that have worked with Infinite Red on all sorts of different products. They've helped out everyone from Amazon to Expensify to Starbucks, and the results speak for themselves. These companies keep coming back for a reason. Infinite Red is awesome to work with, but if you do trust my word, you might want to know that I'm almost certainly
• 02:00 - 02:30 going to be working with Infinite Red on our mobile app for T3 Chat. They're the only group I trust enough to really commit in that type of way. Yeah, I'm going to bet my whole business on these guys cuz I do trust them that much. Whether or not they were sponsoring me, I would recommend them in a heartbeat. The fact that they are makes it even easier to do. So, thank you again to Infinite Red for sponsoring today's video. Check them out today at soyv.link/infinite. So the biggest difference by far, I think it's important that we acknowledge this first and foremost is routing. We'll dive a bit more into what that means in a bit. Second big piece we'll
• 02:30 - 03:00 definitely need to dive into is the platform. Web platform and mobile platforms are very different and there's a lot of nuances here that we need to consider. Next we have the capabilities which is kind of part of the platform but it's different enough that it's worth talking about things like interfacing with camera storage all of that stuff. also background ability of your applications and possibly the most frustrating one deployment. The process of deploying and managing different versions of your applications is very different from the web. I think this is
• 03:00 - 03:30 a good starting point for us to work from and we'll certainly go down a lot of different tangents throughout all of this. Routing is going to be a long one. So, I kind of want to just start with deployment. Yeah, let's do that. I'm going to assume most of the people watching here are already web devs or have at least built a modern site. But for those who aren't, I'm going to show you how easy it is to deploy on the web really quick. Let's touch index.html. Now we have our wonderful
• 03:30 - 04:00 HTML file here. Let's throw it on the internet. MPX forcell deploy. Yes. Yes. No. Demo deploy. It's fine. We're done. What a difficult challenge. Deploying for the web is so hard. Obviously, this is a very simple, rudimentary project, but we could build something more complex here, and the deployment pipeline doesn't necessarily get more complex. On the mobile side, that isn't true. The level of complexity
• 04:00 - 04:30 just to get it out is really high. But as the application gets more complex, it doesn't necessarily get that much harder to deploy. If we were to think of this in terms of like difficulty relative to the complexity of your app, we'll say this bottom axis is app complexity and the other axis, the y-axis here is deployment complexity. When you're deploying web apps, the complexity of your web app doesn't necessarily meaningfully increase the
• 04:30 - 05:00 complexity of your deployments. It starts off super simple to deploy as long as your app is simple. deployment should be. As your app gets slightly more complex, the deployment complexity goes up slightly as well. With mobile, this is a bit different. You start at a much higher level of complexity, and if you have things like additional permissions or things that Apple's annoying about during review, it might get slightly more complex, but not a lot more. So, you have a very slight curve up in the complexity of deployment as your app gets more complex, but you also start at a much harder point. And this gap is something I talk about a lot when
• 05:00 - 05:30 I'm comparing web apps and mobile app like developer experiences because this gap sucks. It's so easy for somebody working on a project on the web to just get it out for people to try. If I'm building a web project and I want my mom to try it out quick, I can just send her a link and now she can try it. If I'm building an app and I want my mom to try it out, I better already have her on test flight. If I don't, good luck. Have fun. I think this is one of the biggest misses of application platforms like iOS and Android. In a world where we have
• 05:30 - 06:00 tools that make it easier than ever to generate experiences like all the cool AI app builders and whatnot, this gap sucks. The actual process of building the app, I can get real far with the complexity, but now I have to be a wizard with the app store if I want to get it out to people. And that sucks. If I can get from like here to here in a day using all these awesome tools and technologies, but then getting it deployed up here takes a week of dealing with Apple's That sucks. And Android's no better here. In many ways,
• 06:00 - 06:30 Android's actually worse, believe it or not. So, yeah, deployment is rough. The biggest reason why this is the case is kind of a benefits and negatives of capitalism thing. The web's a relatively free market. There are so many options for deploying to the web. I'm using like five of them right now and there are more coming out all of the time. You have awesome options like Verscell that take advantage of modern web tools and technologies and will autob build, deploy and scale them for you across serverless environments. You products like Netlefi that make that even easier for companies trying to add modern web
• 06:30 - 07:00 infra on top of their existing older legacy stuff. You have companies like Cloudflare making it really easy to process data anywhere in the world and deploying it's gotten easier than it ever used to be. We even had revolutions back in the day like our friends over at Heroku that was groundbreaking at the time and set this new bar for the experience of deploying your applications. On mobile, we kind of just have Apple and Google and the occasional effort to streamline parts of the process like Expo, but it's so much harder because you're not building for
• 07:00 - 07:30 the web and for servers, these generic things. You have to be building for very specific chaotic platforms that change their expectations all of the time. It is significantly harder to build an expo than it is to build a Versel. The crazy bold statement I'm going to make that I honestly like fully believe I could build an MVP of Versel in like a week. I couldn't build Expo. This might sound insane, but I like 1,000% believe it.
• 07:30 - 08:00 Deployment platforms like Versell are incredible in what they're capable of. I wouldn't be able to replicate some of the awesome infrastructure stuff they're doing, but the idea of link to a GitHub repo, deploy it on AWS for you, I could even DIY for a platform like Azure, which I barely know if I really wanted to. Expo I couldn't do like Expo application services is an incredible achievement in software development in the fact that they've actually made it easier to take code on your computer and get it built and deployed for native apps. But god, it is tough to get going.
• 08:00 - 08:30 And even when you're using EAS, you're going to run into problems because these platforms are so weird. Jam's in chat. If you don't already know him, he's the CTO of Infinite Red. He's an old friend, fan of the channel from before any of you guys knew who I was. Also, good chance that they're the sponsor of today's episode. If not, they'll be sponsoring other stuff in the future. They're awesome to work with. If you're looking for help with your React Native app, hit them up. This part isn't paid for. This just like love these guys. Even Jamon, who is like the mobile wizard here, says the the amount of hours he spent in Apple and Google's
• 08:30 - 09:00 consoles with certificates provisioning profiles, he could have had another kid. That's Yeah. And I don't know how much work a kid is, but I know it's a lot because that's insane. Yeah. Also called out the fact that Expo initially had Expo Go on the App Store where you could send a URL or QR code and anyone could load it on their phone and it was glorious. Apple sadly killed that a few years ago. Yeah, if you're not familiar with Expo Go, it's one of the really cool things the Expo team made. They made it so when you're working on an app locally on your like laptop, instead of
• 09:00 - 09:30 having to rebuild it and ship a new native binary to your phone every time you made a change, you could open up their client called Expo Go. You can scan a QR code that gets generated in your CLI and now your phone is running the code from your computer with hot reloads. You save in your code file in your editor of choice and your phone auto updates with the latest version. It's awesome. Somebody is saying this is a lie. Expo Go still works and exists. It does for local dev. The thing you do before that was really cool is you could deploy that QR code on a server
• 09:30 - 10:00 somewhere at an actual URL and a user can now scan it and in their app on their phone load the data from the network to try out your app. It was really cool. It wasn't Snacks. This was its own separate thing, but Apple squashed it because people were using it to use software that Apple hadn't approved of. My hot take here, and this is something that I one of the reasons I really wanted to make this video, Apple's reign might be over. I've been keeping a close eye on the different
• 10:00 - 10:30 court cases between Apple, Google, Epic Games, and a couple other parties of interest, and the Google case in particular was disastrous. The final results of that Google case were unbelievable. I hope I'm not misquing any of the parts here, but if I recall, it was a five-year ruling on Google that they have to first off allow all other app stores to have full access to the Google Play Store catalog. This is
• 10:30 - 11:00 insane. The fact that the judges ruled that Google's monopoly was so absurd and potentially illegal that they had to counteract it by allowing every other app platform to have full access to their app catalog for 5 years. They also have to allow other app stores to be distributed through Google Play Store. Genuinely insane. So you can once this all gets inked, you'll be able to
• 11:00 - 11:30 install Epic Store or Amazon Fire Store through the Play Store. And arguably most importantly, Google cannot pay manufacturers to exclusively bundle their app store anymore. So previously, Google would pay a company like Samsung to only have the Play Store and not other stores. Google really wanted Play Store to be the only platform for apps on Android. They lost so hard in court that they might be the least popular platform for apps on Android in the next
• 11:30 - 12:00 couple years. Genuinely insane. I am hyped on this ruling because both Google and Apple run their stores in a way that I would argue if it's not illegal, it should be. You should be able to install software of your choice on a platform as important as your mobile platforms. When a user purchases a phone, they don't think about the applications that they're restricted from using. If you bought an iPhone in 2020 and then learned in 2022 that you couldn't use the Xbox game streaming app because
• 12:00 - 12:30 Apple decided movie streaming and music streaming is totally fine, but game streaming is a remote software platform, which means it's an alternative to the app store. So, they're not going to allow it. That is and that shouldn't be allowed. Apple should not be able to control what different app categories can exist and what different experiences users can have on their device. Needs to change. I think it's starting to change now. This Google ruling makes Apple's previous wins much, much more fragile. Having this as a precedent means that the next time
• 12:30 - 13:00 someone sues Apple over restrictions that they're experiencing on the App Store, they are much more likely to win in court. The reason I'm saying all of this, and this is not legal advice, I am not a lawyer. I am not qualified to even really be talking about some of this stuff. Let's be real. I want someone to challenge Apple. What do I mean by this? I mean, one very specific thing. My dream is that someone who has an idea for an app, be it something really cool or even something dumb like a game about them and their friends and a creator
• 13:00 - 13:30 world type thing. Imagine they could prompt for that app to exist using Bolt, V 0, A Z, whatever they use for it. They get something really quickly that they could play on their phone and be impressed with and proud of. Now they can screenshot a link or a QR code or something, send it to a friend, post it on Twitter, show it off on Tik Tok. Now you as a person on the other side can screenshot that. So I'm watching a Tik Tok. They say, "Hey, if you want to try my app, use this." You screenshot it.
• 13:30 - 14:00 You open up the magic platform, whatever you want to call it. We'll call it TMP for now. You open up the TMP app and it has access to your photos and it sees that you have this in your screenshots. instantaneously opens that experience by loading whatever code it needs, probably React Native or something like it. So, it can control this native layer. I really want this. It's almost like Expo Go 3.0 is what I'm imagining here. The problem is none of the big players can do this because they're risking getting in bad standing with Apple. If you don't
• 14:00 - 14:30 care about your standing with Apple, you should consider doing this. Let me know if you do. And once you have it working, let me know if you're taking checks. I think there's a really good chance of somebody with the right incentives doing something magical here. The catch being Apple will be fighting you every step along the way. There's a lot of other edge cases to figure out throughout, but if you can pull this off, you can do awesome things. And I do genuinely think Apple will struggle more than they ever have before to get you off the app store without a potential massive legal issue.
• 14:30 - 15:00 And if you can get Tim Sweeney from Epic on your side throughout this, you'll actually probably win. Anyways, there are a lot of other pieces of deployment. Due to this complexity curve, you have a ton of additional problems. The one that I care the most about is keeping users on the latest version. If I have a bug, here's here's an actual experience I had at Twitch. We were building the mobile app for a certain size of phone. We'll call this uh normal phone pro. So, the
• 15:00 - 15:30 normal phone pro is this size. All of a sudden, Apple puts out the normal phone mini. Sorry, not Apple. We'll say this random company puts out the normal phone mini and it's slightly smaller. Even meaningfully smaller. We'll pretend it's slightly smaller. If we had a bar somewhere in this UI, let's say we just had like one, two, three, four. This is our UI. We have these four buttons in this bar at the
• 15:30 - 16:00 bottom here. Oh no, button four is getting cut off because the phone is smaller. We didn't expect the flex of the display to get to that size. In the webdev world, we're used to having cool things like flex containers. In the mobile world, especially on iOS, there used to be a limited enough set of different resolutions that you would hardcode a lot more stuff. But if a new resolution of display came out or a older one that hadn't been touched for a while came out, dealing with the smaller sizes was really problematic. So, why am
• 16:00 - 16:30 I bringing this up here? Because we fixed this bug as soon as we saw it and we got reports about this bug for the next year and a half. Why in the world would we continue getting bug reports if we fixed this in 2 days for 2 years? The reason is because they didn't update the binary on their phones at this point in time. If you were on an old version of the Twitch app, it wouldn't do anything about it. You'd just be on the old version. Since then, the Twitch mobile team made a change where it will pop up in the app really aggressively saying,
• 16:30 - 17:00 "Hey, you need to update. You need to update. You should go install the latest version." But before then, we would have as much as 50% of users on an old version over one week after the latest shipped. This was very common. And there's a lot of applications that still deal with this every day. On iOS and Android, it's not a guarantee that users are on the latest version of your application. there's no way to really force it if you're all in on native. As such, a lot of these companies have
• 17:00 - 17:30 moved away from having the whole experience be native. Let's say that instead of this tab bar being Swift code that's hardcoded into your app, the code that actually renders each of these buttons might be swift code, but the thing that says one goes here, two goes here, three goes here, four goes here, that might come from some JSON fetched from the server that describes how to lay out the app. This is really common for things like a news feed. If this app had a feed in it, we might have a text post. We might have a video post, but we
• 17:30 - 18:00 also because it's the holiday might have a St. Patty's Day post. And if we want to make this new custom type of post in our app that is its own layout, its own view, maybe it has some fancy like animation in the middle or the text is green or something, we need to get this in the app weeks if not months ahead of time because we need to get this in the app, put it under a feature flag, hide it, whatever we need to do there, and then when St. Patty's Day finally comes around, we can support this unique type
• 18:00 - 18:30 of post because we already embedded it in the app. But if somebody's on an old version of the app and they never installed the update with the St. Patty's Day post type. This might error out. It might render wrong. It might just fail. Okay, it's St. Patrick's Day. You guys are gaslighting me. I'll just call it the full thing so you guys stop doing this. Anyways, if you don't have the code for this in your app already, it can't render it. And you can all imagine what the JSON for this looks like. Hopefully, you understand what I'm trying to show here. You hit some API to
• 18:30 - 19:00 get the posts. And each post has its type, its content, whatever other things it expects. And now our app has to take the fields from here. It uses type to figure out which component or UI element to render. It then uses content or URL or whatever else that post component type expects in order to render the right view for that. This pattern works great until you're changing the post types and the users don't have the latest version of the app to show the latest type of post. So what a lot of companies have started to do instead is they don't send this data. They send
• 19:00 - 19:30 what's called server-driven UI patterns where they describe what this post should look like instead of just sending down this JSON. So instead of type St. Patty's post, they might send down something that looks closer to HTML in order to get that data to the app so it can render the shape instead of rendering the content in an existing shape. The way of thinking of this is you have two parts that matter. You have the box in the app, the component, so to speak, the shape of how the thing should render, and you have the data, which is the part that needs to get stuffed into
• 19:30 - 20:00 the app in order to turn that box into the thing you see. It's the whole like uh UI equals a function of state or in this case data. The problem is that the state doesn't have enough information to describe the UI if the function, which is what makes that UI, doesn't have the right pieces yet. So if we want to be able to send new things to our users without knowing what version of the app they're on, then state has to include more of the UI. It's a balancing act.
• 20:00 - 20:30 How much of the way the UI looks gets put in the state versus into the application binary itself? Native apps have historically had to lean heavily on the native layer. So they've had to massage all the different ways the JSON can come in, filter out things they don't know how to deal with, or just error out if you're on an old version. But if the server sends the shape this should be rendered in, the version of your app matters a hell of a lot less. This is why every company from Facebook to Google to YouTube to Slack even has started moving towards the UI being defined by the server rather than by the
• 20:30 - 21:00 application binary itself. Now what if I told you the F part here could come from React Native. Then this whole paradigm becomes much easier, but that's a discussion for another time. The core point we're trying to make here is that we've had to fundamentally change this relationship in a way that we've never had to worry about in web in order to make sure we can render all the different things the server needs without having to wait for Apple to send the app to users knowing some of them will still be on the oldest version no matter what. I think this covers everything I
• 21:00 - 21:30 need to say about deployment. I have a feeling it's going to be a long video. Let's do a slightly shorter one quick. I say self-aware knowing how bad this will be. Let's talk about the platform. This is one of those slightly more nuanced things that web devs struggle to appreciate, but mobile devs struggle to appreciate from the web. All of these platforms are very different. The platforms being at least the core ones iOS, Android, and web. These things
• 21:30 - 22:00 are all very different. We'll start with the one that most of us are probably the most familiar with, which is web. Web is a open standard. Putting it in quotes because people will fight about that. I don't care. It is genuinely relatively open. It has lots of computing implementations. Whether or not we want to admit it, these implementations are surprisingly compatible. Like I'm in a Firefox based browser right now with Zen and I keep open my Chromiumbased browser
• 22:00 - 22:30 for all the mostly for the dev tools. There's a lot of things I'll say about how if the Firefox platform is behind, but it's 99% of the way there. Pretty insane that it's gotten as far as it has. It's really cool. And there's a lot of other benefits to the web being an open platform and open standards. It means that you have lots of options on how to solve problems. Things like how do you process payments? How do you store data? How do you interface with the web? What API methodologies do you
• 22:30 - 23:00 use? What technologies do you use to build the application? How do you deploy the application? All of these things are part of what makes the web great. You have so many options for almost every layer. iOS and Android less so. iOS is certainly not an open standard. The term people use a lot is walled garden. I think that's fair. They for some reason open sourced Swift, but I haven't actually seen anyone using it for meaningful things that aren't Apple platforms. The closest thing was Arc and
• 23:00 - 23:30 we watched how that went. It has two blessed options for most of what you do. You have the core UI kit like the original Objective C based application platform layer and now you have Swift UI as well. The reason you have Swift and Swift UI as well as the old core UI kit and Objective C stuff is because Objective C is an ancient decrepit language that's a bit of a mess. It's rough. And Swift UI, funny enough, was an attempt at learning the right lessons from tools like React to try and make
• 23:30 - 24:00 application development way less bad. And if you want to see how the iOS community feels here, check this out. Almost immediately in chat, Objective C is better than Swift. Swift is really underrated, though. Yeah, that's where we're at here. There's even still debate internally about the two blessed options and both of them have lots of catches and I would argue neither are properly complete. Now it's a bit rough. It also both of those are very much Apple
• 24:00 - 24:30 platforms. If you build an app in Swift and Swift UI, it might work okayish on Mac, but you're not getting that working anywhere else. Rough. It's also worth noting Swift UI was announced in June of 2019. React was announced in May of 2013. It took Apple six years to learn the lessons that React taught us and it still is trying to apply them. I know a lot of devs still aren't using Swift UI because they still don't consider it stable enough. This is the problem
• 24:30 - 25:00 though. You can't really build a better app platform or native UI layer on iOS or Android because we're kind of relying on the platform itself to do it. Unless you're Flutter and you just ignore the platform entirely, which turns out is a lot worse. The capabilities of these devices are incredible, but the expectations of users are really high. And those expectations are that applications behave in certain ways because they're used to their phone working in a certain way. When Flutter
• 25:00 - 25:30 announced their 3.29 version, I went and read the blog post and I you not, the first screenshot in the blog post had the worst alignment I've ever seen in a search bar. They're aligning on the bottom. Are you kidding? This is the default. This is their example. And whenever you use a Flutter app, you'll get this weird uncanny valley feeling. And this isn't just like devs or people focused on this will get it. My mom felt the difference when she tried using the eBay Motors app for the first time. It's
• 25:30 - 26:00 bad. They And this like since I flamed them, they hid this. By the way, this is no longer at the top of the blog post. It was right here before. They deleted the screenshot because I ratioed them. It's it's not good. And that's kind of the problem though is we have this expectation now. And if you try to build without using the native parts, without using the core UI elements that exist on the platform, you either have to recreate them to meet the expectations that users have or you have to do
• 26:00 - 26:30 something so different that users expectations are subverted and circumvented entirely. There's also a huge important piece to all of this, which is accessibility. Apple did a great job of building good accessibility into these native elements. If you use an actual button or touch element inside of Swift UI and you label it properly, that will work great for a user with a screen reader. And that's genuinely awesome. The fact that iOS, if you use everything in the platform properly when you're building an app, makes an experience
• 26:30 - 27:00 that's great for people who are blind, hearing impaired, or have any of many other things that make navigating software harder. Apple is genuinely groundbreaking in the accessibility space. One of the best companies when it comes to that. And I, as silly as it sounds, when they do their accessibility commercial every year or two where they show something incredible, when they showed the paralyzed woman editing her own commercial, I cried. Like, it's I don't know. Like if you've never met one of these incredible people that
• 27:00 - 27:30 work so much harder to get things done in a piece of software, I implore that you find someone you can talk to about this because it's the the challenges people have to go through with accessibility needs to do things that we do every day. Something as simple as a drag and drop interaction is entirely inaccessible to hundreds of thousands if not millions of people. Apple has made incredible strides here with their mobile platform and with their mobile STKs. But if you go down a different path at all, you have to reroll pretty
• 27:30 - 28:00 much all of that yourself. You lose all of the benefits of Apple's platform in how it benefits accessibility if you try to roll your own. So, you end up locked in in a way where if you're not building like a game, you pretty much have to build into the platform. any other option is borderline irresponsible and hurting hundreds of thousands if not millions of people and their ability to use your software. It's a good thing that React Native uses the native platform, isn't it? But yeah, you get
• 28:00 - 28:30 the point I'm trying to make here. The platform is good and they've done things no one else can do. The web will never be as accessible a platform as iOS simply because they built it from the ground up with this in mind. And the standardization that they've pushed for has allowed for things that are not possible on the web as old and like supported as it is. It's incredible. Pivoting from incredible, we need to talk about Android. Android is technically open source. It's also technically Linux. It's forked hard enough now that it's hard to say that in
• 28:30 - 29:00 good faith, but in almost every other way, it's like iOS, but more jank. There are good things. Cotlin's an awesome language. I've been meaning to do an indefensive Java video for a while, but using Java in the JVM for an operating system is such a cursed idea that we should never have let it happen. Ah, yeah, it's Android's a interesting beast. I used to be deep in the Android world. I used to contribute to custom ROMs all the time and even try contributing to Android core. It was my favorite thing in the
• 29:00 - 29:30 world when I was in high school. And then iOS 7 came out and rewired my brain. Regardless, the the thing I want to emphasize here is you probably should be using the Android platform, but it's also fragile enough that something like Flutter makes a lot more sense on Android. It's actually relatively similar to the native runtime on Android. It's also part of why using Flutter on iOS makes it feel like a crappy Android app. Just remembering the Flutter people. Oh god, what do you have here? Yeah, when you select text in Flutter web, it puts an actual DOM element of text and tries to overlay it exactly where you select the text and
• 29:30 - 30:00 misses like 30% of it when you try to do so. This is the stuff Flutter has to do in order to make it accessible because it's not using the platform. It's using its own layer on top of the platform and then it still has to fall back on the platform in order to do basic things like accessibility. I'm about to show my knowledge gap a bit. I hope I don't regret saying this. Jetpack Compose is supposedly really good. This is the tooling ecosystem around building and bundling for Android. I've heard it went
• 30:00 - 30:30 from absolute garbage to actually surprisingly good now. That's awesome. It's crazy to think that Android went from comically worse development experience than iOS to arguably slightly better, but it has. I actually like full transparency a big part of why I was contributing to things like cyanogen mod is it was easier to modify Android itself than it was to build an app for Android. Nonsense. But yeah, I've heard really good things about the state of the Android ecosystem nowadays. Good to see cuz it was horrifyingly bad before.
• 30:30 - 31:00 The core point here being if you drift too far from the native platforms for either of these, you end up in a lot of pain. There are benefits to these platforms though compared to the web. The one thing I didn't say here is the web can never deprecate anything. There are so many APIs in the web that are subpar that can't be changed because there are millions of websites using them in their current, often broken states. It's horrifying.
• 31:00 - 31:30 One of my favorite examples of web deprecation being a problem is Smoosh Gate. If you're not old enough that you had to bang your TV to try and fix the reception, you probably have not heard about this. So, for everyone here who hasn't, a while back, we didn't have a way to flatten arrays. If you had an array of nested arrays, you wanted to flatten it, you're kind of screwed. There were a couple libraries that did this, and at the time, we were all using them. Things like moo tools, jQuery, stuff like that. But the web standards committees wanted to make this an actual web standard because it's a
• 31:30 - 32:00 common enough thing. It should be in the standards. What we did initially is array.flat. So you'd have an array like this that's like triply nested. You call array.flat and it would flatten it. You could call it with flat and a number like infinity and it will keep calling in order to make it truly properly fully flat. This is also the proposal that flat map came from which is like my f I I abuse flat map. I use it places I probably shouldn't. It's so nice. The issue is that they wanted to go with flatten but they couldn't. When you
• 32:00 - 32:30 install new tools it would override the array prototype key for flatten and would make its own implementation of it. in their implementation was different from the one that web standards was trying to do. So if they were to name the new web standard flatten, that would conflict with and break for moo tools users. Terrifying. Really bad. Because it would have break on a ton of websites, they had to name the API differently and implemented in a different way in order to not break for people using this older library when they implemented this. Insane. And these things happen all the time. Thankfully,
• 32:30 - 33:00 libraries know better than to just constantly override array prototypes now. But if they didn't, this could be bad. This is the state of the web platform, though. By supporting everything forever, by being able to go to a website from 20 years ago and expect it to work now, they can't deprecate things. They can't remove things. They can't change how things work. Sometimes I wish Apple operated that way because they changed how Swift UI worked every single major release for like four years straight. But that's the the difference here. One last thing on
• 33:00 - 33:30 the platform, and I've been touching on this here and there. Tools should be built on top of it. There have been attempts to build things for the web that aren't built into the platform. The biggest two being Flash and Java, the reject of the bunch being Flutter. These technologies aren't part of web standards. None of these are standardized. Java kind of is, but barely. These technologies were attempts to build different things into the browser via native plugins that were part of your operating system, not the browser itself, that would allow you to
• 33:30 - 34:00 run different experiences. Flutter obviously uses canvas in the browser, but Flash and Java were both things you would install on your computer and use as plugins inside of the browser. This allowed for the web platform to advance way quicker because at first the web wasn't very interactive. Flash and Java were almost exclusively interactive. So all of a sudden we could embed these things and do things the browser couldn't do before. And I still dearly miss the flash game revolution. We haven't had anything to properly replace it since. I do actually have a video
• 34:00 - 34:30 planned in the near future called the or in defense of AI games where I'm going to be talking about the relationships between the new AI game building things people are doing and the old days of flash that I grew up on. I probably wouldn't be a programmer if it wasn't for how I fell in love with flash games at the time. We have since built the things into the platform that you would otherwise have had to need and use Flash and Java for, but those standards are harder enough to use that we haven't seen a level of
• 34:30 - 35:00 innovation and genuine like revolution in particular small games that we had with Flash back in the day. And it breaks my heart every time I think about it. These were all attempts to try and build something that wasn't part of web standards into the browser. And there's a reason all three aren't things we expect to use in web pages anymore. Building things on top of the web platform sucks because the web platform will always win in the end. And if you have something that kind of works in the browser that you're building it in, the chances that your abstraction will work
• 35:00 - 35:30 properly in other browsers and other places is relatively low. I wouldn't be surprised if Flutter's crazy canvas hacks broke entirely in Safari. I wouldn't be surprised if Flash didn't work in Oh, wait. It didn't work in iOS because Steve Jobs refused to let it. And when it did work on Android, it did not work on Android. Let me tell you, as one of the Flash dieards, when I was in high school, I was so hyped for my Android phone to have flash. I tried two Flash games built for Android, and they were both so broken and not able to handle touch and like low latency, anything that I just stopped using flash
• 35:30 - 36:00 games on my phone. Also, the they ate my battery. I you not. My Droid X's battery probably died in an hour of playing a flash game. Not even. So yeah, these allowed for us to move faster, but they also died because they showed us where the web should go. They were rough enough that they didn't stay along for the ride. So what about iOS and Android? We've had attempts here, too. We've had things like Cordova and Ionic, which were attempts to build basically a
• 36:00 - 36:30 browser that has some native platform access. Not good. I've never used an app built on these technologies that I actually enjoyed using. We have obviously React Native. We had uh what was the other one that Microsoft acquired and slowly died? Zamarind. Yeah, Zamarind. Oh, Samarind. That was such a disaster. And once again, our friends over at Flutter. Time for one of my hotter takes here with the web. We have an open platform. Because the web is an open platform, the web is a platform with a lot of different options
• 36:30 - 37:00 in how we consume it. Because the web has a lot of different options in how we consume it, guaranteeing that any one of these abstractions will work on the majority of web platforms is basically impossible. That's why these first two required you to install something native in order to handle it. And that's why Flutter isn't something anyone actually sincerely uses for the web. On mobile, we don't have one open standard with thousands of implementations. We have two platforms. They're closed, but they're limited. They're large, but they're limited. So theoretically, if we
• 37:00 - 37:30 could build the right layer on top to have one piece that uses the right thing on iOS and the right thing on Android, which will be different by the way. The problem with web is everything has its implementation, but the implementation might behave differently across platforms giving you a hell to build on top of. With something like React Native, you can use the different specific native thing like you can use the native tab bar in iOS and you can use the native equivalent in Android that are two separate things that are
• 37:30 - 38:00 two separate standards. It ends up being much more work overall, but once you've built that platform, you can actually consistently call native things from this abstraction much better than you can do through something like Flash. And this is unintuitive because the web has one standard, mobile has two. So wouldn't it be easier to build a platform on top of the one standard rather than the two? Turns out no because of the variety within this one standard. Because these two platforms are relatively locked in even though
• 38:00 - 38:30 there's twice as many platforms, they are very consistent because there's just one implementation of each of them. If you put the effort in like Meta did with React Native, they have 300 plus engineers that have worked on React Native over the years and plenty more from other companies like Microsoft and Amazon. They've put in the effort to build this abstraction and the platforms themselves can't really change enough or differ to cause problems. The result is something genuinely impressive. With some of these options, you can actually use the whole native platform, which is
• 38:30 - 39:00 really cool. Wish it was more of them. The platform is a very important thing to consider. Platform capabilities. There's a lot of cool you can do on a platform like iOS or Android. Things like the gyro, things like the camera, things like file system access, things like location access, all being native APIs is really cool. But everything I just listed also exists in the browser. Now, in the same way that the web led to new developer experience expectations, then things like React forced the native
• 39:00 - 39:30 world with iOS and Swift UI to catch up to make better developer experience. Native platforms building these awesome capabilities and integrations into their platforms has resulted in the web having to catch up as well. That said, the native platforms tend to be first. Native tends to have new like device capabilities first. things like camera access, like file system, Bluetooth BS, wearables, all of the crazy things that
• 39:30 - 40:00 get announced. Like basically what I'm saying here is when a new iOS release comes out, those features are only accessible to native app devs, generally speaking. There are exceptions here and there, but if Apple adds an awesome new feature to iOS, the web is lucky if it ever gets it. Usually doesn't, but it'd be cool if it did. There's also a problem with the web platform in that it kind of competes with iOS and Android because they're trying to get you to build native apps on their platforms so
• 40:00 - 40:30 they can make their 30% cut, which we'll talk a lot about later. Because of that, Apple and Google are disincentivized from making the web platform really good. As such, web platform on mobile has lots of catches. Apple often restricts PWA. They have done so many things to destroy PWA over the years. I'm surprised they actually shipped notifications to it. It seemed like they never would. I think it works now. I haven't checked in a while, but I remember when they announced that that would be happening. If anybody chat can
• 40:30 - 41:00 confirm, do PWAs on iOS have notifications now? Like, is that real? And have any of you actually used it and seen it work? Okay, chat says yes. Awesome. It's a pain in the ass, but yes. Yes, they do. Okay, that's cool. So, LSPW implementation is garbage. It is getting more features, but it's still very, very far from where we need it to be. Like, native stuff is sketchy at best. So, if you're trying to like access Bluetooth things, it can work, but as soon as you go to a different tab or leave the app, who knows what's going to happen. Backgrounding is basically
• 41:00 - 41:30 not happening. If you need to do anything in the background, good luck. Have fun. If you want to even something like full screen GHF, like seriously, Apple has made it so hard to do proper full screen in the web on mobile. If you're not rendering a video player, good luck getting your full screen working and hiding the like tab bar and all of that in Safari. I think they announced that it's coming in some future Safari version. Good luck. Have fun. If you've seen how good that open
• 41:30 - 42:00 an app button works at the top of a page, you know how good Apple's attempts at making a more app-like experience in the web are going to be. It's an absolute disaster. Yeah. So, the combination of Apple's incentive and Google's as well to keep you from here is very real. Even if the web itself and like the official web standards committees introduce more and more of these APIs, the likelihood that Apple gives you access to them ever is low. And even if they do, it's coming
• 42:00 - 42:30 years later at best. Apparently PWAs can now finally hide the tab bar. Awesome. But can they be performant? As Jamon just said, very important. Performance is still an issue on web, especially if you get into 60 fps animations and especially gesture following animations. Yep. Apple does not give you the full GPU and CPU power of your device through the web browser. You cannot run your CPU at full throttle via a web page on your phone right now because Apple doesn't want all sorts of crappy tracking and
• 42:30 - 43:00 ads and on a news site when you're trying to just read a page quickly to destroy your phone's battery. I get why they want that. I get why they're pushing for it. But the thing is that they don't want the web platform to be an application platform. Apple wants the web to be for browsing and apps to be for experiencing. They don't want an in between. their incentives are fundamentally misaligned with what web standards committees are at. And because they control their platform so strictly, there isn't the flexibility that we
• 43:00 - 43:30 would want. And it's on one hand, it's a big part of why iOS is so successful. It's why things like spyware and viruses, if like I'd make the argument that iOS was the first major computing platform that never had a massive spyware or like virus problem. Every other major platform has had a pretty significant issue at some or point or another in terms of consumerus stuff. The amount of crap I saw my dad have on his Android phone back in the day was horrifying to me.
• 43:30 - 44:00 His Blackberry was somehow even worse. Windows, we all know how that went. Mac's never been a major comput platform. Linux guys, you didn't even get this far in the video. Your audio drivers aren't working. But for everyone else, iOS was actually groundbreaking in security in these ways and also had a much higher bar for experience than other platforms did too. Awesome. I get it. We need to lower the bar for developers who want to make good experiences in particular for them to share their experiences with others without having to go through so many hoops. If I make a bad app, maybe I
• 44:00 - 44:30 can't put it out on the app store, but maybe I can send a link to my friend to try it and he can give me feedback on why it sucks and I can learn more and fix it. That loop just doesn't exist on mobile. You basically need a really good mobile dev next to you holding your hand in order to do it well. And your reward for all of that, Apple gets 30%. I don't want this to be just a video about Apple and Google's cuts on these platforms. I should have probably talked about this during the platform section, but it's an important thing to
• 44:30 - 45:00 understand. On web, we have lots of ways to pay. It didn't used to be this way. Even back when like iOS first dropped and like the app store first came out, processing a credit card payment on the web was a challenge. When did App Store come out? App Store dropped 2008. Stripe came out 2011. We didn't have good, simple, reliable ways to process payments in our apps and on our websites, especially when the app store dropped. So, Apple taking a 30% cut
• 45:00 - 45:30 matching what was expected from like game distribution made decent sense at the time. Since then, the bar has been shifted. Platforms like Xbox, PlayStation, Nintendo, Google, and Apple. Oh, and Steam. These platforms all take around 30% of your revenue. This might not sound too bad, but when you compare it to something like Epic Games Store, which is default 12%, I believe,
• 45:30 - 46:00 but they'll also wave your Unreal Engine license cost, which is normally 3%. So it is often an effective 9% rate. That's a third as much. But then we look at something like Stripe. Stripe takes a much much smaller cut. If I just say it, you guys might not believe me. 2.9% plus 30 cents per successful charge for domestic cards. That's insanely low. That is hilariously low compared to these other options. There's
• 46:00 - 46:30 an issue here, though. If you subtract the gamer brain rot from this list, you don't have other options here. You have to buy through one of these companies because if you don't, you can't sell an app or a game on those platforms. Epic is an option for how to buy games. There are other options on PC as well, which is why they have to be more competitive with their cut and also why they choose to. It's why they made this in the first place. Stripe is trying to be a general payment processing solution. So, their cut is way, way lower. To show how this
• 46:30 - 47:00 affects people, I'm going to give an interesting example. I am currently live streaming on Twitch. I have a bunch of people who are subscribed to me on Twitch, and I appreciate each of them greatly. Subscriptions on Twitch don't work the same way that they do on a platform like YouTube. They are paid. You follow a follow on Twitch is the equivalent of a sub on YouTube. A sub on Twitch is the equivalent of a member on YouTube or joining a Patreon. My subs here are for the most part paying roughly five bucks a month. If you're an Amazon Prime subscriber, you get a free sub on Twitch every month. You can throw
• 47:00 - 47:30 that to me. Support us a bit. It's really nice. Thank you for everyone who does. But everyone who's not using Prime is paying for their tier one subs around five bucks a month. Yes, a sub is free if you have Prime. It's a really nice thing and it does pay me money. So, why do I bring this up? For a long time, we didn't have subs on mobile. The Twitch subs split is an interesting thing. If a sub costs five bucks and I am not in a certain tier of creator on Twitch, this $5 gets split in half. 250 to me, 250 to
• 47:30 - 48:00 Twitch. If you're a big enough creator, or if you've negotiated with Twitch, you can change this to a 7030 split. So, wait, I'm famous. Then the $5 gets split a little differently. 350 to me, 150 to Twitch. This might seem like a lot of money for Twitch to take. That's because it is. But also, Twitch was providing something really unique at the time, which is a way for viewers to directly contribute to the creator, which just
• 48:00 - 48:30 wasn't really a thing at the moment, which made this a much more justifiable thing. YouTube came out and took 30% by default, so it's the bottom numbers, not the top ones. Patreon came out and it took like 5%. But they've increased that percentage over and over again since in really weird kind of toxic ways that I don't love. This is the split though. And I will defend Twitch taking this bottom number here. I won't defend the top one because the rates of fraud on Twitch are insane because you get a
• 48:30 - 49:00 social reward if you subscribe a bunch on someone's channel. If you donate like 50 or 100, 500 subs to somebody, they're going to shout you out and it's going to be a whole moment. As such, it's a fun place to steal credit cards and use them to scam people on Twitch. And there's a lot of credit card fraud on Twitch. So, they need to increase the cut here a bit to handle as much of that fraud as they can because fraud is expensive. A chargeback on Stripe costs $15. It sucks that the fraud is a big enough problem that they need a decent buffer to handle
• 49:00 - 49:30 it, but it's also the main source of income at Twitch. So, this number conflates between a bunch of different things. Regardless, it is what it is. Why am I talking about this here? Well, uh, what about mobile? Let's say I'm famous and mobile. We have the $5. So, 150 goes to Twitch, but Apple broke in here, too. 150 to bucks. If somebody was to donate $5 to the mobile app, Apple makes almost as
• 49:30 - 50:00 much money as I did. That's pathetic. If I'm not in the good standing famous split tier here, 250 goes to Twitch, 150 goes to Apple, I'm left with a dollar, that's insane. And Twitch knew this was insane. So instead of doing it this way, they changed it. It's $6 to sub on Twitch. Twitch takes a lower cut. I think it's like 120 or so. Apple gets their two bucks or however much they take, their highway robbery. And
• 50:00 - 50:30 then you get what's left. It's like 380 or so or I think it's 280 maybe. Yeah, 280ish. Yep. So, if you weren't famous, you didn't have the special split and you were getting subs on mobile, you'd make slightly more than you would on Twitch. Twitch, you get 250. Here you get 280. But I'm making 30 cents more. My viewers paying a dollar more. Twitch is getting fleeced. This is the same case on Android as well, by the way. This isn't specific to Apple. It's just insanity that they charge this much. Like, how crazy is it that Apple's cut here is so close to mine when they had
• 50:30 - 51:00 nothing to do with you subbing to me on Twitch? Maybe, just maybe, you wouldn't have subbed if you didn't have the Apple Pay integration. But if you already have your credit card attached on the website, you can't use it on the mobile app. Apple will not let you default to your existing credit card that you've attached to your account because they make you use Apple Pay for digital transactions. You might be thinking now, wait, when I use Uber or Amazon, I can use my credit card number in those. You can because Apple has the most
• 51:00 - 51:30 arbitrary distinction imaginable here. Services, real world specifically, no cut. Digital goods 30%. This is Apple's rule for how they split these cuts. If you are paying somebody to come clean your car, if you're paying for somebody to drive you around, if you're ordering something on Best Buy or Amazon and it's a physical good, they don't take any cut and you can still use Apple Pay, you can still use everything else. Apple just lets you do it. A company like Bank of America pays Apple 100 bucks a year for
• 51:30 - 52:00 their dev license and that's it. An indie gamedev pays Apple 100 bucks for their dev license and 30% of all the revenue they have. So indie game developers are subsidizing Amazon and big banks on the app store. What the How did we get here? How is this okay? Companies like Amazon and Netflix have refused to play by these rules. By the way, Netflix fully pulled out and they will not let you sub on mobile. You can only sign in on mobile. You can't subscribe on it. You have to sub on web
• 52:00 - 52:30 because they will not give Apple their 30%. They went to court multiple times because Apple tried to restrict them from doing this and they lost. Netflix can't tell you, by the way, in the app, you have to go to web because Apple will ban you from the app store if you tell people they can go to web for a better price. That's what happened to Epic, by the way. Insanity. So, when Amazon was ready to do a similar move where they were going to pull for Amazon books, like the Kindle store, and for Amazon Prime, specifically around Prime Video, they were going to pull out and not
• 52:30 - 53:00 support paying for it on Apple at all. Apple made this new announcement, the Apple video partner program. Apple announced this thing that they did to give a better cut to certain companies doing video distribution through iOS because they were so scared of losing Prime Video after they lost Netflix. And the deal is they only take 15%. So you're left with 85 instead of 70. At the time it was just Prime Video, but now they've since they've updated it.
• 53:00 - 53:30 There are more companies. For two years it was just Prime Video, though. They announced this as a way to keep Amazon from leaving. And now they support a bunch of these other giant companies. Notice that Netflix still isn't here. Yeah, it's rare I say something is objectively monopolistic This is objectively monopolistic What the Apple? It's not better on Android, by the way. But it's it's insane that they can just charge these numbers and draw these arbitrary lines and distinctions and get away with it the way they have. Absurdity. And to go
• 53:30 - 54:00 back to Stripe, none of this is a problem. Hopefully, you see the problem here. Since Apple controls the only way you can pay in an app, they can make arbitrary rules and distinctions, favor some companies, over other companies, choose to subsidize big banks with indie game devs money. whatever they want to do, they can do it because these are the capabilities of the platform that they chose to implement and the restrictions of the platform that they chose to enforce. Personally, I think this should be illegal and they should get over in the courts. But that's just my take. So, with all of
• 54:00 - 54:30 this said, we need to dive into the part that inspired me to make this video in the first place, and I'm sad Jam's not here for it. Hopefully, I'll do a responsible job covering this. Routing and navigation. This honestly could have been a video of its own, but it's a really important thing to understand in terms of how the experience on apps differs from the experience on web. I'm going to start with the simple one, which is web. Let's say I go to a website. I go to website.com. I'm onite.com. I see a link I'm interested in on the site. So, I
• 54:30 - 55:00 click it. Now, I'm onite.com/about. Then, I realize I can sign in and I might get something different. So, I go to website.com/lo. I click the Google off button. When I click that, it will redirect me quickly to like google.com/off or something and then it will redirect me back to website.com/success or something. What's cool here is that you can edit this
• 55:00 - 55:30 stack because what's happened here is we've created a stack. If I'm onite.com/success, maybe this just redirects me right back to the homepage.com. If I'm on website.com after going through all of this and I go back, I don't go to success, I might not even go to google.com. If you've set your browser history stack correctly, then I should be able to go from website.com, hit back, pop this off the stack, and end up on /lo again, hit back again, pop that off the stack, go to about, hit back, pop that off the stack,
• 55:30 - 56:00 go to website.com. When you're navigating on the web, you're almost always navigating vertically where you're adding things to your stack of URLs you've been to. So when you hit the back button, it can send you back to the place you were before. The one thing we do have that I'm trying to showcase here with the login thing is in a given spot in this stack, you can swap out what is in that element, but it's not super common and it's usually just for something like a redirect or a temporary visit. You don't swap out where you're at in this stack unless you're doing
• 56:00 - 56:30 that. A simple example here is GitHub profiles. If we go to github.comt3.gg. I'm going to switch browser so you can see the URL bar more easily. Here we see I'm on my GitHub profile. I can click repositories and you'll see it changed to question mark tab equals repositories and type equals source. But if I'm in this tab, I can change to other tabs too. I can go to projects. I can go to stars. And now when I go back, it navigates through the different tabs I've been to, as it should, as we would expect it to. I
• 56:30 - 57:00 could replace my current location when I switch those tabs, but that would be a very unintuitive experience. Generally speaking, when a user clicks on something and they navigate, the expectation is they can go back from the place they just navigated to or from. Mobile is not so simple. There's one last piece I want to discuss, which is the structure of these URLs. If we go back here and we see where I'm at in GitHub, it's a little weird. They're using query params here. Most sites would do something more like this. If I did this /t3.gg/reos or slash projects or
• 57:00 - 57:30 slashpackages because there's the top level page of /t3.gg and then there are routes that follow up from it. A really common workflow on the web and we've all hopefully seen pages like this. If I have a dashboard page, call this my dashboard. The dashboard has this top nav of the my dashboard header, but it also has this sidenav that has different content pieces that we can navigate to. Let's say it has uh overview,
• 57:30 - 58:00 analytics, users, settings. So, we have all of these different places we can go within dashboard. So, by default, we're on slash dashboard. Slashboard has the header, the sidebar, and maybe some content here that's like welcome to your dashboard. So let's say I then click analytics. My expectation would be as a user of the web, believe it or not, I actually use browsers here and there, is that going to analytics would send us to /dashboard/analytics. And now a couple
• 58:00 - 58:30 things change. Analytics gets highlighted because we're on this and the content of this page here becomes your analytics. And now we have, I don't know, some charts. Let's make it funny. users over time. Realistic dashboard for most of your guys apps. What's interesting with this way of doing URLs is we are stacking in a different dimension. We have the vertical stack of the history of the different pages that we've gone to, but we also have this horizontal stack that has a different
• 58:30 - 59:00 role. As we go horizontal here, we have the dashboard, which is the core route we're on. It's what defines the topnav and the sidebar. But then we have slash analytics which controls the content of this main section here but also allows for slight changes to the section on the side here. The mental model is that slash dashboard has everything but the section here and then as we want to do more in this section we expand the URL. Chances are it's a little more complex.
• 59:00 - 59:30 It's going to be more like dashboard idanalytics. when I click on different things here, when I go from analytics to users to settings, we're still adding to that vertical stack. So, I can go backwards and forwards and the browser behaves as expected. This is more how the page chooses what content to render. The navigation is how we choose the stack and where we're trying to go backwards and forwards to and from. I really want us to think about the two directions here. We have the vertical stack, which is the links we've went to.
• 59:30 - 60:00 So, slashboard, or we'll say we go to the homepage first. So site.com/ Actually, I'll start at the bottom. It's a stack. So we go to site.com. Then we go from site.com to slashlo. This might send us through some crazy flow to do the o, but at the end, this is what's left on our stack. Then it redirects us to slashdashboard. I'm going to move to just the slash here because you get the point. Then I go to slashdashboard slash one for my specific
• 60:00 - 60:30 app. Then I'll go to /dashboard one/ I don't know analytics. And now this is my stack. This is the vertical stack. This is me adding new links and places I've been to my navigation stack as I am navigating my site. There is a horizontal component here too though. The URL is getting longer and more info is being added to it as we navigate the site. Sometimes we just hard swap out this horizontal stack where it's slashboard is the first page dashboard
• 60:30 - 61:00 one is giving it the data for our specific applan is now telling us which tab within our app we're in. The horizontal describes what we see. The vertical describes how we got there. So this direction is what we render and this direction is how we got here. Horizontal is our content. Vertical is the navigation history. This model is pretty cool. It is super standardized. We expect it to behave certain ways and for the most part websites behave well here. There are
• 61:00 - 61:30 some interesting edge cases like uh here's a fun one. I go to if I go to some random photo that I posted. Uh here's me announcing 200k. You'll notice here in the background you can see the content of the page underneath because this is opened as a modal. But if we look at the URL, nothing here indicates that this is a modal URL. SL Theo status this ID photos one. If I hard navigate, we end up with
• 61:30 - 62:00 an entirely different view because when we click the link, it opened it as a modal. When we load the link, it opens it as a page view. This is very interesting because it means the behavior when you click a link is different from the behavior when you go to the link. There's a lot of complexity here that I could go into, but it's also a relatively rare thing. It's cool they built this as a feature in Nex.js now, but it's not needed that often. We're going to choose to ignore this for the time being because of that unnecessary
• 62:00 - 62:30 complexity. But that's about it for complexity. Navigating the web is when you have a single page app, so you're not loading new HTML for each of these URLs. You can do some interesting weird things. But for the most part, URL equals certain HTML. In the JavaScript world, the URL always might point to the same HTML file, but the JavaScript that loads will change the content of the page from that point forward. Generally speaking though, URL determines what HTML appears on the page. I think that
• 62:30 - 63:00 all makes sense to you guys. So, what about mobile? We have to recognize some things that make mobile meaningfully different here. Thing one, mobile doesn't have URLs. You can build URI support into your apps. You can do things that are like URLs for your apps. By default, mobile apps have no concept of a URL. Usually, applications, in particular, the app platforms have a concept of a navigation stack. This navigation stack is its own method of rendering different views on
• 63:00 - 63:30 mobile. And it behaves very differently from how the web one behaves. It might seem similar at first, but the deeper you go, the more different you start to realize it is. Let's use Twitter as the example. I almost want to screen share myself on the Twitter mobile app. So, if we show this on the stack right now, the current location, the place that we are at is the home. I'm going to visualize this slightly differently. I'm going to have this all just stack up. So, we have home
• 63:30 - 64:00 view is the place that we currently are. It's actually probably something more like the um timeline view. I can go to other tabs on the bottom here. I can hit the search button and go to the search tab. If I drag sideways, it doesn't bring me back though. It brings me to my sidebar and my other accounts. If I go here though, so now I'm in my profile. Suddenly I can slide back. The reason is we added to the navigation stack. We
• 64:00 - 64:30 added the profile view and this one has some metadata on it. This one knows that it's profile Theo because that's the profile I clicked on. So, we have this profile view now on the stack. Here's where things start to get interesting. If I hit a different tab within here, now watch what happens when I drag. I'm not going back to posts. I don't go from the posts profile view tab
• 64:30 - 65:00 to the media profile view tab back to posts. I just go back to the home because the thing that happens with any spot in these navigation stacks is they have their own horizontal layer to them. So this profile view isn't really profile view, it's posts view on profile. And now we switched it to media view. This replaced posts view in this location in the stack. So certain navigations will add to the stack. If I
• 65:00 - 65:30 click a post here, like I'll click this one where I hit 200K, that added to the stack again. So now I have single post view. And this post view has a profile indicator, but also has post ID because it needs that information to render this view. I can drag back to where I was before, which is the media tab. And now I can go back again to where I was before. But you can see now when you navigate apps, you're either adding
• 65:30 - 66:00 vertically to the stack or horizontally as you navigate around. The difference here is when you navigate around, like if we're in using the dashboard example here, and you switch to the different sections, back will bring you to the one you were on previously. If I go to x.com/t3. and I navigate to a different tab and I go back in the browser. It brings me to the tab I was in before because it changed the URL. When I go to slashmedia, it's now/t3. Media. It's not navigating
• 66:00 - 66:30 horizontally. It's always navigating vertically. Whenever you go to a link in the web, unless it's something automatically happening like a redirect, there's a very, very good chance that it's being added and appended to that vertical stack. On mobile, you have to make a decision about this. It's not a free thing where we all just do what the browser does. You have to think about this every time you're adding navigation features to your app. When I am in this post view where I'm looking at a post I made, should going to my profile go up the stack or should it go horizontal? If
• 66:30 - 67:00 I switch the post I'm looking at, should it go up the stack or horizontal? Here, when you're in Twitter, going to a new post or a new instance of a thing always adds vertically. But if you're going to a different view of the thing you're in, it goes horizontal. So, if I go here and then I switch to replies or subs, you get this horizontal navigation, but it doesn't add to the stack. And this is all much more important than it might sound because all of these things are handled with everything from gestures like the sliding with two fingers left
• 67:00 - 67:30 and right to handle it to the native back button being handled properly, but most importantly, accessibility. Some people don't use their fingers to navigate their phones. They have custom commands and layers in order to do this. So if you don't handle navigation the way the platform expects, their way of navigating might just not work entirely. And this is a huge difference in how we have to think about our apps. It's the reason we can't just take a web page that has links that work a certain way and just dump it into an app and expect it to work. And when I use an app that's based on web technologies, or worse, an
• 67:30 - 68:00 app that's built by web devs that don't understand mobile, they will just port every single URL over to a specific view on the phone. And now you're just constantly building these massive navigation stacks. When Blue Sky first came out, it was really guilty of this. If I was like navigating through a profile and like looking at some information, I'd have to slide back like 20 times to get where I started. Most navigation flows in something like Twitter, you only have to go down a few layers. And there's a lot of navigation you can do where you're not going down layers at all. Like when I go from my
• 68:00 - 68:30 home feed to search, that's not a navigation that's changing my stack vertically. The way to think of this with iOS is very much like actual layers. When I open this post, it is now open on top. And when you watch me go back, you see that you see that this layer on top is being pushed out of the way or back on. And when I go to my profile, you see a new layer sliding on top of that. This isn't something they built in with their custom engine for
• 68:30 - 69:00 the Twitter app. This is just part of how the Twitter app works because it's part of how the native platform works. These stacks of vertical navigations are essential to how you experience mobile apps. And if you just shove URLs in and handle navigation the same way the web does, your app's going to feel really jank. And this is super common. When mobile devs complain about React Native, this is one of the things they're complaining about the most. Not because React Native makes you work the way the web works, but because a lot of React Native devs are web devs. And those web
• 69:00 - 69:30 devs are used to using this way of navigation with URLs. And as such, they force it into mobile apps where they don't fit. It's a very, very interesting dynamic, and it's one I think about far more than I probably should. But this idea of I now have my profile open on top of my post, which is open on top of my timeline. And now when I navigate within here, I'm still in that layer on top. I'm just moving around within it. Hopefully, this helps give you an idea of just how different these methods of navigation are. I'm tired of web devs
• 69:30 - 70:00 pretending that mobile doesn't have any differences. They can just port their website over and it's fine. And I'm tired of mobile devs acting like their way of navigation is obviously superior and there's no benefit of the web way. Which is why when you hit that little open button on random web pages to try and open it from the web page in the app, it never works. There's a fundamental incompatibility between how navigation works on web and how navigation works on mobile. And I don't think we can just solve this with tooling. These are decisions that need to be made with care as we're building
• 70:00 - 70:30 our apps. And for better or worse, using React Native often results in devs that don't care as much because the devs that care the most are the ones who are the most obsessed with their platform. Those are the ones who are building using the native tools and technologies. This goes the other way too though. If you are using Flutter on web, there's a good chance you don't care about the web platform. And even if Flutter for web was theoretically really good, most Flutter for web websites are going to be bad simply because the people using it are the ones who don't like or don't understand the web technology, React
• 70:30 - 71:00 Native devs are less likely to know how apps work and how we should use them. Mobile devs are less likely to know how the web works and how we should navigate it. And you can tell when you're using a web app made by a mobile dev or when you're using a mobile app made by a webdev is very apparent. This is also the big reason why I'm not a fan of the tools that try to be a web and mobile app project at the same time because the navigation is so fundamentally different that if you make something that works on both it's optimal for neither. And this isn't the most complex code in your apps. Like the code that handles the
• 71:00 - 71:30 navigation stack for Twitter, it's probably a few hundred maybe a few thousand lines. It's not even 1% of the code in those applications. It's not that complex. But as soon as you make one app platform or but as soon as you make a single project that compiles to web and mobile, you have to have one routing paradigm. And as soon as you have that one routing paradigm, you've made everything less optimal. Yeah, I think I've covered everything I wanted to here. What a journey. I did not think
• 71:30 - 72:00 this video would end up being this long, and I appreciate you greatly for sticking through with it. Hopefully, you got something out of this. Hopefully, you have a better mental model for thinking about the differences between mobile and web. And maybe, just maybe, we'll see a future where shipping for mobile is as easy as shipping for web is today. But until then, I'm mostly going to be sticking to web. Believe me, I want a T3 chat app more than anybody, but uh we're going to have to do a lot of work to get there. Until next time, keep