DEV Community: Sophie @Appcircle

The Journey of Microsoft App Center: A Retrospective from Birth to Sunset

Sophie @Appcircle — Wed, 17 Apr 2024 18:28:42 +0000

The Genesis of App Center

After Apple launched iOS and Google introduced Android, both achieving great results, Microsoft decided to make a move to strengthen its presence in the mobile ecosystem. However, the "Windows Phone" domain did not experience the expected growth in the industry, and market focus shifted towards iOS/Android-based smart devices.

Consequently, Microsoft developed a new strategy to reposition itself in the sector. Instead of competing by introducing new devices, it chose to develop platforms that would serve iOS/Android developers.

This initiative began with Microsoft's release of the "Xamarin" development framework in May 2011. Xamarin provided C#/.NET developers with a cross-platform development environment, enabling them to create iOS and Android applications. This framework quickly became popular, enabling thousands of ".NET developers" to become "mobile developers," and highlighting the need for server-based services. To respond quickly, Microsoft acquired HockeyApp in November 2014, making its first step into cloud-based mobile services. This acquisition was also part of Microsoft's efforts to expand its range of mobile application development tools and services.

In March 2017, Microsoft consolidated all of its mobile-related cloud services, including Xamarin Test Cloud, HockeyApp, and CodePush, with the goal of providing a comprehensive 360-degree suite of tools for mobile developers. This initiative led to the launch of the MS App Center. The development framework "Xamarin," paired with the cloud service "MS App Center," effectively addressed a wide array of needs for mobile developers.

The Rise of App Center

Alongside supporting the Xamarin ecosystem with App Center services, Microsoft also positioned itself as an alternative to Google Firebase and AWS Amplify, thus solidifying its place in the mobile ecosystem.

After a while, Microsoft began to develop "DevOps" features in addition to the "runtime features" on App Center. Starting with "Xamarin" and later extending compilation support to "Native iOS", "Native Android", and "React Native", Microsoft App Center solidified its position in the industry.

As the mobile ecosystem entered a new era, Microsoft accelerated the adoption of App Center by addressing specific challenges such as the lack of specialized CI/CD products for mobile projects and developers' limited access to MAC OS build machine.

App Center offered a comprehensive suite of services (almost for free) like Error Tracking and Reporting, Mobile Analytics, Beta Test Distribution, Push Notifications, Code Push, App Build for Mobile and Windows, etc., which significantly attracted the industry’s interest.

While Microsoft Azure DevOps continued to evolve in the backend DevOps area, MS App Center became more prominent on the mobile front. Integrations between Azure DevOps and MS App Center increased enterprise adoption of App Center.

App Center became a preferred choice for beta distribution among many companies. Over time, it started surpassing Google Firebase and AWS Amplify in this regard.

The Retirement of App Center…

While Microsoft managed sustained success with Xamarin, the usage metrics for App Center were satisfactory. However, App Center was not commercially profitable, and the emergence of alternatives like Xcode Cloud and Appcircle increased competition. The rise of Firebase’s runtime features also created alternatives to App Center, prompting Microsoft to reassess its strategies.

While Microsoft continued to make significant investments in Azure DevOps, it defined a new strategy and began recommending the more corporate solution of the Azure DevOps family instead of App Center. As the DevOps sector began to rise in the early 2020s, Microsoft continued to position Azure DevOps as an alternative to other players in the industry such as GitLab CI, Circle CI, and Jenkins. I'm not even mentioning the acquisition of Github, as that is a completely parallel strategy.

In recent years, MS App Center has increasingly failed to meet the industry's needs. Its lack of support for Flutter, not prioritizing issues on Github, and failing to meet roadmap targets indicated a decline in its priority within Microsoft. However, because it did not produce a solution in the Mobile DevOps area, the closure of MS App Center was not widely anticipated.

Currently, Microsoft is focusing on growing within the Community through Github Actions, while continuing to emphasize Azure DevOps in the Enterprise world. For mobile needs, it is trying to address Runtime features (Error Tracking and Reporting, Mobile Analytics) by directing them towards Azure services for solutions.

Exit Planning from App Center

Considering the services provided by App Center, I would like to share some alternatives:

Build: App Center’s build feature was relatively limited, but it filled a crucial gap especially in Xamarin and Windows builds. For mobile solutions, transitioning to Appcircle Build and Xcode Cloud might be necessary, although custom pipelines will be needed for Xamarin and Windows.

Beta Distribution: One of App Center’s most popular features was its Beta Distribution capability used for distributing mobile packages. Alternatives like Appcircle Testing Distribution and Google Firebase can be considered. If you need more corporate capabilities (SSO/LDAP Login, Pipeline Integration, Reporting, etc.), Appcircle offers a good solution, while Google Firebase can be considered for community-based products.

Analytics & Diagnostics: You can set up your own services in Microsoft Azure, but Google Firebase and AWS Amplify can also be considered. There are many solutions available in this area.

CodePush: For the Code Push feature that App Center offers for React Native projects, you can set up the open source project available on GitHub on your own servers.

Large service providers like Microsoft, Google, and AWS can suddenly shut down their services based on their own strategies. This situation can lead to unexpected results, especially for corporations.

Therefore, I recommend that corporate organizations use reasonably priced, paid services to establish long-term agreements.

Isolation as Key: Optimizing Performance in Concurrent Builds on a Single Host

Sophie @Appcircle — Tue, 02 Apr 2024 14:54:54 +0000

Running multiple builds on a single host for mobile application development is a common practice, but it introduces security and efficiency concerns. This article is about the importance of isolation techniques in mitigating these risks effectively.

Definitions:
By leveraging strategies such as containerization and virtual machine (VM) deployment, developers can ensure that each runner operates independently, minimizing conflicts such as managing different Xcode versions, test cases (simulators and emulators), and library dependencies, thus optimizing performance.

Runners are the machines that execute jobs in a CI/CD workflow. For example, a runner can clone your repository locally, install testing software, and then run commands that evaluate your code. Additionally, insights from best practices in managing multiple runners from other development platforms are integrated to provide comprehensive guidance for creating secure and efficient development environments for mobile applications.

Isolation Techniques: Best Practice
To accommodate multiple builds on a single host, developers often deploy replicas of runners with unique names. This approach enables the execution of numerous runners and jobs on a single host. However, to prevent conflicts and ensure smooth operation, it’s imperative to establish sufficient isolation between these runners.
...
Read More

Measuring Mobile DevOps Maturity with DORA Metrics

Sophie @Appcircle — Tue, 26 Mar 2024 16:00:11 +0000

Discover how Appcircle transforms mobile DevOps in our latest article! 🚀
Learn about tailored DORA metrics on Mobile DevOps

Let's redefine Mobile DevOps together!

https://appcircle.io/blog/measuring-mobile-devops-maturity-with-dora-metrics

Update on App Center's Retirement

Sophie @Appcircle — Fri, 22 Mar 2024 13:58:43 +0000

We have an update on App Center's retirement. In our blog, "Navigating the Retirement of AppCenter: Embracing Appcircle as the Ultimate Alternative," we explore the challenges of App Center's retirement and how Appcircle is the ideal replacement.

https://appcircle.io/blog/navigating-the-retirement-of-app-center-embracing-appcircle-as-the-ultimate-alternative

Transforming Kotlin Collections - Functions with Examples

Sophie @Appcircle — Mon, 17 Oct 2022 07:11:36 +0000

This article originaly posted to Appcircle blog and is written by Safa Orhan

Knowing about the standard library functions in Kotlin saves a lot of time while working on complex data structures. Whether you are mapping the API response model into your business model or you are sorting, filtering, and manipulating data; knowing these operation on Kotlin collections come really handy.

In this post, we are gonna go through some collection transformation operations that I use frequently.

Kotlin Collections - Transformation Operations

1. Mapping

Mapping means to modify each item in a collection by applying a transformation lambda which results in the creation of another collection.

If you are working on lists of data that you need to transform from one model into another or if you want to convert the API response model into a domain layer model you should use mapping operations in Kotlin.

.map()

Using the .map() function is the most common way to convert a collection of items into another. It applies the given transform lambda to each of the items of the receiver collection and yields them into a newly created list.

.mapIndexed()

If you also need the index of each item when transforming them, you can use the .mapIndexed() function. It will feed the index of each item to the transform lambda so that you can utilize the order of the items.

.mapNotNull()

Another convenient mapping function is .mapNotNull(). You can use it if you want to filter out null items after the conversion.

For example, if you have a list of objects which may or may not have text property, you can use .mapNotNull() to get a list of texts without any nulls being in it.

Kotlin's standard library also has .mapIndexedNotNull() method which combines .mapIndexed() and .mapNotNull().

Also you can find .mapKeys() and .mapValues() methods which are defined on Maps.

Please check out the official documentation if you need more information on the topic.

2. Zipping

When you have two lists of the same size and you want to merge each item from the first list with the corresponding item coming from the second list you want zipping.

Kotlin standard library has convenient functions to zip and unzip collections including Lists, Arrays, and Sequences.

Let's take a look at what we have:

.zip()

You can use .zip() without any transformation to create a list of pairs. The pairs have their first item from the receiver list and the second from the argument. If you want to combine two different data sources into one and if the sources has the same number of items, the function .zip() is really useful.

.zip() with transform lambda

If you don't need pairs but you want to define your own zipping logic, good news: .zip() can also take a transform lambda as an argument. So you don't need to chain a .zip() command with a .map(). Instead, pass a lambda and combine two items coming from two data sources in a way you would prefer.

.unzip()

Another great function in Kotlin is the .unzip(). The name gives it all away: it does the opposite of .zip(). If you have a list of pairs and want to create two lists that contain the firsts and seconds of each item, then just .unzip() it!

If you want to see some examples please check out the official documentation.

Now let's check out another group of transformation operations:

3. Association

Association is when you want to traverse a List and convert it into a Map by associating each item with one of its properties. Understanding association operations is easier to show than tell, so let's take a look at what sort of functions we have in the standard library:

.associateWith()

The .associateWith() function, structures the items of the List as keys of a Map. The values for each key are computed by running the given lambda on the item. Please note that maps cannot have duplicate keys, so if the receiver collection has repetitive items, only the last one will remain in the map.

.associateBy()

Kotlin also has .associateBy(), which functions almost the same. The difference is items of the receiver collections are not used as keys but values.

That means if the lambda returns the same values for different items, only the last one will be present in the resulting map.

.associate()

The last associating function in the standard library is .associate().

Using this function, you can define the logic of building the map. You need to pass a lambda that returns Pairs and a Map will be built for you using these Pairs.

Please note that this function has some performance implications since it generates Pairs as an intermediate step.

If you want to learn more on association you can take a look at the official documentation.

Now, let's see how we can flatten collections:

4. Flattening

Flattening in general is removing the nestedness in a collection. Consider you are given a list of lists. If you want to remove all child lists and get their elements into one single-level list, you need to flatten that list.

Let's begin with:

.flatten()

This is the most simple way of flattening a list of lists into just list. Just call .flatten() on the receiver collection to have a flat list.

.flatMap()

Or, if you want to apply some kind of transformation whilst flattening, you can use .flatMap().

Please note that .flatMap() is just a shorter form of .map().flatten() chain.

If you want to see some code examples, you may check the official documentation on flattening.

Now let's check out last chapter:

5. String Representation

If you are generating user-visible text out of Kotlin collections or trying to log an internal state you will need to represent collections as strings. I really liked when I learned that Kotlin standard library has a function just for this reason:

.joinToString()

If don't pass any parameters to .joinToString(), string representations of each items will be concatenated in a string and separated by commas with spaces by default.

Customizing the separator, prefix and postfix strings

However, if you need to change the separator strings or add some more useful information to the start or to the end you can pass some arguments for separator, prefix and postfix parameters.

The limit and truncated arguments

.joinToString() also support limiting and truncating the list. If you have a long list and don't want to print everything and make a mess, you can limit how many elements you want in the resulting string and what string to use in the place of an ellipsis.

Finally, it also supports passing a transform lambda if you also want to define how each item will be converted into a string.

You can study the official documentation to learn more about the topic.

That was it! Now you have learned how to transform Kotlin collections using a handful of convenience functions.

If you like the article please share in your social media and if you want to learn more on Kotlin's standard library functions, let us know!

What Is The Alternative To Xcode For Windows For Mobile App Archive, Sign And Simulation?

Sophie @Appcircle — Wed, 08 Sep 2021 16:37:46 +0000

Reading Time: 2 minutes
People frequently ask, “How to download and install Xcode on Windows for iOS development?” or similarly “Xcode on Linux”. The volume of queries to find a working Xcode for Windows has recently been more augmented as people are forced to work from home with no access to their macOS devices.

You can still do iOS development on Windows with code editors in a crude way or by using the cross-platform frameworks, but you would be missing out crucial Xcode features such as iPhone and iPad simulators and archiving and signing iOS applications on Windows.

There are certain technical workarounds to use Xcode for Windows as we mention in other posts, but each has their own complexities regarding building, previewing and distributing mobile applications.

Moreover, you will encounter additional issues if you want to use multiple Xcode versions such as beta or if you are using a cross-platform framework to develop your iOS app, which requires specific dependencies besides Xcode itself, so you would also be looking to seek an alternative to use such dependencies on Windows.

Instead of struggling with all of these issues, you can use Appcircle for an automates and simple mobile CI/CD experience on any environment.

Appcircle is a complete DevOps platform that can replace many of the post-development operations done with Xcode, from app builds to simulators.

What is the Advantage of Appcircle as an Alternative to Xcode for Windows?
You can just connect your git repository without the need for Xcode and Appcircle will handle the full CI/CD processes of your app in your browser, whether you are using Windows or Linux or any other operating system. Appcircle even works on tablets so in a way, you can use Xcode on iPad for app signing and previews.

Get started with Appcircle right away for archiving, signing and submitting iOS apps along with running apps on simulators.

What is Noops And How to Achieve Noops in Mobile App Development?

Sophie @Appcircle — Wed, 08 Sep 2021 16:37:02 +0000

Reading Time: 3 minutes

As enterprises are embracing DevOps and realizing its benefits, especially in their well-established software stacks, they are challenged with another question with the increasing prominence of DevOps in the cloud applications supported with automation.

The question can be expressed as "why don't we fully streamline the DevOps processes even further since it is more or less consist of tasks in a highly structured flow?"

The primary hurdle is the presence of physical hardware that requires maintenance in any case, but moving to the cloud and taking advantage of SaaS (Software as a Service) or PaaS (Platform as a Service) products eliminates this layer of complexity and automated DevOps starts to make more sense.

And this concept actually has a recently coined name of "NoOps", which is gaining foothold in parallel with the cloud adoption.

What is NoOps?

In the simplest way, NoOps can be considered as integrating and automating (wherever possible) DevOps processes. In this sense, it is perceived as an alternative to DevOps or sometimes even as "DevOps" killer, but, it is more like an extension and further streamlining of the DevOps concept.

The term is first identified by Forrester and they emphasize that

"NoOps means that application developers will never have to speak with an operations professional again."

Indeed, when NoOps is implemented and used in the right way and in the right conditions, it is as beneficial and productive as the name suggests.

However, it requires the right tools and preferably a full cloud presence and it should not be considered as a silver bullet for DevOps needs.

With the advantage of the cloud, NoOps eliminates the hassle of integration and upload/download operations.

DevOps vs. NoOps

There are certain fields where you have an established DevOps culture and an "Ops" team, such as maintaining critical backend applications, which may include dealing with locally installed hardware and software.

However, in emerging technologies such as mobility, it is not as easy as to find and maintain internal resources for DevOps or you might not have the operations experience that you have already gained in backend applications for decades.

DevOps in Enterprise Mobility

Due to its nature, mobility has its own DevOps challenges:

Requiring a binary to be installed on mobile devices
Device and operating system fragmentation making coding, testing and distribution processes demanding
Binary distribution regulations to mobile devices
Strict app signing requirements
Issues with keeping signing identities safe, secure and accessible
Complex app signing and submission processes that force the use of specific hardware and software.
Lengthy and complex store submission and review processes causing issues in maintenance of the apps after production

For this reason, we highlight the fact that mobile app development is only the tip of the iceberg and the lifecycle management of mobile apps (the "Ops" part) is as important as the development itself, if not more.

The Typical Mobile App Lifecycle

Switching From DevOps to NoOps in Mobile App Development

Achieving NoOps in mobile app development is more difficult but also more important than many other fields due to the problems outlined in the previous section.

We developed Appcircle for enterprises to embrace the NoOps approach in enterprise mobility. You can consider Appcircle like an automated production line, where everything is transferred automatically between stations.

Appcircle automates DevOps processes to achieve NoOps to

streamline mobile CI/CD
deliver mobile apps faster
increase productivity
automate mobile app releases

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