Mobile Deployments for Web Developers

Rate this content
Bookmark

It's easier than ever to use JavaScript to build native mobile applications. But for web developers building in the mobile ecosystem for the first time, deploying cross-platform apps built with tools like Capacitor or React Native can be complex. Learn about the mobile-specific deployment considerations through the lens of a web developer, including the key differences between mobile and web, how to develop a deployment strategy, and how to evaluate tooling options.

23 min
05 Jun, 2023

AI Generated Video Summary

Mobile deployments are crucial for web developers due to the increasing number of users on mobile devices. Cross-platform development and web to mobile migrations are on the rise with tools like React Native, Ionic, Capacitor, and Native Script. Mobile testing requires native binary compilation and testing on real devices. Google Play and iOS have specific methods for releasing apps to testers, while web development allows for dynamic updates and quick deployment. Mobile app building and deployment require specific infrastructure and code signing processes. App store approval guidelines and versioning updates pose challenges in mobile app deployment.

1. Introduction to Mobile Deployments

Short description:

Welcome to Mobile Deployments for Web Developers. As a web developer, it's important to understand the significance of mobile deployments. Users are increasingly on mobile devices, so building for the mobile platform is crucial. Cross-platform development and web to mobile migrations are on the rise, with tools like React Native, Ionic, Capacitor, and Native Script. Mobile differs from web in terms of the platform, as you're building for hardware and compiling a native binary. The platform sets the rules in mobile deployments.

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.

2. Web and Mobile Deployment Testing

Short description:

Let's explore the differences between web and mobile deployments. Web testing usually takes place in a dev, testing, or staging environment, with automated testing for continuous integration. Mobile testing requires native binary compilation and testing on real devices. Virtual devices can be used for quick implementations, but real device testing is necessary. You can connect a real device to your dev machine or use a real device farm for automated testing. Test channels are also available.

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.

3. Test Channels and Web Build Process

Short description:

Both Google Play and iOS have specific methods for releasing apps to testers. Google Play has internal, alpha, and beta testing tracks, while iOS has ad hoc releases and Apple TestFlight. TestFlight allows you to invite up to 10,000 testers and provides built-in tools for collecting feedback. When building for the web, there is no need for an actual build, as modern web development allows for dynamic updates and quick deployment.

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.

4. Mobile App Building and Deployment

Short description:

On the mobile side, you're creating an executable binary for your native platform. You need specific infrastructure requirements, such as Mac hardware for iOS builds and specific versions of Xcode and Android SDK. Build types and versioning are important, and the code signing process ensures the app's integrity. Android has debug and release build types, while iOS has simulator, development, ad hoc, App Store, and enterprise. Credentials like upload key and app signing key are needed for Android app signing. For iOS, there are signing certificates and provisioning profiles. Once the app is built and signed, it's ready for deployment. Web deployment involves putting the files on the server.

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.

5. Mobile App Deployment Challenges

Short description:

You have control over when your app is deployed. The platform sets the rules. You have to submit your app for app store approval before it can be deployed to users. It's important to understand the store approval guidelines and what can cause your application to be rejected. You can't have crashes or bugs in your application, no broken links or placeholder information. You also can't have a substandard UI. Your app can be rejected for not having enough lasting value. When maintaining for the Web, we have control over our own deployments and all users have the same version of the application at the same time. With Web applications, you can choose what dependencies you need and when to update them. Pushing a bug fix or updating the application on mobile is not easy due to the long tail of app versions to support.

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.

6. Mobile App Versioning and Updates

Short description:

On mobile, everyone doesn't have the same app version. App store requirements and updates must be followed to avoid being delisted. Bug fixes for cross-platform apps can be done through over-the-air deployments, updating web content without a new app store version.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
React Day Berlin 2023React Day Berlin 2023
29 min
Bringing React Server Components to React Native
React Server Components are new topic in community, bunch of frameworks are implementing them, people are discussing around this topic. But what if we could use React Server Components in React Native? And bring all optimisation features that RSC allows to mobile apps? In this talk I would present what we are able to do with RSC in React Native!
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

Workshops on related topic

React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Workshop
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
Workshop
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
Prerequisites
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
GraphQL Galaxy 2022GraphQL Galaxy 2022
156 min
Hands-On With SwiftUI, GraphQL, & Neo4j AuraDB
WorkshopFree
Bring the power of graphs to iOS mobile app development in this hands-on workshop. We will explore how to use the Neo4j GraphQL Library to build GraphQL APIs backed by Neo4j AuraDB and how to integrate GraphQL into an iOS app using SwiftUI and the Apollo iOS GraphQL library as we build a news reader mobile app.
Table of contents:- Intro to Neo4j AuraDB- Building GraphQL APIs with the Neo4j GraphQL Library- Intro to SwiftUI- SwiftUI + GraphQL
PrerequisitesTo follow along during the workshop attendees will need a Mac laptop with a recent version of Xcode installed. Some familiarity with Swift and iOS app development will be helpful, although not required.