Welcome to rules_apple & rules_swift Discussions!

[keith]

👋 Welcome!

Hey everyone! We decided to enable GitHub discussions to provide a place where the community can come together and:

• Ask questions about best practices and how to use the rules
• Share ideas about new features that would be useful for your case
• Engage with other community members.
• Welcome others and provide support as folks ramp up on bazel

I know many folks communicate on the bazel slack and a few other places, but GitHub discussions is a slightly more discoverable and searchable medium for folks who prefer it. It also makes it easy to convert things to issues so we can track things that should be done based on conversations.

To get started, comment below with an introduction of yourself and tell us about your bazel usage!

[keith]

I can start 🙃

I work at Lyft where we moved to bazel in ~2018 for our iOS project, and have moved many other projects include our Android codebase since then. I'm also one of the maintainers of rules_apple / rules_swift

[brentleyjones]

I work at BuildBuddy focusing on Mobile things, mainly iOS. Previously I worked at Lyft and Target on their iOS teams that dealt with Bazel. I'm one of the maintainers of rules_apple / rules_swift, and recently I started rules_xcodeproj.

[tinder-maxwellelliott]

I work at Tinder on iOS Developer Experience and we completed our Bazel migration on November 1st, 2021. You can learn more about our migration to Bazel here

[BalestraPatrick]

Hello! I work at Spotify on mobile developer experience. We're on our way to moving all our mobile code to moving to Bazel and to a single monorepo. Some developers have been building with Bazel parts of our codebases for more than one year now. I recently joined the maintainers of rules_apple/rules_swift and I'm looking forward to submit more contributions over the next few months. We're also interested in collaborating on rules_xcodeproj since getting the IDE experience right has been one of the trickiest parts of our Bazel adoption so far.

[kkpattern]

I work at EVE Echoes, a mobile sci-fi game. We're currently moving to Bazel to build our game on iOS, Android and PC. We're close to finish. And we're happy if we can contributing to Bazel and rule_apple in the future.

[Jacky-LinPeng]

Hi, I'm new to Bazel, and I've discovered that Bazel has a lot of build rules, such as: 'bazelbuild/rules_apple', 'bazelbuild/rules_swift', 'bazel-ios/rules_ios',' line/rules_apple_line ', I plan to convert my ios project to bazel, Which rule is recommended? Are they related? I hope to get your reply about my doubts.

[keith]

Welcome! I definitely understand the confusion. The gist of the situation is that rules_apple and rules_swift are the most core bazel rules for creating apple specific packages, and compiling swift. rules_ios and rules_apple_line are higher level abstractions that improve some various use cases that the core rules don't optimize for. For example rules_ios attempts to make a more Xcode-like structure which potentially helps your migration. Both rules_ios and rules_apple_line directly depend on rules_apple and rules_swift, so no matter what you're getting the core rules, whether you use the other 2 is a question of what level of abstraction is best for your use case.

[Jacky-LinPeng]

Welcome! I definitely understand the confusion. The gist of the situation is that rules_apple and rules_swift are the most core bazel rules for creating apple specific packages, and compiling swift. rules_ios and rules_apple_line are higher level abstractions that improve some various use cases that the core rules don't optimize for. For example rules_ios attempts to make a more Xcode-like structure which potentially helps your migration. Both rules_ios and rules_apple_line directly depend on rules_apple and rules_swift, so no matter what you're getting the core rules, whether you use the other 2 is a question of what level of abstraction is best for your use case.

Please accept my best thanks

[louwers]

Hello I am Bart. I am maintainer for MapLibre Native which is a vector-tile based maps render written in C++ which works on various platforms, most notably iOS and Android. Our primary build tool (generator) is CMake, but Lyft (@nvanfleet) contributed the build files for Bazel, which got the ball rolling. We are now ramping up our Bazel usage especially for the iOS platform, because the CMake build setup for iOS uses a mix of checked in Xcode files and a CMake generated Xcode config, and this is pretty messy, error-prone and makes reviewing changes very hard. Bazel shows a lot of promise to improve this.

Thanks for making the Apple build tool world a little bit nicer to work with. ❤️