Alternatives to fastlane logo

Alternatives to fastlane

HockeyApp, Bitrise, Jenkins, Firebase, and CircleCI are the most popular alternatives and competitors to fastlane.
403
290
+ 1
71

What is fastlane and what are its top alternatives?

fastlane lets you define and run your deployment pipelines for different environments. It helps you unify your app’s release process and automate the whole process. fastlane connects all fastlane tools and third party tools, like CocoaPods.
fastlane is a tool in the Mobile Continuous Integration category of a tech stack.
fastlane is an open source tool with 31.4K GitHub stars and 4.8K GitHub forks. Here’s a link to fastlane's open source repository on GitHub

Top Alternatives to fastlane

  • HockeyApp

    HockeyApp

    HockeyApp is the best way to collect live crash reports, get feedback from your users, distribute your betas, and analyze your test coverage. ...

  • Bitrise

    Bitrise

    It is a Continous Integration and Delivery (CI/CD) Platform as a Service (PaaS) with a main focus on mobile app development (iOS, Android). You can automate the testing and deployment of your apps with just a few clicks. When you trigger a build a Virtual Machine is assigned to host your build and your defined Workflow (series of Steps scripts) will be executed, step by step. ...

  • Jenkins

    Jenkins

    In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project. ...

  • Firebase

    Firebase

    Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds. ...

  • CircleCI

    CircleCI

    Continuous integration and delivery platform helps software teams rapidly release code with confidence by automating the build, test, and deploy process. Offers a modern software development platform that lets teams ramp. ...

  • TestFlight

    TestFlight

    With TestFlight, developers simply upload a build, and the testers can install it directly from their device, over the air. ...

  • Buddybuild

    Buddybuild

    Buddybuild ties together continuous integration, continuous delivery and an iterative feedback solution into a single, seamless platform. ...

  • Greenhouse

    Greenhouse

    Greenhouse automatically builds your project for every commit you make and runs all your unit or UI tests on the emulator/simulator or on real hardware. Automatic build distribution is also supported so that your team and clients are always up to date with the latest state of your apps. ...

fastlane alternatives & related posts

HockeyApp logo

HockeyApp

168
131
38
Manage your betas and collect live crash reports for iOS, Android, Windows Phone, and OS X apps.
168
131
+ 1
38
PROS OF HOCKEYAPP
  • 17
    Crash analytics
  • 11
    Cross-platform
  • 5
    Mobile application distribution
  • 2
    JIRA Integration
  • 2
    Open source
  • 1
    GitHub Integration
CONS OF HOCKEYAPP
    Be the first to leave a con

    related HockeyApp posts

    Bitrise logo

    Bitrise

    255
    248
    58
    Automate your mobile app development from building through testing to deployment
    255
    248
    + 1
    58
    PROS OF BITRISE
    • 17
      Easy setup
    • 8
      Bitbucket Integration
    • 7
      Advanced Workflow configuration
    • 6
      Slack integration
    • 5
      Github Integration
    • 4
      Friendly & Easy to use
    • 3
      Great support
    • 3
      Great tools for iOS and Android development
    • 2
      Pricing by concurrency, not team size
    • 1
      Fast Updates
    • 1
      Discounts for contributors
    • 1
      Open Source
    CONS OF BITRISE
      Be the first to leave a con

      related Bitrise posts

      Jesus Dario Rivera Rubio
      Telecomm Engineering at Netbeast · | 10 upvotes · 817.3K views

      We are using React Native in #SmartHome to share the business logic between Android and iOS team and approach users with a unique brand experience. The drawback is that we require lots of native Android SDK and Objective-C modules, so a good part of the invested time is there. The gain for a app that relies less on native communication, sensors and OS tools should be even higher.

      Also it helps us set different testing stages: we use Travis CI for the javascript (business logic), Bitrise to run build tests and @Detox for #end2end automated user tests.

      We use a microservices structure on top of Zeit's @now that read from firebase. We use JWT auth to authenticate requests among services and from users, following GitHub philosophy of using the same infrastructure than its API consumers. Firebase is used mainly as a key-value store between services and as a backup database for users. We also use its authentication mechanisms.

      You can be super locked-in if you also rely on it's analytics, but we use Amplitude for that, which offers us great insights. Intercom for communications with end-user and Mailjet for marketing.

      See more
      Jenkins logo

      Jenkins

      36.1K
      28.8K
      2.2K
      An extendable open source continuous integration server
      36.1K
      28.8K
      + 1
      2.2K
      PROS OF JENKINS
      • 520
        Hosted internally
      • 463
        Free open source
      • 313
        Great to build, deploy or launch anything async
      • 243
        Tons of integrations
      • 208
        Rich set of plugins with good documentation
      • 108
        Has support for build pipelines
      • 71
        Open source and tons of integrations
      • 63
        Easy setup
      • 61
        It is open-source
      • 54
        Workflow plugin
      • 11
        Configuration as code
      • 10
        Very powerful tool
      • 9
        Many Plugins
      • 8
        Git and Maven integration is better
      • 8
        Great flexibility
      • 6
        Continuous Integration
      • 6
        Slack Integration (plugin)
      • 6
        Github integration
      • 5
        Easy customisation
      • 5
        Self-hosted GitLab Integration (plugin)
      • 4
        100% free and open source
      • 4
        Docker support
      • 3
        Excellent docker integration
      • 3
        Fast builds
      • 3
        Platform idnependency
      • 2
        Pipeline API
      • 2
        Customizable
      • 2
        Can be run as a Docker container
      • 2
        It`w worked
      • 2
        Hosted Externally
      • 2
        AWS Integration
      • 2
        JOBDSL
      • 2
        It's Everywhere
      • 1
        NodeJS Support
      • 1
        PHP Support
      • 1
        Ruby/Rails Support
      • 1
        Universal controller
      • 1
        Easily extendable with seamless integration
      • 1
        Build PR Branch Only
      CONS OF JENKINS
      • 12
        Workarounds needed for basic requirements
      • 7
        Groovy with cumbersome syntax
      • 6
        Plugins compatibility issues
      • 6
        Limited abilities with declarative pipelines
      • 5
        Lack of support
      • 4
        No YAML syntax
      • 2
        Too tied to plugins versions

      related Jenkins posts

      Thierry Schellenbach

      Releasing new versions of our services is done by Travis CI. Travis first runs our test suite. Once it passes, it publishes a new release binary to GitHub.

      Common tasks such as installing dependencies for the Go project, or building a binary are automated using plain old Makefiles. (We know, crazy old school, right?) Our binaries are compressed using UPX.

      Travis has come a long way over the past years. I used to prefer Jenkins in some cases since it was easier to debug broken builds. With the addition of the aptly named “debug build” button, Travis is now the clear winner. It’s easy to use and free for open source, with no need to maintain anything.

      #ContinuousIntegration #CodeCollaborationVersionControl

      See more
      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 21 upvotes · 4M views

      Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

      It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

      I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

      We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

      If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

      The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

      Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

      See more
      Firebase logo

      Firebase

      22.5K
      18.5K
      1.9K
      The Realtime App Platform
      22.5K
      18.5K
      + 1
      1.9K
      PROS OF FIREBASE
      • 357
        Realtime backend made easy
      • 261
        Fast and responsive
      • 233
        Easy setup
      • 206
        Real-time
      • 184
        JSON
      • 126
        Free
      • 120
        Backed by google
      • 80
        Angular adaptor
      • 62
        Reliable
      • 36
        Great customer support
      • 25
        Great documentation
      • 22
        Real-time synchronization
      • 19
        Mobile friendly
      • 17
        Rapid prototyping
      • 12
        Great security
      • 10
        Automatic scaling
      • 9
        Freakingly awesome
      • 8
        Chat
      • 8
        Super fast development
      • 8
        Angularfire is an amazing addition!
      • 6
        Awesome next-gen backend
      • 6
        Ios adaptor
      • 5
        Firebase hosting
      • 5
        Built in user auth/oauth
      • 4
        Very easy to use
      • 3
        Brilliant for startups
      • 3
        It's made development super fast
      • 3
        Great
      • 2
        Low battery consumption
      • 2
        The concurrent updates create a great experience
      • 2
        I can quickly create static web apps with no backend
      • 2
        Great all-round functionality
      • 2
        Speed of light
      • 1
        Easy to use
      • 1
        Good Free Limits
      • 1
        .net
      • 1
        Serverless
      • 1
        Large
      • 1
        JS Offline and Sync suport
      • 1
        Easy Reactjs integration
      • 1
        Faster workflow
      • 1
        Push notification
      CONS OF FIREBASE
      • 25
        Can become expensive
      • 14
        No open source, you depend on external company
      • 14
        Scalability is not infinite
      • 9
        Not Flexible Enough
      • 5
        Cant filter queries
      • 3
        Very unstable server
      • 2
        Too many errors
      • 2
        No Relational Data

      related Firebase posts

      Tassanai Singprom

      This is my stack in Application & Data

      JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB

      My Utilities Tools

      Google Analytics Postman Elasticsearch

      My Devops Tools

      Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack

      My Business Tools

      Slack

      See more

      We are starting to work on a web-based platform aiming to connect artists (clients) and professional freelancers (service providers). In-app, timeline-based, real-time communication between users (& storing it), file transfers, and push notifications are essential core features. We are considering using Node.js, ExpressJS, React, MongoDB stack with Socket.IO & Apollo, or maybe using Real-Time Database and functionalities of Firebase.

      See more
      CircleCI logo

      CircleCI

      7.7K
      4.6K
      956
      Automate your development process quickly, safely, and at scale
      7.7K
      4.6K
      + 1
      956
      PROS OF CIRCLECI
      • 223
        Github integration
      • 175
        Easy setup
      • 151
        Fast builds
      • 94
        Competitively priced
      • 72
        Slack integration
      • 54
        Docker support
      • 44
        Awesome UI
      • 33
        Great customer support
      • 18
        Ios support
      • 14
        Hipchat integration
      • 12
        SSH debug access
      • 11
        Free for Open Source
      • 5
        Bitbucket integration
      • 5
        Mobile support
      • 4
        AWS CodeDeploy integration
      • 4
        Nodejs support
      • 3
        Great support
      • 3
        YAML configuration
      • 3
        Free for Github private repo
      • 2
        Clojure
      • 2
        Simple, clean UI
      • 2
        Clojurescript
      • 2
        OSX support
      • 2
        Continuous Deployment
      • 1
        Android support
      • 1
        Autoscaling
      • 1
        Fair pricing
      • 1
        All inclusive testing
      • 1
        Helpful documentation
      • 1
        Japanese in rspec comment appears OK
      • 1
        Favorite
      • 1
        Build PR Branch Only
      • 1
        Really easy to use
      • 1
        Unstable
      • 1
        So circular
      • 1
        Easy setup, easy to understand, fast and reliable
      • 1
        Parallel builds for slow test suites
      • 1
        Easy setup. 2.0 is fast!
      • 1
        Parallelism
      • 1
        Extremely configurable
      • 1
        Easy to deploy to private servers
      • 1
        Works
      CONS OF CIRCLECI
      • 9
        Unstable
      • 6
        Scammy pricing structure
      • 0
        Aggressive Github permissions

      related CircleCI posts

      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 21 upvotes · 4M views

      Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

      It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

      I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

      We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

      If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

      The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

      Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

      See more
      Tim Abbott
      Shared insights
      on
      Travis CITravis CICircleCICircleCI
      at

      We actually started out on Travis CI, but we've migrated our main builds to CircleCI, and it's been a huge improvement.

      The reason it's been a huge improvement is that Travis CI has a fundamentally bad design for their images, where they start with a standard base Linux image containing tons of packages (several versions of postgres, every programming language environment, etc). This is potentially nice for the "get builds for a small project running quickly" use case, but it's a total disaster for a larger project that needs a decent number of dependencies and cares about the performance and reliability of their build.

      This issue is exacerbated by their networking infrastructure being unreliable; we usually saw over 1% of builds failing due to transient networking errors in Travis CI, even after we added retries to the most frequently failing operations like apt update or pip install. And they never install Ubuntu's point release updates to their images. So doing an apt update, apt install, or especially apt upgrade would take forever. We ended up writing code to actually uninstall many of their base packages and pin the versions of hundreds of others to get a semi-fast, semi-reliable build. It was infuriating.

      The CircleCI v2.0 system has the right design for a CI system: we can customize the base image to start with any expensive-to-install packages we need for our build, and we can update that image if and when we want to. The end result is that when migrating, we were able to delete all the hacky optimizations mentioned above, while still ending up with a 50% faster build latency. And we've also had 5-10x fewer issues with networking-related flakes, which means one doesn't have to constantly check whether a build failure is actually due to an issue with the code under test or "just another networking flake".

      See more
      TestFlight logo

      TestFlight

      1.1K
      639
      162
      iOS beta testing on the fly.
      1.1K
      639
      + 1
      162
      PROS OF TESTFLIGHT
      • 62
        Must have for ios development
      • 49
        Beta testing
      • 19
        Easy setup
      • 10
        Easy way to push out updates for internal testers
      • 7
        In-App Updates
      • 5
        Crash Logging
      • 4
        Checkpoints
      • 3
        Multiple platforms
      • 2
        Remote Logging
      • 1
        Sessions
      CONS OF TESTFLIGHT
        Be the first to leave a con

        related TestFlight posts

        Buddybuild logo

        Buddybuild

        44
        52
        41
        A continuous integration, continuous deployment and user feedback platform for iOS and Android development teams
        44
        52
        + 1
        41
        PROS OF BUDDYBUILD
        • 12
          Easy setup
        • 8
          Beta testing
        • 8
          Crazy easy
        • 7
          GitHub Integration
        • 3
          Crash reporting
        • 2
          Cause it's just great
        • 1
          Good support team
        CONS OF BUDDYBUILD
          Be the first to leave a con

          related Buddybuild posts

          Greenhouse logo

          Greenhouse

          36
          42
          35
          Simple and secure continuous integration for mobile apps
          36
          42
          + 1
          35
          PROS OF GREENHOUSE
          • 13
            Easy setup & usage
          • 6
            Free
          • 6
            Great customer support
          • 5
            Awesome team with awesome project
          • 3
            Great and fast builds
          • 1
            A lot easier than Jenkins
          • 1
            Doesn't have an issue with Android emulators
          CONS OF GREENHOUSE
            Be the first to leave a con

            related Greenhouse posts