DEV Community: Appcircle.io

What is CI/CD and Why Do You Need CI/CD in Mobile App Projects

Sophie @Appcircle — Wed, 08 Sep 2021 16:36:34 +0000

Reading Time: 4 minutes

As the backend systems are evolving to cloud-native apps and the frontend clients are unifying around mobile apps, continuous integration (CI) and continuous delivery (CD) are getting more and more crucial in every software development project regardless of the size and the scope. Mobile app development is one of the areas that can benefit from CI/CD the most.

This article is the first in our CI/CD article series, where we answer the following questions:

What is CI/CD and why do you need CI/CD in mobile app projects? (This article)
What are the operational and business benefits of CI/CD?
How does Appcircle solve the common problems in mobile app lifecycle?

In our first article, we will start with a quick introduction.

What is Continuous Integration and Continuous Delivery?

Continuous Integration (or CI for short) is the automated way of building every code pushed to a common code repository. This build process is ideally enhanced with workflows for steps like code reviews, code analysis and unit tests.

Continuous Delivery (or CD for short), as the name indicates, is the automated delivery of the application with environment deployment (e.g. a development or production variant), code signing, versioning and sharing the successfully built releases with the related users (e.g. testers).

So, then, what is a pipeline (CI and CD)?

When you consider CI and CD together, we get a full application "pipeline". With CI, you build your app and push it towards the pipeline. With CD, you ensure the app is transported through the pipeline properly to the correct recipients.

How do CI and CD relate to some of the most prominent problems in mobile app projects?

After laying the groundwork, let's explain why you need CI/CD in mobile app development, starting with the causes, the problems that are commonly observed in mobile app lifecycle and how CI/CD addresses them.

Code repositories being used like a file storage, not as a collaboration tool: Automated CI/CD process encourages frequent code pushes.
Low application quality with issues slipping through the cracks in the end user release: Automated CI/CD process eliminates manual operation and possibility of human error.
Long build times of large apps with multiple dependencies: Agent-based CI/CD tools free the local environments from the resource and time-consuming build process.
Rapidly changing landscape with frequent updates to mobile operating systems and development frameworks: CI/CD tools handle the environment to be up to date while providing a wide range of options for build configurations.
Complexities and delays caused by application code signing due to the unique requirements of Apple and Google: With CI/CD all the complex steps in the app lifecycle are automated and the developers are isolated from these complexities
Complicated set of build artifacts to gather at every step of the app lifecycle: The CI/CD tools automatically collect and deliver all the artifacts from a single convenient point of access

With all these problems and many more, it is indeed necessary to have a proper CI/CD solution in place and we can now have a more detailed look on why you would need CI and CD in mobile app projects.

Why do you need Continuous Integration in mobile app projects?

CI is not just about using a source control system and resolving conflicts when multiple developers are working on the code. It is about establishing a discipline and a standard for development.

The reason for this is that even if a team is using a common code repository but without an automated build process, the general tendency is to use it like a backup tool and push changes at the end of the day.

From this perspective, one of the most important advantages of CI lies in the automated builds, which is then enhanced with automated workflow steps such as static code analysis, code quality review and of course, integration with testing automation or manual testing distribution.

CI enables shorter release and test cycles, which is even more crucial with the unique complexities and error-prone nature of mobile apps.

For instance, if you are developing your apps with a native or hybrid cross-platform framework, which is highly likely to have a single-project structure, building the same project for iOS and Android requires totally independent efforts, which can be automated with mobile CI.

Why do you need Continuous Delivery in mobile app projects?

Similarly, CD is not just about uploading and downloading multiple app binaries for different environments. CD automates the release process and eliminates the human factor, which again enables shorter release cycles and producing more reliable releases.

In mobile apps, one of the most crucial pain points is the environment switches and with an automated CD process, you can easily get the same application for multiple environments.

Another point that makes mobile CD more complex but also more important is code signing, which is not applicable for the majority of the web applications. Especially for iOS apps, there are different code signing procedures for different distribution methods (ad hoc, enterprise distribution and public distribution) and manual signing is indeed a complex process.

What's Next?

These are just the tip of the iceberg in terms of the reasons and the benefits of using CI/CD in mobile development.

In our next article, we discuss and list the benefits of CI/CD both from a general and from mobile development perspective.

Appcircle is an all-in-one automated mobile CI/CD platform is that makes mobile CI/CD best practices accessible to everyone.

Why Do You Need a Dedicated Mobile CI/CD Platform Instead of Jenkins

Sophie @Appcircle — Wed, 08 Sep 2021 16:35:14 +0000

Reading Time: 4 minutes

Jenkins is a general-purpose CI/CD tool, but you may be asking how you can use Jenkins for mobile app builds or if Jenkins is useful for mobile CI/CD. Jenkins is one of the most popular tools for DevOps processes, however mobile DevOps may benefit from specialized tools that meet the unique needs of mobile apps.

In this article, we will discuss how Jenkins manages mobile DevOps processes, and show how it differs from a CI/CD solution that's specifically designed for mobile.

What is Jenkins and what is it good for? Jenkins is highly flexible and configurable CI/CD platform with a wide range of plug-ins. This interoperability and flexibility makes Jenkins a preferred tool, however sometimes, plug-ins are needed even for the most basic tasks, but it syncs with a wide range of platforms, operating systems, programming languages and technologies. That also allows Jenkins to integrate with other software/tools used in your company’s tech stack, such as Maven, Gitlab, SonarQube, Selenium.

As a result, its complexity and dependency is high since everything is handled by manual efforts of integrating with the right plugins.

You are also dependent on third parties, and whenever there is an issue, you have to get support from the plug-in developers themselves, the Jenkins community, or even whoever configured the platform in the first place.

How is Jenkins used for DevOps? Jenkins works as a deployable solution, which is highly scalable. It can be used in different DevOps stacks with the right configuration and the plugins.

From student projects to enterprise products, Jenkins can cover most of your needs if you deploy and set up everything by yourself. However, Jenkins can be hard to figure out as its unintuitive and outdated UI can be confusing for first-time users.

It may take a decent amount of time and effort to for new users to be comfortable with using Jenkins.

For this reason, there are many number of emerging tools that specialize on specific stacks to alleviate such issues.

Is Jenkins suitable for enterprise use and teams? Jenkins can be used in enterprises, however it requires a huge deal of customization, setup and maintenance for enterprise-oriented or team-based tasks. Since it’s not designed for large teams in mind, the management of Jenkins is generally done by a single user, which leads to tracking and accountability problems with the pushed code.

Jenkins has the risk of creating a singular “hero user” within a large team, which creates a potentially problematic dependency on top of other third-party dependencies for plugins and such.

Assigning separate users or groups to split tasks or jobs is not available and Jenkins doesn’t allow one developer to reach the activities done by another team member, readily. Tracking the overall release progress becomes a challenging job for larger projects and enterprises. Reporting is also a major feature lacked by Jenkins.

How can Jenkins be used for mobile CI/CD? Jenkins is very much like a Swiss Army Knife. It can work with many different stacks, but it’s not specialized in any of those; so in cases of complex and unique stacks like mobile, it requires a big deal of configuration, management, and many different plug-ins to set up a full pipeline.

Thus, Jenkins can solve the most common problems, but falls short in anything that requires precision without additional tools.

For instance, there is no storage for previous builds and artifacts. Therefore, users need to store their former documents and artifacts manually to reach back later.

Is it actually possible to use Jenkins with high productivity for mobile CI/CD? Build and deployment of mobile apps with Jenkins is not an easy task, and you have to maintain it all by yourself, without official support. Also, even if Jenkins itself is scalable, you will have issues with the build environments such as the unique requirement of a Mac to build iOS apps.

Jenkins is designed with freedom and flexibility in mind, but mobile stacks do not have the same freedom that backend stacks have. It is tightly controlled by the constantly changing rules and standards by Apple and Google. This increases not just the setup effort but the maintenance effort as well for mobile stacks.

What are the concerns of using Jenkins as a mobile CI/CD tool? Especially for iOS, the build environments must be on a Mac and if you have multiple projects or multiple build it is difficult to isolate them or create queues by default. Scaling is another issue. You can easily scale the Jenkins instance itself, but the scaling of build environments requires additional efforts and a special set of knowledge for macOS.

When using Jenkins for mobile app projects, the build environments usually become the performance and operations bottleneck.

With a cloud-based dedicated mobile CI/CD platform, you have higher performance all around as all relevant specifications and extensive automation is possible without third-party tools.

What is the alternative of Jenkins for mobile CI/CD?
A special case for mobile CI/CD is that the DevOps processes are usually handled by the developers themselves.
Mobile CI/CD is differentiated by the specific knowledge and the close attention required for the build and deployment processes.
With all the concerns specified in the previous items, it is common for mobile developers or any mobile DevOps specialist to look for a Jenkins alternative for mobile DevOps.
There are actually dedicated mobile CI/CD platforms that makes mobile CI/CD accessible by everyone by providing the best of both worlds set of features with high flexibility and ease of use.
Dedicated mobile CI/CD platforms that can be used in the cloud in a fully scalable manner without the need for any maintenance or hardware investment or they can be deployed on-premises for enterprises. With this way, there is no compromise from what Jenkins offers with significant value added.
Benefits of using an dedicated mobile CI/CD platform as an alternative to Jenkins
With an enterprise-oriented, specialized mobile CI/CD platform like Appcircle, you have native integrations and automated workflows.
Any issue or maintenance is handled from a single point of contact with full support.
As authorization and role management is available, proper collaboration can be achieved by the enterprise teams.
Continuous integration and delivery in mobile DevOps have a unique set of requirements and demand a dedicated mobile CI/CD tool for the highest productivity, as Jenkins alone cannot achieve.

With Appcircle, you can manage the full CI/CD pipeline of mobile apps without the need for complex integrations and multiple tools. Appcircle is specialized on the specific needs of mobile apps.

SECURITY IN APPCIRCLE

Sophie @Appcircle — Wed, 08 Sep 2021 16:34:13 +0000

Reading Time: 3 minutes

A well-established CI/CD pipeline gets entwined with many enterprise processes and the security of the pipeline gets more and more crucial. In this article, we will outline how Appcircle ensures the security of your CI/CD pipeline.

Code Security in Appcircle

Appcircle connects to your repository to fetch your projects and branches so that you can build your apps in the cloud, however the source codes are not stored in Appcircle infrastructure.
The source code is fetched for the build only to a brand-new build agent specifically created for that build. Once the build is complete, the agent is killed along with all the source code and any leftover data from the build.
GitHub, GitLab and Bitbucket are all supported by Appcircle through oAuth. The agents connecting to your repositories follow the protocols enforced by the repository providers.
For all other repository providers, the only provided option is to use SSH connections for the utmost security.
Appcircle never modifies the contents of the repository itself. During the build, it is possible to modify the contents with custom scripts and workflow steps by the user, but these are not permanent and only applicable for the local copy.
Appcircle team does not have access to the source code for any means and purposes. The oAuth tokens or the SSH keys are stored securely in an AWS vault and they are only used to fetch the branch and commit list or during the build.

Infrastructure Security in Appcircle

Appcircle fully runs on AWS, who considers cloud security as the highest priority with many built in security features and services. For more information on the cloud security, please refer to the AWS Security Center.
Appcircle is built on Kubernetes. For every single build, there is a brand-new virtual machine specifically created for you. This enables Appcircle to keep your source codes secure and isolated from others.
The virtual build agents run on an internal private network and they are not directly accessible from the outside.
Even your concurrent builds run on different containers which eliminate the chances of conflicts and instability.
After the build is done, the virtual machine is killed and there is no residual data storage.
Only the selected build artifacts and the build logs are retained, and they are not accessible by the Appcircle team.
The same level of security is also applicable for the Appcircle simulator/emulator. A brand new virtual device is generated for every session and once the session ends, the virtual device is killed and no residual data is stored.
The same also applies for the shared app preview links. For every new session, a new device is generated even though the app is the same and you can set an expiration date for the public links as well.

Data Security in Appcircle

All secret data, including the keys, signing identities, environment variables and secrets are stored in an AWS vault. Since these are highly confidential and crucial elements for DevOps, Appcircle provides the best-in-class security for any private element.
For instance, the secret environment variables (both text keys and files) are not accessible externally. They can only be utilized in a build and they cannot be exposed by the build module users (e.g. they are automatically removed from the build logs). They cannot be modified and the only way to update them is deleting and re-adding.
As for the signing identities, again, if a user does not have access to the signing identities module, they cannot view, download or edit the signing identities while being able to use them in builds.
You can be highly confident when sharing the build logs with developers or others for any kind of assistance needed. They can see neither your secrets nor the signing identities.

Enterprise-Grade User Management and Logging in Appcircle

For enterprises, Appcircle provides fine-grained permissions for all submodules so that you can manage which user can access which module in what level. This makes it well suited for team without the need to worrying about widespread access.
Appcircle provides logs for all modules so that the enterprise admin can track which build is done by whom or who ran an in-browser app preview session and when. This provides full transparency and visibility across the entire platform.

Billing Safety with Appcircle

Appcircle uses Stripe, which is world's one of the most used and trusted payment platform. Your credit card information is never stored in Appcircle and does not pass through Appcircle infrastructure.
All transactions are done exclusively through the Stripe platform directly and transactions are done with 3D Secure for the supported credit cards.

Even Higher Security with Private Cloud and On-Premise Options

The Kubernetes-based next generation architecture of Appcircle enables private cloud and on-premise deployments as well. Even though Appcircle provides high security, you can optionally ensure that the full CI/CD pipeline is hosted in your own infrastructure.

With Appcircle, you can manage the full CI/CD pipeline of mobile apps in a secure and trusted environment.

HOW TO DEPLOY IOS AND ANDROID APPS TO AWS DEVICE FARM AND RUN TESTS AUTOMATICALLY

Sophie @Appcircle — Wed, 08 Sep 2021 16:33:03 +0000

Reading Time: 5 minutes

Appcircle is a mobile CI/CD platform that provides a fully automated environment to manage mobile app CI, CD and CT (continuous testing).

For continuous testing, you have a number of options with Appcircle and you can use AWS Device Farm for multiple-device testing. In this article, we will be integrating AWS Device Farm to your mobile CI/CD workflow in a few easy steps so that you can deploy apps and run tests automatically for a complete CI-CD-CT.

Manage your mobile CI, CD and CT (continuous testing) with Appcircle

Start for Free

Adding AWS Device Farm Step to the Build Workflow

AWS Device Farm is an application testing service that enables you to run your tests concurrently on multiple mobile devices to speed up the execution of your tests and generates videos and logs to help you quickly identify issues with your app. Appcircle is integrated with AWS Device Farm for continuous testing. You can build your app in Appcircle and deploy it directly to AWS Device Farm to run automated tests.

With the "AWS Device Farm Deploy and Run" step in Appcircle, you can directly deploy your binaries and test scripts during the build to the specified AWS Device Farm project and run tests.

To start, you need to add the

"Android Build for UI Testing" step for Android
"Xcodebuild Build for Testing" step for iOS

followed by the "AWS Device Farm Deploy and Run" step to the workflow from the workflow marketplace.

If you just want to run tests, you can also remove other build steps such as "Android Build" or "Xcodebuild for Devices".

Android workflow for AWS Device Farm

iOS workflow for AWS Device Farm

Configuring the AWS Device Farm Step in the Workflow

Once these steps are added, press save to exit the workflow edit mode and click on the AWS Device Farm step.

The input values are as follows:

AWS Access Key ID: Enter the AWS access key ID. For more information, you can refer here.
AWS Secret Access Key: Enter the secret access key associated with the ID entered above. For more information, you can refer here.
AWS Default Region: Enter the AWS region where for the run. You can find the endpoint codes for the regions here.

It is highly recommended to add the keys as secret environment variables instead of typing them here for security purposes.

AWS Project ARN: The ARN of the project for deploy and run.
AWS Device Pool Arn: The ARN of the device pool for the run.
AWS Device Farm Run Name Prefix: The name prefix for the run to be scheduled. AWS Device Farm Run Test Type: The type of the test for the run.
AWS Device Farm File Upload Time Out: Time out duration (seconds) for the test file upload. The step is skipped if the time out is reached.
Maximum Waiting Time for Run Test Results: Time out duration (seconds) for the AWS Device Farm run. The step is skipped if this duration is reached, but the test execution continues in AWS Device Farm.
AWS Device Farm App ARN: The ARN of the application package to run tests against, created with CreateUpload. If you don't set this parameter, the subsequent App Upload File Name, App Upload Type and App Upload File Path parameters are required.
AWS Device Farm App Upload File Name: The file to be uploaded. The name should not contain any forward slashes (/ ). If you are uploading an iOS app, the file must have an .ipa extension. If you are uploading an Android app, the file must have an .apk extension.
AWS Device Farm App Upload Type: The upload type of the file.
AWS Device Farm App Upload File Path: The file path for the app upload.
AWS Device Farm Test ARN: The ARN of the uploaded test to be run. If you don't set this parameter, the subsequent Test Upload File Name, Test Upload Type and Test Upload File Path parameters are required.
AWS Device Farm Test Upload File Name: The test file to be uploaded. The file must have a .zip extension.
AWS Device Farm Test Upload Type: The upload type of the test.
AWS Device Farm Test Upload File Path: The file path for the test upload.
AWS Test Spec ARN: The ARN of the uploaded test spec to be run.
AWS Test Spec Upload File Name: The test spec file to be uploaded.
AWS Test Spec Upload Type: The upload type of the test spec.
AWS Test Spec Upload File Path:The file path for the test spec upload.

For the details of the AWS Device Farm-specific parameters, please refer to the following documents:

create-upload --- AWS CLI Command Reference -- to upload apps and tests
schedule-run --- AWS CLI Command Reference -- to run tests

Running the Build with the AWS Device Farm Step

After you save your settings, you can run the build automatically with the triggers or run it manually and the step will be executed accordingly. You can view the details of the upload operation in the build logs:

After you save your settings, you can run the build and the step will be executed accordingly. You can view the details of the AWS Device Farm Deploy and Run step in the build logs:

Building and deploying apps automatically for AWS Device Farm

The full details of the tests are accessible in the AWS Device Farm console.

An automated test run on AWS Device Farm

With Appcircle, you can automate the full lifecycle of your mobile app with continuous integration, continuous delivery and continuous testing.

GUIDE TO BUILDING FLUTTER WEB APPS WITH APPCIRCLE

Sophie @Appcircle — Wed, 08 Sep 2021 16:29:06 +0000

Reading Time: 2 minutes

Appcircle is a mobile CI/CD platform that provides a fully automated environment to manage mobile app lifecycle end-to-end, transforming DevOps to NoOps with the best practices and the Flutter framework is an open-source user interface toolkit created by Google.

Flutter app development is done with the Dart language and you can develop iOS, Android, and web apps with Flutter.

Appcircle supports the full lifecycle of Flutter apps for all Flutter CI/CD needs. In this article, we will be building a Flutter web app with Appcircle. For a full overview on mobile CI/CD with Flutter and Appcircle, please refer to this post.

Build Flutter mobile and web apps with Appcircle

Start for Free

If your app supports Flutter Web, you can also build the Flutter web app along with the Flutter iOS or Android build.

Flutter Web Build is available as a workflow step in the workflow marketplace. Just configure your project as you would for iOS or Android and add the Flutter Build for Web step anywhere after the Flutter Install step to include a web build in the workflow.

If you want to build your Flutter project only for web, you can add a Flutter Android project in the standard way, save your project configuration once, and then remove all the Android-related steps from the build workflow.

In this case, the workflow may look like the following:

If you want to deploy your web output automatically, you can use a Custom Script or upload it to Amazon S3.

Once your build is configured, it can be built manually or automatically in the same way with other apps. Your app will be built in the beta channel to enable web builds.

After a build, you can download the web build output manually from the build artifact list as the web.zip file.

With Appcircle, you can manage the CI/CD of your Flutter web, iOS and Android apps for free.

Start Using Appcircle Now

12 App Store Review Tips: How to Get Along Well with Apple and Avoid App Rejections

Sophie @Appcircle — Wed, 08 Sep 2021 16:28:32 +0000

Reading Time: 5 minutes

This article may look like another article about the common app rejections by the App Store reviewers; though it's not.

Even Apple itself is very open about this subject and they have an official guide on common app rejections in the app review. So we will rehash these from a positive perspective instead by focusing on how you can develop your app in such a way that it is well-received by Apple. For a much better app, don't ask yourself the question "How can I avoid being rejected?", instead ask yourself, "How can I make Apple like my app?"

With such a positive approach, you can avoid rejection and also get a chance to become a "featured app". Let's dive deeper into the important points to increase your chances to be noticed by Apple.

12 Tips to get along well with Apple for app reviews

1. Everyone likes crash-free apps

One of the most important aspects of having a well-received app is to have it well-tested with minimal bugs and no crashes. It may be inevitable to have small bugs, but crashes are another thing, and no one, including Apple, does not like crashes.

For this reason, make sure that your application is tested thoroughly in different conditions. For this purpose, you can use the Appcircle Distribute module for manual testing in the browser or on real devices. For automated testing, you can use AWS Device Farm and Firebase Test Lab in your Appcircle CI/CD workflows.

2. Your app must be an app and an iOS-worthy one for Apple

This one looks straightforward, but for one reason or another, developers may be inclined to use WebViews for certain functionality, but Apple recommends using native functionality over WebViews.

Apps with no native functionality are rejected outright, but in any case, Apple likes apps with full native functionality more than the apps with a more hybrid approach.

3. Reasonable and transparent advertising

It is perfectly fine to have a solid business model for your app, but transparency and respect for users' privacy are very important for Apple for any app.

For instance, if you specify that you have no ads in your app you need to make sure that there are no ad frameworks present and no ads are displayed.

If you are transparent about your business model, it would be highly likely to be better received by Apple.

4. Attention to transparency and privacy

Similarly, your app should have a clear privacy policy and any data collection must be done transparently with an opt-in manner.

Apple differentiates itself from others such as Google and Facebook with its emphasis on user privacy so any app sharing the same privacy-focused approach is preferred.

5. Adhering to the app permission rules and best practices

Another point regarding privacy and transparency is requesting the permissions the right way. You should not ask for additional permissions than absolutely necessary and the reason for each permission request must be explained clearly.

One of the most common rejection reasons is the missing permission request description in Info.plist file.

As per Apple's focus on privacy, the way the permissions are requested, and the way the sensitive features are used are thoroughly reviewed.

6. The infamous "Restore Purchases" button

Another common review point is the "Restore Purchases" button. Any app that provides in-app purchases must have this button within the app.

Again, it is all about these small details that make an app noticed or rejected by Apple.

7. The mention of Android and the exclusivity

Talking about small details, we should also point out that Apple also cares about the presentation and exclusivity. If the app description includes any references to Android or if the screenshots are coming from an Android device, the app is rejected right away. On the other hand, if an app is exclusive to the App Store, then it has a higher chance to be featured.

8. Do not underestimate the importance of the app metadata

App Store listing description is indeed as important as the app itself. If you are keyword spamming in the app name or description or if the description is too short, the app will be rejected.

Even though smart app store optimization (ASO) tricks are welcome, your primary objective should be providing insightful and meaningful descriptions. If the app description conveys the value of the app in an exemplary way, you also have a higher chance of getting more downloads and getting noticed. Keep in mind that being featured provides as high visibility as keyword optimization, if not more.

This also applies to screenshots. Your screenshots should be relevant to the app and they must come from the actual form factor (e.g. iPad or iPhone) and of course, not from an Android device. Beautiful screenshots always attract more users and complement Apple's attention to beautiful design.

9. What the user sees must be what the user gets

Two other points regarding the app description are that it should not contain any pricing information and any features that are "in roadmap" or "coming soon".

It must be a reflection of the currently available features. You must also refrain from classifications like "beta" or "testing".

10. App Store is no place for pre-release apps

Anyway, any pre-release version of an app belongs to TestFlight or platforms like the Appcircle Distribute module, so you should avoid submitting pre-release apps entirely, not just avoid mentioning it in the description.

This also applies to apps designed for private use such as an in-house enterprise or a closed group of people. In such a case, you should ideally be distributing your app through an Enterprise App Store with Enterprise or Ad Hoc certificates. However, also note that these certificates also have certain terms, so you cannot use them for public distribution out of the App Store.

11. Take advantage of Continuous Integration, Delivery and Testing to deliver the highest quality

There are so many details to take note of to get along well with Apple, but it all comes down to having a high-quality app. If your app crashes right away, even the most amazing screenshot in the world does not matter.

For this reason, you need to have a full CI/CD/CT (Continous Integration, Delivery, and Testing) pipeline set up for your project so that you can make sure that you can provide the best quality with the highest productivity. With Appcircle, you can manage the CI/CD/CT of your iOS apps for free.

Build, deploy and test high-quality iOS apps without a Mac!

Start for Free

12. You actually have a direct line to Apple

The last but not the least important tip to get along well with Apple is to make life easy for the reviewers. Better descriptions and screenshots surely help with this, but you actually have a more powerful tool in your arsenal, which is the notes to the reviewer field.

This is your direct connection to Apple so use it wisely and reasonably. If you have sample credentials, you must specify them here, but you can also specify instructions or certain features that are not visible at first sight. If you have exceptional cases for any reason, you can specify them here so that they are not classified as bugs. (Not a bug but a feature!)

Special thanks to Celil Bozkurt for his contributions to this article.

CUSTOMER SUCCESS STORY: WEBEE STREAMLINES THE DEPLOYMENT OF HUNDREDS OF APPS WITH APPCIRCLE

Sophie @Appcircle — Wed, 08 Sep 2021 16:27:30 +0000

Reading Time: 2 minutes

Overview

WeBee is an award-winning guest engagement platform, which provides a mobile guest engagement solution with social distancing and contactless features for more than 150 hotels in 20 countries globally. Hotel guests can make any of their requests via their smartphones (iOS & Android) without a need for face-to-face communication.

Their digital solution enhances guest experience and improves guest satisfaction. Users can handle everything through the app, such as reservation, transfer opportunities, check-in/out, or in-room dining/laundry/housekeeping requests.

Challenges

WeBee uses a mono-repo (single codebase) approach to create and deploy multiple white-label apps for Google Play Store and Apple Store.

End-users experience different interfaces as the hotel-specific apps have different branding with dynamic app name, icon, and content supplied by the clients' content management systems.

WeBee's database runs on AWS, and it directs user requests from the end user apps to the staff app of the specific hotel. Those apps are updated with new features from a single, unified codebase, but required separate app builds for each white-label client. Thus, the team manually signed unique apps and submitted them to the app stores from different publisher accounts.

That was taking a tremendous amount of time and manual effort before they met Appcircle.

Appcircle upped the game for us for achieving the highest efficiency in deploying and managing hundreds of mobile apps under different brands, strengthening our leadership with our unique focus on mobility.

Ozgur ZanFounder -- WeBee

Results

WeBee streamlined and automated mobile DevOps processes with Appcircle.

They manage all updates efficiently as tagging code commits with hotel name triggers build for specific clients.
Appcircle can then automatically build any requested version of the app with the specific customizations for that client.
They use the Appcircle online emulator/simulator to provide clients instant app previews, where they can approve the final version immediately.
Publishing the client apps under their own publisher accounts has also been automated. WeBee linked various Google Play IDs and Apple Developer IDs to lead deployments in Appcircle.

The mobile CI/CD pipeline of the WeBee apps is fully automated with tagged pushes from a single codebase, resulting in significant improvements in productivity and time-to-market.

HOW TO USE FASTLANE WITH APPCIRCLE FOR AUTOMATED MOBILE CI/CD

Sophie @Appcircle — Wed, 08 Sep 2021 16:26:03 +0000

Reading Time: 4 minutes

Appcircle is a mobile CI/CD platform that provides a fully automated environment to build and deploy apps, which also supports *fastlane *for build automation.

With Appcircle, you can automate your build and signing processes with the flexible workflow structure and you can also use fastlane *as a workflow step within the build workflows. To use *fastlane, Appcircle expects the presence of a fastfile in your repository.

Manage your mobile CI, CD and CT (continuous testing) with Appcircle

Start for Free

How Does Fastlane Work with Appcircle

fastlane is an automation tool for mobile app build and deployment and just as the name indicates, it provides a "fast lane" for mobile app projects by running the command line tools like xcodebuild. It can automate and simplify these processes and even though you can use it locally, it works best in tandem with CI/CD tools. It is especially popular with the traditional, general-purpose CI/CD tools that don't support mobile app projects out of the box.

Mobile CI/CD tools like Appcircle can already automate the full mobile CI/CD process without the need for fastlane or any third-party tool. However, if you already have a project configured for Fastlane or if you have very specific dependencies on certain fastlane features, you can use it within Appcircle. With this way, you can actually enhance your fastlane flows with the advanced automation and workflow features of Appcircle. Moreover, you can use Appcircle Centralized Signing Identities or Appcircle Distribution or even the Appcircle In-Browser Emulator for your apps built with fastlane.

How to Use Fastlane in the Mobile CI/CD Workflow

Setting up fastlane with Appcircle is very easy. You just add fastlane as a step and you just need to have a fastfile present in your repository. Appcircle will take care of fastlane installation and automation.

The default actions are supported (such as fastlane gym, fastlane cocoapods, fastlane gradle for building iOS and Android apps, fastlane scan for testing apps, fastlane pilot and fastlane supply to send apps to App Store Connect (formerly iTunes Connect) and TestFlight, fastlane deliver to send apps to Google Play Store, etc.)

Appcircle supports different types of mobile app projects so that you can use fastlane iOS, fastlane Android, fastlane React Native and fastlane Flutter. You can opt in to use Appcircle counterparts of the fastlane actions as well. Appcircle workflow feature enables cherry-picking mobile CI/CD steps.

Creating a Build Profile to Connect Your Repository with a Fastfile

In Appcircle, a build profile contains the build workflows and the configuration of an app per target platform. (i.e. separate for iOS and Android).

To create your first build profile, go to the "Build Module". (The first item on the left menu) and click on the orange "Add New" button on the top right of the screen.
In the next screen, enter a name for your build profile and select the target operating system (iOS or Android) and the target platform (Obj-C/Swift, Java/Kotlin, React Native and Flutter projects are supported). If you have two different targets in your project for iOS and Android, you need to create two separate profiles. This allows you to manage separate build workflows for different operating systems.
Once created, click on the build profile to connect your repository that contains a fastfile. You can connect private and public repositories on GitHub, Bitbucket, GitLab and other compatible git providers. You can authorize Appcircle to connect to your cloud repository provider account. This will allow you to use auto-build your project with hooks.
The build configuration has different flows for iOS and Android and the projects are configured on a branch basis. You can have different configurations for different branches and you can build any of your commits (assuming that they are compatible with the current configuration).
You can use *fastlane *with the signing configuration defined in the lane or you can configure your build to use Appcircle centralized code signing as an alternative to *fastlane *match.

Adding fastlane to the Appcircle Build Workflow as a Step

A workflow in Appcircle is a ladder of steps taken to build your applications. Each step has a different purpose and the workflow can be customized by modifying step parameters and inputs, running custom scripts or re-ordering steps.

To utilize *fastlane *in your builds, open the workflow editor and add the "fastlane" step after the "Git Clone" step.
If you want to run a specific fastlane *command, you can add a "Custom Script" step anywhere after the *fastlane step.
Once added, click on the *fastlane *step to configure it. Fastlane is easy to use with Appcircle just with two options.
The "Fastlane Directory" option is used to specify the fastfile path . If you keep your fastfile in its default location, it is automatically used without the need to change this field.
With the "Fastlane Lane" option, you can specify which lane to use.
Once everything is set up, press Save to save your step configuration. Then you can configure and run your build just like any other app.

Appcircle also supports building and signing the app independently with the "Build" and "Sign" steps in the workflow. These steps can be used in parallel with fastlane.

Running the Build Workflow

To run the build workflow that includes the *fastlane *step, you can start a manual build or trigger an automatic build.

The full output of the *fastlane *execution can be viewed in the build log in real-time or after the build.

Deploying the fastlane Build Output

You can use *fastlane *to deploy the built apps to the supported third-party services or you can use the Appcircle Distribute module to share the app with the testers or send it to the public app stores.

Further Documentation

For more information, screenshots, and support, please refer to the Appcircle documentation.

With Appcircle, you can automate the full lifecycle of your mobile app with continuous integration, continuous delivery and continuous testing.

Start Using Appcircle Now

HOW TO TEST YOUR MOBILE APPS IN THE BROWSER

Sophie @Appcircle — Wed, 08 Sep 2021 16:21:40 +0000

HOW TO TEST YOUR MOBILE APPS IN THE BROWSER

Reading Time: 3 minutes

One of the most challenging parts of mobile application development is testing. iOS and Android mobile apps need to be tested on a wide range of devices from various manufacturers and form factors with different operating system versions to ensure compatibility and stability.

From iPhone SE to iPhone 11 Pro or from a Samsung Galaxy to a Xiaomi Redmi Note, the mobile apps must be compatible with many different mobile devices.

Testing a mobile application on physical devices can be virtually impossible due to the large number of different devices being used all around the world. This leaves a mobile development team with only two options to test mobile applications on mobile phones or tablets, which are simulators and emulators.

What is the difference between Simulators and Emulators for Mobile App Development?

While they look (and sound) similar, mobile device simulators and emulators have distinct differences.

Emulators imitate the software and the hardware environments of the target mobile devices while simulators provide only software environment imitation and they use the host system's hardware resources such as processors, memory and network connectivity
Emulators are better for debugging purposes but simulators won't be much use for debugging your mobile application
Emulators usually act slower than simulators since they imitate the hardware of the mobile device when simulators are software-based
A good example of a mobile device emulator is Google Android SDK. A good example of a mobile device simulator is Apple's iOS Simulator.

Emulators imitate the software and the hardware environments of the target mobile devices. (i.e. Running an authentic ARM architecture on an x86 environment.) Simulators, on the other hand, provide only software environment imitation and they use the host system's hardware resources such as processors, memory and network connectivity. (i.e. running iOS and Android directly on an x86 environment.)

Android in that sense is an open platform and you can run Android emulators on any desktop operating system whether macOS or Windows; however things are more complicated if you are looking to download an iOS emulator. Emulating iOS hardware is not just limited by Apple's license agreements (e.g. Xcode on Windows is not directly possible), but also there are certain technical challenges toward iPhone emulators.

Appcircle can help you test your mobile application on your web browser by providing you a web-based, in-browser, iOS simulator, which is the closest you can get to an online iPhone emulator on Windows, macOS, Linux or any other desktop OS.

Appcircle offers various simulation options for the device, screen size and operating system versions for iOS and Android which gives you a broad range of selection to test your mobile applications. You don't even need to download any large emulator stacks, you can run and test your mobile apps in the cloud.

Having access to a number of iPhone, iPad and Android mobile and tablet devices online lets you make sure your application will function as expected if you have a specific audience using a specific form factor and operating system combination.

Mobile applications that are built with Appcircle's build module can be previewed on a device emulator or simulator instantly with a single click. You can test the native functionality of your applications without the need for using a real device.

If you have an application that was built earlier, you can simply upload your compatible application binary file (built with x86 architecture on Android or the simulator binary for Xcode) to Appcircle's distribution module and preview the application on a mobile device emulator on a web browser for Android or on a mobile device simulator for iOS.

Click here for more information about the Appcircle emulator

HOW TO INTEGRATE FIREBASE TEST LAB TO THE MOBILE CI/CD PIPELINE FOR ANDROID

Sophie @Appcircle — Wed, 08 Sep 2021 16:20:30 +0000

Reading Time: 4 minutes

Appcircle is a mobile CI/CD platform that provides a fully automated environment to manage mobile app CI, CD and CT (continuous testing).

For continuous testing, you have a number of options with Appcircle and you can use Firebase Test Lab for multiple-device testing. In this article, we will be integrating Firebase Test Lab to your mobile CI/CD workflow in a few easy steps.

Manage your mobile CI, CD and CT (continuous testing) with Appcircle

Start for Free

Setting Up a Firebase Project and a Service Account

To start with the Firebase Test Lab, you need to have an associated Firebase Project, which is created in the Firebase console. Go to the console, press the "Add Project" button and specify the project name and the other settings:

After your project is created, go to the Google Cloud Platform console to create a service account. Press the "Create Service Account" button and follow the prompts to create a service account with the Editor role:

Once the service account is created, click on the three dot menu next to the service account and press "Create Key".

Select the key format as "JSON" and download the created key. We will be using this key for Appcircle to be able to deploy apps to Firebase Test Lab.

As the final step, go to the Google Developers Console API Library page and find and enable the following APIs:

Google Cloud Testing API
Cloud Tool Results API

Firebase Test Lab Authentication Configuration in Appcircle

To start, go to the environment variables section and add the service account JSON key created in the previous step as a new environment variable. Take a note of the variable name, which will be necessary in the workflow configuration.

Then select the related environment variable group in the build configuration of the project that will be using Firebase Test Lab.

Build Workflow Configuration for Firebase Test Lab

To utilize Firebase Test Lab in your builds, open the workflow editor and add the "Firebase Test Lab for Android" step after the build or sign steps. If you want to run instrumentation tests, also add the "Android Build for UI Testing" step before the Firebase Test Lab step.

If you want to use the UI Test Build output or the Signed Build output in Firebase Test Lab, add any of these steps before the Firebase Test Lab step and take a note of the output path of these steps. You will need this environment variable for testing configuration.

Before the build, the last task is to configure the Firebase Test Lab for Android step:

Project ID: Enter the name of the Firebase project created
Key File: Enter the name of the key file uploaded as an environment variable ($ is required before the key name).
Test Type: Select a test type. robo and instrumentation are supported.
Bucket Name: Enter a bucket name to store the test results in a Google Cloud Storage bucket.
APK Path: The default value is the APK produced by the "Android Build" step. You can specify a different environment variable to use the APK files produced in other steps.
Test APK Path: Specify the environment variable to the path of the APK build for UI testing
Extra Arguments: For further configuration of the test run. Please refer to the Google Cloud CLI Documentation.

Once everything is set up, press save to save your step configuration. Then you can configure and run your build just like any other app.

Viewing the Firebase Test Lab Step Results

Once your build is done, you can view the results of the Firebase Test Lab step in the build logs.

The full details of the tests are accessible in the Firebase console and in your Google Cloud Storage bucket for analysis.

With Appcircle, you can automate the full lifecycle of your mobile app with continuous integration, continuous delivery and continuous testing.

Start Using Appcircle Now

GUIDE TO AUTOMATED MOBILE CI/CD FOR REACT NATIVE WITH APPCIRCLE

Sophie @Appcircle — Wed, 08 Sep 2021 15:25:02 +0000

Reading Time: 8 minutes

Appcircle is a mobile CI/CD platform that provides a fully automated environment to manage mobile app lifecycle end-to-end, transforming DevOps to NoOps with the best practices.

Appcircle supports the full lifecycle of React Native apps for all CI/CD needs. In this article, we will be building and deploying a React Native app with Appcircle with no need for a Mac or any third-party tools.

Build, distribute and test your React Native project quickly with Appcircle

Start for Free

The first step is getting started with Appcircle. Just go to https://appcircle.io/start and register. (Regardless of the login provider you select, you can connect any other provider for the repository connections.)

Creating a Build Profile for a React Native Project

In Appcircle, a build profile contains the build workflows and the configuration of an app per target platform. (i.e. Separate for iOS and Android).

To create your first build profile, click on the orange "Add New" button on top right of the screen.

Enter a name for your build profile and select the target operating system (iOS or Android) and the target platform as React Native. If you have two different targets in your project for iOS and Android, you need to create two separate profiles. This allows you to manage separate build workflows for different operating systems.

You will see your build profile once it has been created. Click on the build profile to connect to a repository that contains a valid React Native app.

You can connect GitHub, Bitbucket and GitLab repositories to your build profile through oAuth apps. Alternatively, You can connect private repositories through SSH and public repositories directly on GitHub, Bitbucket, GitLab and other compatible git providers.

You can authorize Appcircle to connect to your cloud repository provider account. This will allow you to use auto-build your project with hooks. If you authorize Appcircle to access your repositories, you can select the repository that you want to connect. If you use a private repository using an SSH Key, you need to have an SSH key pair ready and enter your private key to Appcircle so Appcircle can access your repository.

Appcircle will then pull your branches, commits, and other information from your repository.

To test drive the Appcircle platform for React Native app builds, you can also use our sample React Native App by forking it or adding it as a public repository: https://github.com/appcircleio/appcircle-sample-react-native

React Native Application Build Configuration for iOS and Android

The build configuration has different flows for iOS and Android and the projects are configured on a branch basis. You can have different configurations for different branches and you can build any of your commits (assuming that they are compatible with the current configuration).

iOS Build Configuration

Click on the gear icon on the top right to access the build configuration. The first step will be entering the project details. You can enter these details manually or click on the Fetch button to retrieve them from your project to detect the correct path for the Xcode project automatically.

Your iOS project needs to have an Xcode project or an Xcode workspace and a shared scheme to complete the build configuration successfully. Appcircle can fetch these workspaces and shared schemes from your branch automatically.

You can also select a specific Xcode version if you have certain dependencies or if you want to test your build on a specific version.

Android Build Configuration

Click on the gear icon on the top right to access the build configuration. The first step will be entering the project details. You can enter these details manually or click on the Fetch button to retrieve them from your project to get the available modules and the variants in your project. You can also select the output type (APK or Splik APK as AAB).

Build Triggers for Auto Builds

The next section, Triggers, is common for both iOS and Android.

Appcircle allows you to trigger builds manually or automatically using build triggers.

On push: Whenever code is pushed to a configured branch, the build is triggered.
On a tagged push: Whenever a tagged commit is pushed, the build is triggered for that commit. Commits without any tags are ignored.
On push with selective tags: Whenever a commit includes one of typed in tags, the build is triggered. You can specify tags with Unix shell-style wildcards to trigger builds.

Signing Configuration

Appcircle allows you to sign your app for deployment.

Appcircle is unique that it doesn't require you to generate signing identities with a third-party tool. You can simply create your iOS certificates/profiles and Android keystores within the platform and use them in any project in a centralized manner.

If you have readily available signing identities, you can also upload them once to the Appcircle Signing Identities module and use them centrally in any project. (No need for separate uploads of the same certificate for separate projects.)

For more information on iOS certificate and provisioning profile management, please refer to the following document: https://docs.appcircle.io/signing-identities/ios-certificates-and-provisioning-profiles
For more information on Android keystore management, please refer to the following document: https://docs.appcircle.io/signing-identities/android-keystores

For signing iOS apps, press add, select the bundle ID from the first dropdown and then select a compatible provisioning profile (added from the signing identities module) from the second dropdown.

For signing Android apps, simply select a keystore (added from the signing identities module).

Distribution (Deployment) Configuration

Appcircle is an end-to-end mobile CI/CD tool and enables you to build and deploy your apps to mobile devices with full automation.

Distribution is a critical step when it comes to test your application on real devices. You may need multiple testers and test groups to download, install, and test your application and make sure it works on different devices and operating system versions.

Distribution configuration allows you to set up which testing groups will receive your application after the build is complete. You can manually send your binary file to testers or Appcircle can do this for you.

For more information on how to set up testing groups and deploy your app after the build, please refer to the following document: https://docs.appcircle.io/distribute/create-or-select-a-distribution-profile.

You can select a previously created distribution profile or create a new one in this window. Use the top input box to enter a name for the new distribution profile you want to create. Press enter or click on the green + icon on the right to create the distribution profile.

Finally, check Auto Distribute if you want your build to be sent to the distribution profile automatically. If the target profile has autosend configured, your testers will receive the latest version automatically.

There are three main automation points in Appcircle:

Autobuild: builds new pushes automatically
Autodistribute: deploys new binaries automatically to the Appcircle Distribute module, where you can use it with the online mobile device simulator/emulator or share with the testers.
Autosend: Sends new versions of the apps automatically to the selected testing groups.

Environment Variables Configuration

The final tab is to add environment variables to the build. For advanced use cases, you can define variables and secrets to be incorporated during the build in the Environment Variables submodule so that you don't need to store certain keys and configurations within the repository.

Workflows for Advanced Build Configuration

Appcircle is a simple, but flexible platform. You can make basic changes in a simple user interface with the build configuration and use the workflows for advanced use cases. A workflow is a ladder of steps taken to build your applications. Each step has a different purpose and the workflow can be customized by modifying step parameters and inputs, running custom scripts or re-ordering steps. Workflows allow you to have complete control on your build process and enhance it with third-party services and features.

Also note that the workflows are set up by default, so you don't need to set them up for builds.

For more information on the workflows, you can refer to the following document: https://docs.appcircle.io/workflows/why-to-use-workflows

You have a wide variety of options with workflows. For instance, if you want to run a specific npm command before or after the build, you can add a custom script step at any point in the workflow. If you want to deploy your app with a third-party service instead of Appcircle, you can configure it with the workflows.

Starting a Build and After a Build

To start your first build, just press the start build button -- the play button under the actions columns (or push some code to your repo if autobuild is configured.)

You will see the build progress and the log in realtime.

Once your build is complete, you can now download the binary file or deploy it to distribute module manually (if autodistribute is enabled, it will be sent automatically after a successful build).

You can also view or download your build logs anytime.

Testing the React Native App

With Appcircle, you have two options to test your app. You can use the standard unit testing workflows by adding the related Android and iOS test steps or by running custom scripts or as for the second option, you can use the Appcircle in-browser mobile device emulator/simulator to run your app for manual testing.

Deploying Your App to the In-Browser Emulator

If you set a distribution profile in the distribution configuration, you can deploy your app and share it with the testers or preview them right in your browser in the online Android emulator or the iOS Simulator.

In the Distribute module, click on the selected profile, select your OS on the top left and then select a version. To run that version in the online emulator, just press the "Preview on Device" button on the top right. (Your app must support the x86 architecture for this feature to work.)

With Appcircle, you can manage the CI/CD of your React Native apps for iOS and Android for free.

Start Using Appcircle Now

GUIDE TO FLUTTER WEB CI CD, WITH APPCIRCLE

Sophie @Appcircle — Tue, 24 Aug 2021 16:33:07 +0000

Reading Time: 2 minutes

Flutter app development is done with the Dart language and you can develop iOS, Android, and web apps with Flutter.

Build Flutter mobile and web apps with Appcircle

Start for Free

If your app supports Flutter Web, you can also build the Flutter web app along with the Flutter iOS or Android build.

In this case, the workflow may look like the following:

If you want to deploy your web output automatically, you can use a Custom Script or upload it to Amazon S3.

Once your build is configured, it can be built manually or automatically in the same way with other apps. Your app will be built in the beta channel to enable web builds.

After a build, you can download the web build output manually from the build artifact list as the web.zip file.

With Appcircle, you can manage the CI/CD of your Flutter web, iOS and Android apps for free.

Start Using Appcircle Now

DEV Community: Appcircle.io

What is CI/CD and Why Do You Need CI/CD in Mobile App Projects

What is Continuous Integration and Continuous Delivery?

So, then, what is a pipeline (CI and CD)?

How do CI and CD relate to some of the most prominent problems in mobile app projects?

Why do you need Continuous Integration in mobile app projects?

Why do you need Continuous Delivery in mobile app projects?

What's Next?

Why Do You Need a Dedicated Mobile CI/CD Platform Instead of Jenkins

SECURITY IN APPCIRCLE

Code Security in Appcircle

Infrastructure Security in Appcircle

Data Security in Appcircle

Enterprise-Grade User Management and Logging in Appcircle

Billing Safety with Appcircle

Even Higher Security with Private Cloud and On-Premise Options

HOW TO DEPLOY IOS AND ANDROID APPS TO AWS DEVICE FARM AND RUN TESTS AUTOMATICALLY

Adding AWS Device Farm Step to the Build Workflow

Configuring the AWS Device Farm Step in the Workflow

Running the Build with the AWS Device Farm Step

GUIDE TO BUILDING FLUTTER WEB APPS WITH APPCIRCLE

12 App Store Review Tips: How to Get Along Well with Apple and Avoid App Rejections

12 Tips to get along well with Apple for app reviews

1. Everyone likes crash-free apps

2. Your app must be an app and an iOS-worthy one for Apple

3. Reasonable and transparent advertising

4. Attention to transparency and privacy

5. Adhering to the app permission rules and best practices

6. The infamous "Restore Purchases" button

7. The mention of Android and the exclusivity

8. Do not underestimate the importance of the app metadata

9. What the user sees must be what the user gets

10. App Store is no place for pre-release apps

11. Take advantage of Continuous Integration, Delivery and Testing to deliver the highest quality

12. You actually have a direct line to Apple

CUSTOMER SUCCESS STORY: WEBEE STREAMLINES THE DEPLOYMENT OF HUNDREDS OF APPS WITH APPCIRCLE

Overview

Challenges

Results

HOW TO USE FASTLANE WITH APPCIRCLE FOR AUTOMATED MOBILE CI/CD

How Does Fastlane Work with Appcircle

How to Use Fastlane in the Mobile CI/CD Workflow

Creating a Build Profile to Connect Your Repository with a Fastfile

Adding *fastlane *to the Appcircle Build Workflow as a Step

Running the Build Workflow

Deploying the fastlane Build Output

Further Documentation

HOW TO TEST YOUR MOBILE APPS IN THE BROWSER

What is the difference between Simulators and Emulators for Mobile App Development?

HOW TO INTEGRATE FIREBASE TEST LAB TO THE MOBILE CI/CD PIPELINE FOR ANDROID

Setting Up a Firebase Project and a Service Account

Firebase Test Lab Authentication Configuration in Appcircle

Build Workflow Configuration for Firebase Test Lab

Viewing the Firebase Test Lab Step Results

GUIDE TO AUTOMATED MOBILE CI/CD FOR REACT NATIVE WITH APPCIRCLE

Creating a Build Profile for a React Native Project

React Native Application Build Configuration for iOS and Android

iOS Build Configuration

Android Build Configuration

Build Triggers for Auto Builds

Signing Configuration

Distribution (Deployment) Configuration

Environment Variables Configuration

Workflows for Advanced Build Configuration

Starting a Build and After a Build

Testing the React Native App

Deploying Your App to the In-Browser Emulator

GUIDE TO FLUTTER WEB CI CD, WITH APPCIRCLE

Adding fastlane to the Appcircle Build Workflow as a Step