🏈 Remastered: RC2

[swiftyfinch]

You can find the previous release here.
Use this command to update Rugby from 2.0.0b2+:

rugby update --beta

Please, check out the 📖 readme, you can find there all information.

Changelog

• 🤹🏻‍♂️ Added support generate_multiple_pod_projects: true
• 🐳 Added support remote cache + #220 (readme)
• 🐛 Fixed issue "Space Characters in Project Path Not Handled" #221

Release Roadmap 🎯

• RC2 (Release candidate)
• RC3?
  • Refactoring
  • Tests
  • CI Pipelines
• Release 🚀
• Open Source

Demo 📺

---

This discussion was created from the release 🏈 Remastered: RC2.

[VaslD]

Hi, @swiftyfinch. If I remember correctly, Development Pods were automatically excluded in Rugby 1.0, right? I just tried this release and found that Development Pods were included in both warmup and build. Is this change planned? And what's the reason behind this change?

Also for auto arch with simulator, would it be a good idea to detect EXCLUDED_ARCHS (optionally with [sdk=iphonesimulator]) build settings and force x86_64 on ARM Macs? Currently -a auto fails on my x86-only project.

[swiftyfinch]

Hi, @swiftyfinch. If I remember correctly, Development Pods were automatically excluded in Rugby 1.0, right? I just tried this release and found that Development Pods were included in both warmup and build. Is this change planned? And what's the reason behind this change?

@VaslD Hello! Yeah, you are right. It's by design. In this version I tried to reduce dependency on CocoaPods. In the Rugby 1x I parsed Podfile.lock and I knew about Development Pods. But in the new Rugby 2.x I parse only xcodeproj format.

I think that if we still need to detect Development Pods, we can add an optional flag for rugby cache command. Now it's a shortcut command and it's OK to improve it in that way. But it's the first time I've received such feedback.

Also for auto arch with simulator, would it be a good idea to detect EXCLUDED_ARCHS (optionally with [sdk=iphonesimulator]) build settings and force x86_64 on ARM Macs? Currently -a auto fails on my x86-only project.

Yeah, I see. We need to understand if it might break something or not. And it can be not so easy to parse EXCLUDED_ARCHS correctly. I really hope that all projects will use only arm64 soon 😀.

Thanks a lot, I will add this feedback to backlog. You can open issues if it's important for you. We can collect reactions from other people from Rugby community.

[VaslD]

Thank you.

I'm half-way OK with Development Pods being built. I threw them all in a cache somewhere anyway, so if some files were dormant they'd get cleaned up eventually. I guess letting end-user decide whether to keep something is somewhat better.

I really hope that all projects will use only arm64 soon 😀.

I do too. Sadly if one Pod didn't ARM I had to downgrade the whole project to x86. Currently either Firebase or Google Maps didn't support ARM simulators, forgot which one. Apple removed Open using Rosetta support in the upcoming Xcode Beta, but I'm afraid as long as Rosetta 2 itself lives, people will find a way. 😭

[VaslD]

I'm wondering is it necessary to treat bundles as separate caches?

I have a Pod that has the following definition:

# …

  spec.source_files = "MyPod/Sources/**/*.swift"
  spec.resource_bundles = {
    "MyBundle" => "MyPod/Resources/*.json",
  }

# …

Rugby generated (and would require during warmup) two caches:

- /Users/vasld/.rugby/bin/MyPod/Debug-iphoneos-arm64/3a7c07a
- /Users/vasld/.rugby/bin/MyBundle/Debug-iphoneos-arm64/c786671

I saw that MyBundle is actually included in MyPod's framework bundle. So logically if MyPod was properly downloaded from remote, I wouldn't need MyBundle to ever be present, even during a normal build.

But if I didn't upload MyBundle, I'd miss 5% of local binaries. 🤣

[swiftyfinch]

I think it's better to keep the resources cache separately. Because resource bundles can be without any changes long time.
So, we can download them and just reuse.

[swiftyfinch]

BTW, thank you for nice question!