Bringing your React Web App to native with Capacitor

Okay, so, this workshop is bringing your React web app to you native with Capacitor. Like as I said, my name is Mike Hardington. I work on this technology. I work at a company called Ionic. We do cool stuff with not only web technology but native as well. So, we know a thing or two about bringing web apps to native. And bringing some web goodness to native as well.

Quick little notice on some housekeeping. This is being recorded. You'll be able to watch any replay at a later point in time. I'll try to post all of the slides. Though I don't think the slides are going to be too applicable at a later point in time. Most of the conversation that we'll be having here, will be the most important part. I'll try to post what I can afterwards. But don't worry too much about slides and everything. As I said, post your questions. There's a Chat feature, we'll use that. Also use Discord if that's where you feel comfortable. I'll try to meet you where you are, versus forcing you to use any one particular thing.

So, with that out of the way, seems to hit a little con point in attendees. Let's dive in! I want to first dive into this concept because it's going to be the central point for everything we're going to cover today. It's this idea of cross-platform. Cross-platform development is something that is not uncommon. It's done in almost every software specialty. If we think about games, video games, you rarely see people writing a game once for PlayStation, once for Xbox, and then, again, for PC. There is typically some sort of tool that they are using to build their games and then have that essentially be able to run on all of the consoles, the desktop environments. And all they really need to worry about is building their games using these tools, to be able to take advantage of this cross-platform. So this is a very well-tested approach to building a product and to build anything. We're just going to look at it in the context of building an app, and taking your existing web apps to be able to port them to these different platforms. So what we're trying to figure out is how can we reduce having to learn new things, reduce having to ship or create more code that is specific to a different platform and reduce the time it takes for us to actually ship everything because having all of the different technologies choices available to us, it's an amazing thing, but if we're spending a lot of our time having to focus on learning a particular tool and then we never get to ship, it's kind of all for nothing. So reduce our overall knowledge that we need to know, reduce the code we need to write, and then reduce the amount of time it takes for us to ship something.

So when comparing different technologies we have to look at it in terms of abstraction. Too often or not, we get into a situation where folks like to say, x is better than y for these three reasons. I mean, think about how many versus articles exist out there, React Native versus Flutter, Flutter versus the web. All these different technology comparisons are doing a disservice to themselves because they are trying to go point-for-point with the thing that they are comparing themselves against. It doesn't always work out that way. Thinking of it as terms of levels of abstractions to me, makes a little bit more sense. We're going to look at a few of them. The way I tend to think of this is, how far removed from a given target is our technology choice. Here on the left, we have a pure web development environment. You are not even focused on mobile or native mobile. You are only focused on building a good, responsive web experience. On the other side, we have pure native, where we don't care about the web. We are just focused on building a dedicated native app for each platform. And we have plenty of teams that can focus on that, and work in that environment.

So, let's start off with the pure website. And I'm going to look at this one first. Chances are, if you have been a developer for at least five years, you might have heard of this project. It's called Cordova. It was probably one of the first projects to promote this write once, run anywhere mantra.

Where they gave you, essentially, a poly fill for native device features. They were a bunch of developers that want to build web apps. But the web at the time was not really a good platform to develop for. It was missing several key features that native devices had right away. So they decided to build this technology to expose these native features through JavaScript, and then let developers go ahead and wrap their web app in this runtime and then provide access to those features by extending built-in web platform features.

For instance, if there was an old geolocation specification, they wrap their own geolocation API on top of that old specification. So they extended a lot of the built-in features that ship with the browser to supplement their own native runtime features. So they started off using this approach realizing that certain APIs don't really map well to built-ins. So eventually they did need to go ahead and create their own global APIs and they built up on top of the Navigator object, for whatever reason, and inside of this they were able to build out essentially objects that had all of the functionalities for the core plug-ins. So one of the first ones that they had was this camera plug-in and then they created a way to take a picture or present a native camera activity to your users directly from your JavaScript. So they had this navigator.camera.getPicture. It had an onSuccess, an onFail callback and then there was a third parameter where they allowed you to set all of the different options for this execution. If the camera call was successful, you'd get the image data back, and if it was, if it failed for whatever reason, you'd get a, an error message returned back to you.

It worked well. Now this approach of using navigator and having everything tied to that fails right away when you realize you need to include Cordova with everything to get this to work. There was, there is no built in camera API currently with the web, although that would be a fantastic new feature. So it's automatically not as cross platform, because if you don't include it in your web browser, or if you try to run this in your web browser right now, it would, it would fail because there is no way to mock camera with something that exists in the browser. The browser. So this is only available when you're essentially targeting iOS or Android.

So the camera was one API but there was this huge ecosystem that came out of Cordova where they have things for Firebase, they had plugins for for...blanking on names, Century, PayPal, they had a lot of success getting people to build plugins and they themselves also shipped a good collection, I believe, like 12 to 14 core APIs that they felt were essential to a device. So geolocation, camera, filesystem access, splash screen controls, status bar controls, all of those types of things. They didn't really have a package manager. Cordova predates NPM, which is pretty hard to imagine an environment where we did not have NPM. And this was also before Bower for the people who remember what Bower was. And they basically had these custom built scripts that they would run anytime you wanted to trigger a release, which were not that great. They had a lot of learning curves, because they were pretty ahead of the time for 2010. So this whole idea was to keep the web, was to polyfill the web until the browser finally added those features. It's 2022, some of these features still don't exist in the browser at the moment. So it's pretty fair to say that their target goal was pretty unsuccessful. They also didn't want you as a developer to ever need to open up a native IDE, which I don't know why. A native IDE is actually a pretty good tool for configuring these native projects. So going back to that custom scripts thing, if you wanted to set your profiles for signing and releasing the app, it all had to be done through pretty obscure script tags or script tasks and passing in different options. Not ideal. But they took this even further and made it so the native projects were things that got destroyed and not committed to version control. If you and a co-worker are trying to work on the same app, you set a permission on your machine, they set a permission on their machine, there is no way those permissions are ever being shared. They are constantly having to be reset. So not ideal. Okay. So that's the very beginning of cross platform. That was going on for a little while. People were pretty happy with it. Sure there were some pain points but for the most part there was the only project in this space. Then came something called React Native and several other quote, unquote compile to native where their main goal was to say, hey, you write in this tool and it will give you a pure native app afterwards. So I put this kind of cheekily saying that, learn once, write anywhere, as the as the kind of initial goal of React Native. Their idea was that trying to do write once, run anywhere was never going to work. So rather than have that, give you an abstraction where you could learn one API or one style of programming and let you write for all these different platforms. They promised it would be a truly native app, which it's not necessarily the case. It's not too different from Cordova, and they built abstractions around native controls. They did provide a nice standard library, so to speak, around these native APIs. But it was basically put upon the community to add more features than the core team actually wanted or any core team from various projects.

So, in a sense, when you are building, and this is just a simplification for React native, when you're building a React native app, you have your app over here in this blue box being ran inside of a JavaScript runtime. It could be V8, something else. But essentially, that is running your JavaScript, and that runtime will communicate through a bridge layer. Any time that bridge layer tries to access device features, it's going to proxy out to the actual device features, get the results, serialize that to JSON, and then return that to the JavaScript runtime and that is going to be sent back to your app.

As the UI gets evaluated, the bridge layer is also going to communicate to the native runtime and render out all the controls essentially on the fly. So, all of the UI elements, the buttons, cards, tab navigation, is all getting rendered on the fly internally via react native. And this is actually a pretty similar infrastructure to other projects. It is not specific to react native so don't assume that. There is a very similar architecture to Cordova here. The only difference is that instead of a JavaScript runtime, it is a full browser ecosystem, and we separate out the rendering process and just use the browser to render. So these are very similar architectures.

My and this is a bit of my own personal opinion towards it, where it kind of breaks down is having this idea of different, having to learn a new syntax that isn't essentially the same stuff that you've learned for web development. Having to learn how to redo h1, h2, paragraph tags, anchor tags is kind of kind of frustrating. I get why they did that, but it is yet another thing to learn. If you have an existing web app where you are trying to get that into the native runtime or the native stores, you're unfortunately going to need to rewrite that app to support this React Native runtime. Some people will do that, and they will say it's okay, but it's still just a frustrating feeling. And then finally, if there's a third-party library that you really, really like, if it does not support React Native out-of-the-box, you can't use it. So, I have one of my favorite libraries out there is fill.js, which is a rich text editor. You can't use that in React Native because of how it's built and how it works. You have to find one that's specific to React Native in order to get it to work in a React Native app, which seems not right, in my opinion.

Yeah, I mentioned it earlier, but the idea that it's truly native is a bit misleading. Architecturally, it is still running JavaScript, controls are rendered on the fly, there's essentially a custom rendering agent. This last point for folks who are interested in Flutter, this is something that you do need to deal with is that the rendering is not actually rendering native controls, it's rendering things in the loosest sense on a canvas. And then you're just interacting and re-implementing all of the native interactions. Take that for what it's worth, it is just the fact. So moving on, what are the other options here? Ideally, we want something that kind of bridges the native development life cycle, but also still very much in this web developer mentality where I am just writing HTML, CSS and JavaScript. I can bring not only React, but any framework into my toolkit and I can just ship whatever I want. So that is what we'll focus on today, and that is Capacitor.

So, in a runtime, Capacitor is a native runtime and a JavaScript library. It is at first a way for you to import packages that provide access to the native device features. So similar to Cordova in that sense. Except that each package itself allows it to wrap various different APIs and we'll look at how that works. The APIs that you as a developer actually interface with are streamlines. That way you have this one particular way of accessing the file system and then the packages that you will interact with know how to send those options and call certain methods that fit on iOS or Android. And when you want to include a new package, it's basically just pulling that in from the native package managers inside of the respective projects. So if I install, say, our file system API, it's an npm install for me, but behind the scenes it's using CocoaPods to fetch the dependencies for iOS, using Android libraries for Android. So the package management story here and how the code gets from your node modules to the native project feels at home for those respective platforms.

So let's take a look at the architecture because I think this is actually pretty important. So we have our web app here in the blue box again, and it gets rendered inside of a native web view. This native web view is basically just an optimized version of Chrome, Safari, what-have-you without any of the browser UI elements in there. When you go ahead and make a call from your web app through capacitors API, that native web view is going to be able to hear that call, or at least know that something inside of it is trying to call a capacitor API. It'll get the information that you're trying to call for the certain device that you're trying to call, and it will send that to the bridge layer. The bridge layer will then proxy out to the native features, whether they are operating system-level features or hardware features. Serialize the results, return it back, send it to the native web view, and then that will get returned to your JavaScript code. So architecturally, this is very similar to how React Native works, with the exception that we are rendering our own UI. So if you have a UI library, or if you have your own design system in place, you can bring that to a capacitor project and still have the same experience between your website, your native iOS app, and your native Android app. So great experience all around. How this is different is that, as I said, you could reuse your existing web apps and your existing web skills. This includes third party libraries, frameworks, again, we're looking at it with React today, but this is framework independent. So if down the road, you work in a project, and you have to use something like Svelte or solid, or view in The runtime loads instantly, so as your app is booting up, it is essentially able to call native APIs right away.

So there is no slowness as it waits for everything to connect. You are able to call location data as soon as the app starts up, which is really, really nice. Not something that was possible with Cordova. And can make your app really stand out. It is very drastic, how fast it is. And as I said, it utilizes the best practices for native, meaning that we're not trying to introduce our own thing. Native has its own set of tools and resources. We're just going to use them and take advantage of the fact that those tools exist.

So, that's enough for like the slides. Enough for all of that. Let's bring up, we got a question. Does it produce a native app or a web app with mobile hardware OS features? Yes to both. I know it's not really a great answer at the moment, but I'll show you more about why I think it's both. And you can debate if you think I'm wrong.

Let's go to my terminal. So I have an app over here. I'll just open this up in VS code. And I will change my color scheme for real quick because that is super bright. And then I will also. Run starts start my terminal. So this is quite literally a blank React, create React app project. And let's get this over here and do some window management real quick. Just one more. Can I get a thumbs up if you can't thumbs up in the chat? Or can I get some indication in in the chat if you think that is a good. Index.ts. Dex.tx. How does that look for font size? Too big? Not big enough? Look good? Anything? Okay. I saw a thumbs up so we're gonna assume that that is good. Awesome. Thank you all. So, I just created this app. You could create your own app with create React app if you want. I think it is MPX create React app init. Don't quote me on that. But the idea is that this is nothing more than what the React docs suggest that you do. You create a project, you now have you now have all your files over here. You have an app.tsx. I'm using TypeScript for this. You don't have to. I just think it is probably the best way to do this stuff in 2022. And make sure that it all makes sense. It is in a type safe way. have our app here. It is loading up an image. We have some docs on the code. We can probably get rid of this link tag. Everything is updating pretty well. And we are going to focus on here for most of this. Because I don't feel like I'm not trying to include so many opinions on how you build your app. I hope you have your own opinions on how to do that.

I want to show off what you can do without having to go through a lot of explaining around, here is the UI library we chose to use. From here, we do want to install and set up a capacitor this project.

I am just going to split, keep the dev server running, and I am going to start installing some dependencies. So the first one we are going to need is to uninstall atcapacitor-core, and atcapacitor-cli. So their names are pretty obvious. atcapacitor-core is the core runtime, the core library, and then atcapacitor-cli is a very slim CLI that will go ahead and manage to create the native projects and manage the native dependencies. So we're going to go ahead and run this. It should only take a moment. They don't use too many dependencies, so it works out.

And with those installed... we have a question. Cool. Stephane, we'll get to your question in a moment. I just want to initialize this project first. To initialize the project, once we have the Capacitor CLI installed, we can just run npx cap, and then init. So this is going to be our little walkthrough process of how we create a project. What should our app name be? We can just say React Summit. Again, user-friendly, it should be something that people will search for. This next part is just package ID. Now, the package ID is a pretty standard thing that happens in both iOS and Android. If you have never done any of native development before, it can be kind of confusing. They tend to expect this reverse domain style, but there is no practice for how this should work. So I'm just going to do com.mhartington.app. Hopefully, that works, and then you'll see that it creates this configuration file for us, capacitor.config.ts, and then it produces some docs for how to get started and what to do next. We're going to walk through this all together, so we don't really need a reference those docs, but we'll keep them in the background if anything goes awry, which it shouldn't.

So let's take a look at that capacitor config file. Our config file basically tells our tooling how to manage the project and manage handling all the different dependencies in the web code that we end up creating. So obviously we have the app ID in here, which is that reverse domain bundle ID. We have our app name, which will be used and displayed on, say, our simulator or our real device. The web dir is essentially where all of our JavaScript code gets built to. So for a React project, this is going to be build. If you do have a custom project structure or a custom setup and you do not build the build, change this to whatever you want. And then, bundle-webruntime is just a default if you're not using a bundler, like Webpack or Vite. You can set this to true and it will include a script tag reference. We don't need to worry about that because we are using Webpack in this case. From here, I do want to include one... Okay, so for some reason, Zoom had captured my keyboard controls. All right, I hope that that is still recording. All right, what I'm going to do real quick is just this little trick that React does not provide out of the box. And that is this meta viewport tag. And I am terrible with remembering it. So I'm going to grab it from an existing project from directory. And I'm going to copy this viewport instead. Let me go back to the S code. Where did I have it? Viewport, is that it? Yeah, meta Viewport. So essentially what I just did here, because of devices that have a notch, iPhone, certain Pixel devices, Samsung devices now, we need this Viewport bit cover in there to essentially tell the web run time to use the full real estate. Otherwise it would cut below the notch and this looks kind of weird. So we'll keep that in there, and we'll save, our project is still running in the web browser, and let's go ahead and start accessing our first native feature. I'm going to use geolocation first, because that is a pretty familiar API, because it exists in the browser right now, and you can use the browser geolocation API instead. I want to show why you would use capacitor.

But first we need to install it. So to install it, we have all of the core APIs split out into their own npm packages. So we can install it by just saying npm install capacitor geolocation. The geolocation plugin is only focused on geolocation and provides all the dependencies that you need for that, which are basically the appropriate iOS code and appropriate Android code. And then it wraps the web geolocation for a web environment.

So back in VS Code, and with that installed, let's go to our app.tsx, and let's actually add some stuff in here to start calling the geolocation. So first we're going to import from at capacitor geolocation, and we are going to import the geolocation API. The geolocation API will hold all of the available methods for us, it's going to be able to provide all of the necessary permissions and let us manage those permissions internally. So let's go ahead and also import from capacitor core because there are some differences in how platforms manage location or manage permissions. We're going to import this core capacitor class and it will give us everything we need here. Now, we also need to have, I believe you can do it up here, we actually don't need to import React from Reactive, at least we do need to import use, use effect to be able to manage handling these permissions. So let's go ahead and create this use effect and it's going to have zero dependencies. So it's going to be acting like a knit lifecycle hook and the use effect is going to be async, which I don't know if that's actually recommended. I still do it because whatever. Actually, we won't do it. We'll do things properly, appropriately. So our way of managing permissions or getting all this stuff is we're going to want to have a request permission function which gets called when the app initially starts up or when this component initially renders. Because it has zero dependencies, you'd only call this useEffect instance once. And then we need a const request permission. It's going to be an async function. And inside of this, we could literally just call geolocation.requestPermission. So, oh, bad scrolling. This is literally just how it'll go ahead and try to request browser permission to get location. Let's save this first and see how this works. So, nothing really happens. Let's open up the DevTools. So I am using Safari. Comments to yourself about that. But what we have here is that we have this unhandled promise rejection. So as I said, the web handles permissions not really well compared to iOS or Android. So there are going to be cases where you have some APIs that behave slightly differently between the different platforms. It's not a totally big issue because the warning over here or error over here it's just a simple unhandled rejection which we could reject and handle ourselves. So your app isn't going to crash completely if you do this. If you don't like seeing these unhandled premise rejections, either handle the rejection well or you could do what I would do and just say, if capacitor.isnativeplatform and then bring this up to here and it will only run if it's on a native platform. So we're already having some nice experience here. We can do some quick runtime checks to see if we are on a native platform. And if we are, we should be able to request permission.

Moving on below this, we should get our location first. So we can have a new method called get AutoCompleteFailingMe, getLocation, which will go ahead and try to get our location data. So let's just stub this out real quick. GetLocation, cool. I'll center this real quick. So this getLocation function, this is simply just a way, this is an async function, again, everything in Capacitor is asynchronous. So you're gonna be dealing with a lot of async await or promises if that's how you want to do things. In this case, I wanna just use async await because I think it's a little bit easier, but we also could use promises. So within this getLocation, we want to have a variable and it's going to be await geolocation.getCurrentPosition. Now, getCurrentPosition is going to be essentially a one time call. Behind the scenes in iOS and Android, it's going to split up a single shot location call, return that data, and then clean up after itself. So it's going to manage the memory and the impact of this call for you without you having to do any cleanup. So we'll await the results of this and store that in a lock variable.

And we can see the different return values that we get. We can get a set of coordinates or, if my cursor wanted to move, or a timestamp. Timestamp could be nice if you are doing some kind of location where you want to update your users. For instance, if you're doing a delivery app, you could use the timestamps to inform it, your driver has left the building at such and such a time or your delivery person has left at certain time. We want to get this current position and we want to also display it inside of our app.

So let's continue on at the top of our function and we're going to create some state real quick. So we'll just use date and we'll have location data and set location data. And we'll have location data and set location data. So with that, we can say set location data is going to equal in or it's going to be function call and we'll have our longitude, which is going to be lock.coordinates.longitude. And then we'll also have a latitude, which is going to be lock.coords.latitude. Now I'm just gonna do some quick little cleanup, TypeScript's going to be pretty mad at me, and just give it a nanny. Provide the proper types for everything. And actually, let's look at what is on coordinates. So coordinates gives us a bunch of different things out of the box, latitude, longitude, accuracy, and then also altitude accuracy. So it can return whether or not you are at an elevation. Also inside of it, there are a few optional, lock.coords, things in here. For instance, we could have the heading, we could have, let's see, altitude, accuracy. It's only available on native platforms, so it is optional, it could be undefined. You're able to type around that in certain situations where it doesn't return a value. So keep that in mind as you do things. Let's close that out.

And then underneath our, or inside of this paragraph tag, actually, let's change the paragraph tag to a pre, and then inside of this we'll render JSON, that's Stringify, location data. And this is a really, really fun little trick on just how to indent all of this stuff in a readable fashion. I'm not gonna go ahead and show it inside of Safari, because Safari doesn't actually mock my location. Not that I don't think you are all trustworthy. I just don't want my location being out there. I believe it's localhost 3000. And let's see what happens. So there, you saw our location. So actually, let's go ahead and manage this location. We'll delete this, just because I want to show how the permission gets set up. And this is all managed through the actual browser instance at this point. So when you're on the browser, because there is no built-in permission model or permission setting that is comparable to iOS or Android, as you go and you try to request permission, it's going to use the adjust in time model. So you can see here that in this promise for getCurrentPosition, we have a timeout, which can be configured so that way you can wait a little bit longer. But if you don't allow it within a certain amount of time, you get a rejected promise. In this case, let's allow it. And because the timeout happened, we will just do a quick refresh, and you can see that we have our location data pointing us to our mock location. So far, so good. This is exactly what we want. This is just essentially the bare minimum. I said, I don't expect you all to have the iOS SDK or Android SDK set up, but I do want to add a native platform first to show how this can work. If you do want to go ahead and try to install the iOS SDK or Android SDK, we do have a lot of, don't allow, we do have some good docs over here on how to get started with this and how to set up your environment to work with these native platforms. We're going to just kind of skip over that. Definitely check it out. If you would like, Capacitorjs.com slash docs, drop these into the chat. We're gonna focus on and assume that some of this is already set up. To like add a platform, we can just run npm install at capacitor, and then we have two platforms out of the box that we support. Obviously iOS and, let's see, iOS and Android. And we're going to install those real quick. Now, when, I do want to touch on one of the questions, which was from Stefan, comparing Ionic Cordova versus Ionic with Capacitor.

What is the performance difference? What is the difference in the plugins? If we use Cordova plugins within Capacitor, is it slower than using a Capacitor alternative plugin?

So, let's make sure, you should be able to unmute if you would like, Stefan. I just want to make sure that I understand your question fully in this context. Yeah. Okay. So, for me it's important, the performance of Cordova, comparing to the Capacitor. And why shall I switch my project from Cordova to Capacitor? That's my question. Yeah, yeah, yeah. So, this is kind of jumping ahead a little bit. But you can answer later if you want. When we reach it. Okay, let's do that and then we can go, I can be able to provide more details. Yep, thanks. Cool. No problem.

So, we have installed the two platforms, iOS and Android. Let's go ahead and then call cap add iOS. Now, we split up the install and the add commands to two different things, because you might have a a package install of iOS, but you're not on a Mac and you are on a Windows. That would fail, but we still want you to be able to install the packages without any issues. So, we split them out into two different things and it simplifies our work that we need to do.

So, we'll add an iOS project. You can see, it's going to create this native Xcode project. It's already milliseconds. It could not run the, or it could not sync it to the web assets to the native project because there is no build directory. And then we get this nice little doc on how to handle workflows. If you get lost, the documentation is always going to be there. We can do the same thing for Android. It will do the same exact steps and produce the same exact output varying different times. So I'm going to show iOS first because that's where I'm most familiar but we'll show Android afterwards.

So let's go ahead and do a quick build. It's going to run React scripts and it's going to run our native build or our web build and produce the JavaScript that we need to deploy to iOS. With that process done, we can run mpx cap sync iOS. Now you can see it's going ahead, it copied all the web assets but it's also using this native dependency and I don't know how well you can see with the flashing. It's using this native cocoa pods tool that iOS uses. So all of the dependencies get installed through cocoa pods for iOS and Android libraries for Android and just keeps the tooling that we need to generate to a minimum and uses the existing ecosystem.

Once we are done with that, we can run mpx cap open iOS and it will open up our native Xcode workspace. Let's give this a moment. If Xcode is a little slow today, that's pretty normal. Xcode is somehow slower than any Electron app that I've ever used, which is gonna be really painful for native desktop app enthusiasts. I'm going to select my device to be 13 pro. I'm going to let it finish indexing all the files. You can see over here we have a little bit of a file tree where we have all of the dependencies that our native project needs, the development versions, and then the actual frameworks and tools that get included with this. Here you can see we have the capacitor. We have this Capacitor Cordova Pod, which is our bridge layer. So if you are someone who has a Cordova app and you just want to migrate over but you're not fully set on being able to replace everything, Capacitor can take your Cordova app and support that as well. We have a nice little bridge to the Cordova APIs and a good selection of third-party APIs. I would suggest moving all your plugins to using Capacitor once.

And we have our geolocation API, which let's go ahead and actually look at what this is doing. I just think this is fun. So we have our pretty typical native code here. We are importing some plugin versions, some nice data, we have all of the different methods and it's actually supporting all of the methods like getCurrentPosition, watchPosition, give away a little secret to what we'll do later. And then checkPermissions and requestPermissions. All of these are being done inside of our Swift code. So Swift is a language, if you've never written it before, we won't focus too much on it, but you can see that we have this nice, asynchronous way of getting the location and managing all this for you. Same thing with watchPosition. We have this whole entire way of getting the current position and watching it as changes happen over time. So there's a bunch of native code in here. We also have our app, which is our app.delegate. The app delegate is probably something that you won't customize or you won't use too much. But if you are part of a team where there is a collaboration between web developers and a native developer, be it iOS or Android, you can have them come in here and provide some overriding features for when your app starts to launch, when it becomes active again after being in the background, or when it does want to receive notifications. So all of this can be customized to your heart's content. The main storyboard, storyboards, the best way I can think of to describe them are these are our kind of mockups and our ways of building up the structure of our app, like by adding widgets in UI. We don't really need to focus on it too much, we are first going to just try to run this and get everything to load up on a simulator. I'm going to run this from this little play button, it will go ahead and try to deploy this to my iPhone 13 Pro simulator. We'll give it a moment.

Like I said, Xcode can be very slow. I'm going to preemptively pop open up this log over here, and it's going to let us see what happens behind the scenes. The build succeeded, that's awesome. Let this run real quick, and I will watch this for simulator. Awesome, simulator is up and running. It's going to toggle this feature real quick, set the location to Apple Park, and we'll get our app up and running. And hopefully we'll be able to see the location. Just a give it a moment to just actually get everything up and running. And you'll be able to tell when everything is set as the device will be able to print some stuff out over here. This doesn't work. Yeah, see? Cool, so it does take a little bit to actually get all of this stuff up and running. Subsequent runs will be faster. It's just because this was a cold start. And just to prove that, let's just stop real quick and run that again. Let's see, it's already up and running. Now, you notice that we are trying to get the current position, but we have an error. This was intentional. The error is the app has attempted to access some privacy-sensitive data without any usage description. So we need to add some native permission management here to allow us to get access to this data. So let's go ahead and copy this. So NSLocation, when in use, usage description. As I said, this is pulling in all of the actual, you know, things that we need from both native and web. So we'll just come over here to an info.plist. If you've never messed with info.plist before, it is a fairly typical data format for, add a row for setting things for your given project. So we have our NSLocation, when in usage description. It's easier to say privacy. Location, when in use description. We can set the value for this to be, I want to see the location for the demo. Pretty standard stuff. Location, there's a bunch of different values that we can do in here. So if you've opened up an app before, Uber, Uber Eats, any kind of delivery app where they need to know your location. There are different options here for a one-time in-use and always usage, always in the background. You can supply those privacy settings and hope that your users will be able to accept it and you can see why they want that location. You can tell them, I just want to see the location for a demo. So with that set, let's rerun this again and open up our app. Allow React Summit to use your location, allow once, and we'll go ahead and set the location to be Apple Park. Don't miss that we also get this little icon up here in the top corner for iOS. It's just going to indicate that something tried to get our location. Now we can see the trail of events that have happened. So we bloated the app, WebView is loaded, geolocation request permission was our first call. So it automatically printed that out. We got the current position and decided to call native. The location permission came back and we said, granted, everything is good. And then we have the results coming back from our get location. So our entire app is working as expected and we're getting the location back just well. So moving on from this, we can start to try and customize the Android experience. So we'll go ahead and we will do the same thing. Instead of opening up, well first we need to sync Android because we did a build, and it does have its web assets. Worked well, it's actually much faster than surprisingly iOS but we'll do npx cap open Android. Now Android Studio if there's any fans of IntelliJ products, WebStorm, PHP Storm, this should feel pretty familiar to you.

This is basically IntelliJ just re-skinned for Android development. So we'll give it a moment, it does take a little bit longer for it to start up at least for the IDE because it manages to fetch all the dependencies once you install. You can see we're importing all the different plugins and all the different tasks and letting it operate. It'll also index all of our files so that way we can examine the entire project structure.

Okay, everything looks like it's coming up good. All right, so we should now be able to go ahead and build this project. So much like we had to do for iOS, we need to provide the permissions here. And I'll be honest, I don't remember Android permissions. They are pretty different compared to iOS. Thankfully though, we have all of the plugins that are part of the core offering. The geolocation plugin will tell you what permissions you need to request. So let's go ahead and just copy these, and then inside of this app, manifest android manifest.xml, we need to print them or set them here. You know, so we'll get this nice little tab over here saying where our permission should go. And we're just going to print these three permissions. You might get a little warning saying your permissions are outside the application tab. That's totally fine. The app is going to still function just as well.

With those permissions set though, we can come up to the top of Android Studio, and we have our selection of devices, whether it is a Pixel 4 or Pixel 3, or any real devices, or we can create a new virtual device. I'll pick the Pixel 4. We have the configuration for our app, and then we'll hit this play button. I had to spit up the entire emulator, and you see I had a saved state from before when I was practicing with a different example. Let's let this kind of do its thing. As I said, Android Studio can be a little bit slower, but it's not terrible. We can, however, just close that I think. And if you're ever curious, there is the full output that happens when you are building your app. So you can check on that to see what's happening. Cool, so our app is up and running, got deployed to the emulator just fine. Same thing as the iOS version, the cold start for the app, it does tend to take a little bit. And this is only with the simulators though. So a little bit of a delay. So allow while using the app, go ahead, should try to get the location. It might have timed out because I took too long. Let's just double-click this to close it. Let's try one more time. React Summit. Cool! Cool, we got our location. Again, the emulator is not the best development experience in my opinion. It can be very, very slow. It can not work great if you have an underpowered device or if you're trying to run, for instance, a Zoom call and an emulator and a bunch of other things all at the same time. So, if you do have a device, so this is my Nexus 5a, the last Nexus that LG made is my testing device. It's a lot faster than the emulator. Always worth testing on a real device too because you have access to notifications and everything. So, right now we have our app running and it is using the longitude and latitude. We're getting everything up and coming back. It runs automatically in the web, iOS and Android. Without me talking, probably 30-ish minutes and that's just waiting for things. All right, so we do have some questions over here. Stephan asks, is it possible to store these permissions in a config or everyone who works with the same project should be set then manually for their builds? So, very good question. These actually, if we were to just stop the run and then open up over here. So, this is the same project, right? Git status.

So, we now have several files that are basically gonna be part of version control, iOS, and Android. So, once one person sets up permission, the full native project gets included into, or once they've created a project, I should say, that native platform gets added to version control. So, Stefan, if you made a change or added a permission, and then you pushed it to Git, and then I pulled your changes down, I would get all of the permissions in here and be able to keep working on my project without having to constantly reset them. There could be some room for improvement in adding them in different locations and setting them via the TypeScript API. But at the moment, they're still going to be available regardless of who's working on the project because they're all version controlled. But hopefully that...

So, just to recap, what are the different benefits compared to React Native again? Well, automatically, we now have, basically, a great way to start working by not having to develop initially in the device. So, if we were to run our DevServer again, this'll automatically be up and running, we could start developing in the browser first, have the same access to APIs in a much faster development lifecycle, and just keep Chrome in the focus. It would sing. Come on, React DevTools.

Cool, so all this is just gonna start working versus React Native having to set up a React Native project, having to configure all your dependencies, basically learn the new tool and syntax for it. This is basically just HTML JavaScript plus a few different JavaScript functions. And it works in the browser right away. So I'm not having to learn a new development cycle.

Now, if you are someone who doesn't want to open up Xcode or open up Android Studio, in fact, let's just close those down right now. That is just what I was going to say, basically. What I don't like about React Native, like having Xcode, compiling, taking time to do these things. And while you are developing, usually look for things that faster. So it's a bit sometimes annoying. So if there is alternative way to do this, for example, in web, and then you have the same experience that should be in Native, it'll be brilliant. Yeah, I mean the same experience, it will be shared the same way. What's really nice is here, we're just developing in the browser and everything's working, but if we wanna do, we can do a little trick. So we could also just npm or npxcap run iOS, which will go ahead, set up the entire build process for us, copy all this over, and instead of having to open up Xcode, we now have a little picker over here where we could select our device, it'll go ahead, try to run the build for us, and automatically deploy that to the iOS simulator. So reducing the need to have to open up Xcode is really nice. I'll let this run again real quick. Is there any other questions?

Oh, I see we do have a question. Does a web view handle large projects where multiple native APIs are made, and does it handle animation like native does? Let's see. Does web view handle, Cahir, could you explain what you mean a little bit more? You can come on mute if you would like.

Yes, I was gonna ask if we make like calendar, API, maybe contact API, lots of APIs, and the APIs that, for example, the React Native users that use native drivers that boost the animation. Because I think the animations in Capacitor are made for CSS and HTML. Those are the primary animations, I guess.

Okay, so for the multiple native APIs, don't allow, all of the API access, again, like I said, are in these official API, plugins. So you mentioned the Calendar and contacts. I believe we do have a contacts plugin, if not in the official one. It is in the community plugins, which we have this huge community of third party plugins that people have been maintaining for Bluetooth low energy, background geo-location. Let's check the contacts. Yeah, here we go. This is the contacts plugin that you can use and you can install this, add the plugins, and again, here are your permissions. And then you can go ahead and get these added to your project. So multiple native APIs can be used and leveraged. As for animations, you're probably going to want to use a library for that. Since this is just web though, you could use something like Frame or Motion. You could build your own animations using JavaScript and the web animations API. Various different ways to build all those things out. I wouldn't say that that's necessarily something that has to be handled through a capacitor because that should be something that is part of your web app design process. Cool. All right. We did a one time build and our app is up and running. I do wanna show one thing that I really, really enjoy and that is getting a faster development cycle. So we have this whole Concept section over here in our docs and we have this live reload. Now if you're using this with Ionic, we kind of cheat and provide a lot of the work for you. But if you're using, say, React, we could say, host equals npm run start and it'll start your React dev server. We can then set the... Hello in Safari. We can then set the URL to point to the appropriate location inside of our capacitor project setting. So we'll open up that real quick and go to capacitor config.

And then we'll have a server reference. I think I copied. Yeah, don't need this anymore. Don't need clear text. Cool, so let's just double check. Nope, I think it is, yeah, 30. Now I need to remember what my IP is. Eh, shouldn't be too big of a deal. And just double check that's working good. Awesome. Let's go ahead and then run our mpxcap run iOS. Again, it'll do the same thing as before. But instead of pointing it to our native assets or to our statically built stuff, it's gonna point it to the dev server. Go ahead and get this up and running. We'll still be able to have our permissions maintained, but now when we come over to our project, if for some reason we wanted to not use pretag or if we wanted to split this out, H1 location, up and running, we could now start developing our app and have this whole entire thing just basically bound to our location data dot. That's it to. Basically now our development cycle feels a lot more familiar to traditional web development. We're not having to go ahead and wait through these long compile times because we do have library load in dev servers. So all of this is working really, really well. And then it also works for app dot CSS changes as well. So we could get rid of this Text Align Center. I don't think we need it. Give it a moment, looking pretty good. Awesome. Basically, you're now familiar depth environment. Wanted to actually get this across because this is really, really nice. If you are developing a very, very large, complex app, it can be a pain to have to constantly go back and forth between working in the browser to then deploying to the native device, figure out that you need to change, rebuild, redeploy. This is working just fine on the simulator and is able to update on real time as I make these changes. So if I get rid of the H1, it works the same way. This is not tied to just using a simulator, you could deploy it to a real device as well and have that same experience working for you. Things that you can also handle here, if for some reason we wanted to come back to this React Summit app, and we want to change this name or even change the icons, there's various different ways we could do this. Stuff, but dev server first. We have an extension here inside of VS Code. It's just called Ionic. It's not tied to just the framework. You can see we have a whole bunch of capacitor configurations over here, and we can generate some custom splash screens for you using some local tooling that gets included. So it'll use, I believe it's ReSharp, to generate icons and splash screens for you, and even include background and foreground colors for complex icons on Android. If you wanted to have some kind of a GUI way of opening things up in Android Studio and Xcode, you can do so. Or if for some reason you want to manage the build number, inversion number, or completely rename the app to something like getNation, it'll go through and rename the entire app for you. Then you could redeploy and it will automatically update for you. Give that a second. Don't need that, don't need that. No issues found. It'll go ahead, ask me to pick my simulator again. And it will automatically make sure that that is up to date. So I think if we sit here and watch, yeah, updated the name and still deployed to the device. So it's working really well here. Cool. Want to make sure, check how we are in time. Don't believe we're gonna through the full three hours.

That has been a lot of this workshop, which is totally fine. It's a lot of information all at once, but do wanna open this up for any more questions or anything else that people would like to know or are curious about. That's fine.

So what's the pros and cons about running this on YesWeb or on this Accelure one? Android Studio so for like development while developing? One more time, sorry. What's the pros and cons? The point, you have two options to running this locally, for example, just using your web, like development kit or using XFBOE on Android Studio. So what's the process for running this on device? Is that what you're asking? Yeah, what is the advantages and disadvantages for this? Oh, the advantages. Okay, the advantage is that you get a quicker like on device feedback, like there are some things that can be emulated inside of the browser with varying degrees of success. But if you're trying to target a mobile device, it's sometimes just better to deploy it to a real device and know that that's what the experience is going to be for your users. So it's kind of how, it really depends on what you're trying to do and what you're trying to... Achieve. Achieve. I would probably, I have a mapping app that I've been working on that I always deploy to a real device just to make sure that the rendering of the web app in the web map, are going to be as fast and efficient as possible. I could try to emulate that in the browser, but the device is just going to be the one that gives me the quickest and most real feedback. And if we were to deploy it to those devices, we'd still be able to attach our Chrome DevTools and inspect that and get that feedback on how the performance is going. Yeah, I think that's a good answer. But still while developing sometimes, you need to just like not wasting the time moving between these platforms. So we need to develop at the end, where you need to test it fully in actual device and see if that works properly or not. But while developing, yes, I can use like a Chrome browser. And yeah, if there is a list of mapping to say what is available on browser and what is not available. So that would be also good to before you start, build something for two days and then come after find that it's not supported. So, that's all. Well, we can take a look, if for instance, actually geolocation, but we do have support. I believe it's some used to be listed in here where you can see all the various different plugins and what platform is supported. I think our docs team might have removed that. So I need to open up an issue to get that added back. Let's see, what is the average size or like what's the overall size for the app that this is generated? So let's just do a quick little build and we'll try to get a rough estimate of what this is going to be. I will say that the overall size will be significantly smaller. Let's just try to run it on the simulator real quick to see if we can get a size to that. The overall size is going to definitely be a lot smaller than say, a pure native app. Well, it will be a little bit smaller than some other cross-platform solutions and can be smaller than a pure pure native app because the tools and dependencies included are going to be a little bit better optimized. Did I break something in my app? Going out here, let's just see. Oh, I pointed the server to the wrong location. Anyways, let's just get rid of this. Let's try this real quick again, one more time. So there is another question that Tahir is asking what big companies are using this technology. So, I do have actually a slide for that. I do have a slide. So we do have a lot of huge companies. This is constantly changing. Burger King, Blue Cross, Blue Shield, BBC, IBM. A lot of large enterprises are using this stuff. I believe even, I believe Target is also using it. The capacitor docs would have a full section on how, what companies are using this stuff. Let's just try to see what we got here. I don't know why it's not working. Settings. Should be able to see the usage and everything. Let me see app size. No, it's not gonna give me the size here in Simulator. Average size probably somewhere in the, with native dependencies and deployed on the device, somewhere anywhere between 80 megabytes to smaller.

A lot of the areas where this could change is what dependencies are you including, what web assets are you including, are you requesting stuff from a server or are you requesting things or including them locally? If you're including a bunch of videos or something, that might include, that most likely is going to include the overall app size. But most of the apps are pretty actually small.

I'm blanking on where I can find the usage of this, so I don't have an actual number that I can give you.

Naveed, what is the limitations of the Capacitor versus a native app? It's a very good question. I would say that the actual limitations are probably going to be 3D intensive graphics. That's not specific to Capacitor, I think that's just a general comparison against the web. Native has really highly optimized APIs for managing 3D graphics, creating 3D graphics, the web does not have that. Probably a better solution would be to use something native in that regard, but you could use Unity in that case, which is highly optimized for cross-platform 3D graphics. Otherwise, think of the apps that you use these days that are probably going to be just glorified lists and scrollers. You can rebuild that in the web just fine.

If you do want to learn more, because I'm basically at the time with the workshop, but we have the CapacitorJS website that you can join. There is our dedicated docs that you can use here, and then this Capacitor Community GitHub organization, which has a whole bunch of different plugins, as I mentioned. We'll remove the query for this first. Don't know why that's still up there. How many plugins? Yeah, I mean, we have things for date picker and intercom integration, integrating Twitter, Twitter Kit, I had no idea that was a thing, Facebook login, we basically have covered every single use case that you would want for developing an app and accessing third-party APIs. SQLite is a pretty fun one that people have often used. So, if there's something in there that you want to try, we probably have an API for it. So, I believe I am at the time and everything for the presentation.