Mobile Deployments for Web Developers

Hello, welcome. This is Mobile Deployments for Web Developers. I'm Cecilia Martinez. I'm a developer advocate for AppFlow, the mobile CI CD platform built by Ionic. Feel free to connect with me. I'm at Cecilia Creates on Twitter and GitHub, or you can also connect with me on LinkedIn. Just look me up by my name. It's n slash Cecilia Martinez. I'm happy to chat about mobile deployments with you more if you have any questions.

The first question that you may have is, why, as a web developer, that you may care about mobile deployments? Well, increasingly we're seeing that users live on mobile devices. This means that, as a web developer, you're building for the mobile platform in terms of either a mobile web app or, in some cases, actual native applications as well. We're seeing an increase in cross-platform development, which means building from a single code base to mobile web, iOS and Androids using tools like React Native or Ionic. And we're also seeing an increase in web to mobile migrations. What this means is using existing web content or building out a web app and then turning it into a mobile app. You can do this with tools like Capacitor, which is also built by Ionic, Native Script, or anything where you're essentially adding native functionality and then building for the Android or iOS platform. You can also use this using what we call mobile micro frontends, where you're embedding web content into a native mobile application. So you may come to a point where you're asked to create web content for a mobile app and then also a need to understand how to deploy it. So understanding what makes mobile different is really important when it comes to taking a web app and turning it into a mobile application.

Ultimately, what makes mobile different is the platform that you're building for. When you're building a web app, you're building for software or you're building for a browser. Your web app will ultimately be interacting with another piece of software and running in that browser. For a mobile application, you're building for hardware. You're building for an actual native device. And because of that, you're actually compiling a native binary that will then run on that device at a later time once it's been installed. This is different than a web app where we have, you know, interpreted code that is really dynamic and that is running in the browser at runtime. So these are the differences that take place between web and mobile that need to be accounted for. But the overall, like, the big picture difference is that with mobile, the platform sets the rules. With a web app, you have complete control over when you deploy your app, what tools that you use to build it, what dependencies that you use. With mobile, that is not the case. Whether you're building for iOS, Android, or both, those platforms are going to dictate a lot of the deployment process.

So let's take a look at that deployment process and the different stages and how web and mobile deployments are different across each stage. We'll go ahead and kick things off with testing. So when we think about testing for web apps, typically, we're testing in a development, testing, or staging environment. There is testing in production that can be done as well, but we'll stick to pre-production testing for now.

So when you're testing in a dev, testing, or staging environment, you can be testing your actual code itself using like unit tests, or integration tests, or API testing. Or you may also be doing end-to-end testing where you're launching your application in a browser typically headlessly and running your automated tests. Ideally, there's minimal manual testing that will take place for your web app. Ideally, you have a lot of automated testing and that allows for automated continuous integration. That means that you have a change to your code base, all your tests run on an automated fashion, if everything looks good, you can go ahead and integrate that change into your code base without the need for a lot of manual testing.

It's very different on the mobile side. That's because you do need to have a native binary compiled for end-to-end testing. You also need to be able to test it on a device. You can't only just launch it in a browser and do that in your testing environment. So what this means is that you have to leverage both virtual and real devices for testing. And there's also a requirement of more significant manual testing. There are automated testing frameworks for testing both on virtual and real devices, but typically what we'll see is that you'll have multiple rounds of test releases and you'll use that with manual testers and testing tracks in order to get your application fully tested before it's actually released to users.

I mentioned that there are multiple device options for testing, so you do have virtual devices. These will be emulators for Android or simulators for iOS. There's a couple of small technical differences between the two, but ultimately what these are doing is they're replicating a real device, but it runs on your computer. It's a virtual device. These can be helpful for seeing quick implementations of your app or showing it off to stakeholders or doing some debug testing, but it doesn't fully replicate the experience of a real device. That's why typically you do have to have eventually real device testing. You can connect a real device to your dev machine, hooking up your iPhone or your Android device and being able to run your app that you're building. You can also manually install the binary onto your device. AppFlow, for example, has an Android QR code where after you build your Android app you can scan the QR code and it'll install it and open it on your Android testing device. You can also upload the binary to what's called a real device farm. This can be done with automated testing, so you actually upload your application build that you just created and you can run automated tests on real devices in the cloud. Some of these include like AWS device farm, Sauce Labs, there's quite a few out there. But they do allow you to do some testing on real devices without having to provision those real devices yourself. There's also test channels.

So when I mentioned earlier that the platform sets the rules, that's what we're talking about in this example here when we come to talk about test channels. So both Google Play and iOS have specific methods for releasing your apps to testers.

On the Google Play side, you have three testing tracks. You have internal, which is used for quick deployments of up to 100 users. You can deploy apps that have not been fully configured yet to internal testing tracks. So it's good for your QA testers, stakeholders, anything that's going to be internal to your organization. You do have to authorize everybody on this list manually with an email address. So it's something that really should not be used for releasing your app more widely.

Then you have the alpha testing track, which is also called the close testing track. This allows for deployments to a wider list of authorized testers. So if you need more than the 100 for internal, otherwise, then you're going to need to go to beta testing track, which is also called the open testing track. When you're in beta, anybody can install and test your application. So it should be ready for listing in the Google Play Store and ready for it to be visible. So this is really the last step in testing before you release your application fully.

On the iOS side, you have what are called ad hoc releases. Ad hoc releases can be used to deploy apps to up to 100 devices per year. So Google Play is users. Apple ad hoc is based on devices. Each test device does have to be manually added to your provisioning profile and you build your application. So it's really, again, useful for internal testing, your QA test, just your stakeholders. If you need to deploy to more test devices, or if you're ready to share it wider, then there is Apple TestFlight. So Apple TestFlight is a program provided by the Apple App Store that allows you to invite up to 10,000 testers using email addresses or you can also share a public link. The nice thing about TestFlight is that it has built-in tools for collecting feedback such as bug reports, screenshot submissions, things that make it easier for you to get feedback from your testers while it's in the program. You do have to have an app store built to deploy to TestFlight, so your app has to be configured and ready for that.

Speaking of app store builds, let's talk about the build process next. When you're building for the web, you don't technically need an actual build. This is a requirement of modern web development, where we're using things like frameworks and transpilers in bundles in order to optimize or minimize HTML, CSS, JavaScript and our static assets for the web. It's really easy to update for the web dynamically. Web builds should not take a very long time. We're able to deploy updates very quickly when we talk about building for our web applications.

On the mobile side, as I mentioned earlier, you're creating an executable binary for your native platform. This also means that you have to have very specific infrastructure requirements in the environment that you're going to be building. Whether you're doing this locally, like manually on your Mac computer, or whether you're doing this in a CICD environment, you're going to need to have Mac hardware for iOS builds. You're also going to need to have specific versions of Xcode and Android SDK installed in your environment in order to actually build your mobile app.

There's very specific build types that you have to select from, and you need to make sure that you're versioning each build properly, because different versions are required as you update your application. And you're going to want to be able to keep track of which version of the application that you're building and how that connects back to the version of your code base. The biggest difference though when it comes to building your mobile app is going to be the code signing process.

I mentioned build types. For Android, there's debug and release build types. For iOS, there is simulator, development, ad hoc, App Store, and enterprise. Ultimately you're going to need an App Store build in order to actually release to TestFlight or the App Store. On Android, you're going to need a release build if you do want to release to either beta or production testing tracks, and then also release. Otherwise, the other build types are useful for various types of testing and development.

I mentioned code signing. So code signing, what it does is it actually validates the identity of the signer, as well as what devices it can run on, and from a security perspective, it ensures that the app binary has not been altered or modified since the time that it was signed. Signing your Android app involves two credentials. You have an upload key that's generated locally on your machine, and what that does is it's actually used during the build process to generate what's called a signed bundle. This is a .keystore or a .jks file. There's also an app signing key, and this is actually typically generated by Google, and it's used by Google to sign your app after you've uploaded it to the app store, but before it's delivered to users. You don't need this in your build environment, so it's not required if you're doing a CI City pipeline for your build. This is something that happens within the Google Play process.

For iOS, you have two credentials, a signing certificate, which validates the identity of who generated that authorized build, and then also provisioning profile that states what devices a signed bundle can run on. If you're doing an app store build and you have what's called a distribution provisioning profile, meaning that the app can run on any device, but as I mentioned, for those ad hoc builds, you do have to specify which devices they can run on, and that's when you'll need to have a specific provisioning profile that lists out all those devices. Both of these credentials, actually all of these credentials, need to be in your environment when you go to build your application.

So once your application has been built and signed, it's ready for deployment. We talk about deployment, we talk about the process of actually getting the app to users, right? So for web, all you have to really do is put the files on the server. That's it. I remember, I used to use FTPZilla back in the day and just kind of drag the new build file folder over and replace the previous one, and then once that was complete, all of your users have that new version of your web app. You have control over when your app is deployed.

You have control over when your app is deployed. Again, this is kind of the theme here, but not the case when it comes to mobile, right? The platform sets the rules. You have to submit your app for app store approval before it can be deployed to users.

There are some ways to get apps in the hands of users, by bypassing app stores, but it's very, very rare and, honestly, most users will not install an app that does not come from the app store, and for good reason. The app stores set these specific privacy and security policies to ensure application quality, so you do have to also create a store listing. You're going to need to have all your details and your assets in that store listing, things like your app icon, your screenshots and previews, and you're also going to need to set your privacy and data agreements.

You know, whenever you're using a mobile app and it makes a request to access your photos or your location, these are data access requests that need to be specified in your app store listing as well as your application code base and what permissions that you need, and that could cause you to be rejected from the app store if these aren't configured properly. The approval process can take up to a week or more. It's not a very specific number that they give you, and if you do get rejected, you have to go through a resubmission process that could take even longer.

Because of this, you don't have as much control over the deployment process and you're kind of at the mercy of the app stores. Because of this, it's really important to understand the store approval guidelines and what can cause your application to be rejected. These are the reasons provided by Apple, the most common reasons why apps get rejected. It includes things like, you can't have crashes or bugs in your application, no broken links or placeholder information. I mentioned specifically that privacy policy and unclear data access request issue, that's definitely a big one. You also can't have a substandard UI. And the Apple documentation gives a couple of screenshot examples of what they consider a substandard UI.

This one kind of makes me laugh because if we didn't allow substandard UIs to Web apps, a lot of them wouldn't actually be in production. Static Web content, this does not mean that you can't use Web content in your native application, it just means that the native application needs to have a reason for being native. If you're taking an existing blog, for example, and turning it into a native mobile application, but not making any changes, that's something that could be rejected because it doesn't need to exist as an app. And also your app can be rejected for not having enough lasting value. So it's important to understand what these potential blockers are, so that you can deploy quickly.

That's because you'll need to be able to maintain your application as it moves forward, right? When we talk about maintaining for the Web, as I mentioned before, we have control over our own deployments and all users have the same version of the application at the same time. Barring any feature flags or A-B testing, once your user goes to the server, they're getting the same version of your app. With Web applications, you know, you might have to maintain some dependencies. But you ultimately get to kind of choose what dependencies that you need and you can choose when to update those. So you do have total control over your releases. And you can push critical bug fixes or updates whenever you need to. Pushing a bug fix is not easy on mobile. Neither is updating your application and maintaining it on mobile. This is because you have what we call the long tail of app versions to support.

So whereas on Web, everybody has the same version of your app, on mobile, that's not the case. Right? So if you have� may have your applications� your app store set to automatically update, or you may have a really old version of an app on your phone because you've never actually gone in and manually updated it. If you make any changes to your API, maybe a microservices, if you implement new features, you have to make sure that your application will still work, even on those oldest versions of your app that's out there. You also have to keep up with app store requirements. So both iOS and Android will update their security requirements, they'll update the minimum SDK that you need to use to build your app. And if you don't comply with these, you can actually be delisted from the app store. You also need to think about what your update strategy is going to be because bug fixes and updates are difficult to deploy. If you are building a cross platform app or an app that leverages web content, one option for bug fixes is using live, or what we call over the air deployments. This allows you to update the web content of your app without actually doing a new app store version. You can't use this for any native changes and your app does have to be pre-configured. But there are various tools available that allow you to essentially push new changes to that web content and bypass a new native version. So keep that in mind as a potential update strategy as well.