u/Candid_Bicycle_2389

If you've ever lost an hour to `pod install` failing on a fresh machine or fighting Ruby version conflicts, good news: Flutter 3.44 makes **Swift Package Manager (SwiftPM)** the default dependency manager for iOS and macOS apps.

No more Ruby. No more CocoaPods setup. SwiftPM ships with Xcode, so it just works out of the box.

Why now?

CocoaPods is officially in maintenance mode and its trunk registry goes permanently read-only on December 2, 2026, meaning no new packages or updates after that date. Flutter is proactively moving to Apple's native, actively-maintained solution before things break.

What changes for you?

New Flutter projects → SwiftPM by default, nothing to do

Existing projects → Flutter CLI auto-migrates your Xcode project on next `flutter run`

Plugin authors → You *must* add a `Package.swift` file if you haven't already (only 61% of top 100 iOS plugins have migrated so far)

What stays the same?

CocoaPods isn't immediately ripped out, you can still opt out and file bug reports if something breaks. But the direction is clear: it's going away. Firebase/FlutterFire already supports SwiftPM. Most major plugins do too. The ecosystem is ready.

Honestly, this is one of the most quality-of-life improvements Flutter has shipped in a while for iOS devs. CI pipelines alone will be so much cleaner.

Has anyone already migrated their plugins to Swift Package Manager? Any gotchas worth knowing?

Google Colab + VS Code Is Live: Free T4 GPU Inside Your Editor, and Most Devs Haven't Noticed Yet

Dropping this here because our community should know about it, and it's flying under the radar.

Google quietly released an official Colab extension for VS Code and the implications are kind of wild for anyone doing local AI development.

https://reddit.com/link/1taqcip/video/doi4a69rrm0h1/player

So what actually changed?

Up until now, if you wanted a proper dev environment, you used VS Code. If you needed GPU compute, you switched to Colab and dealt with its browser-based notebook interface. Two separate worlds. Constant context switching.

That's now gone.

The official Google Colab extension lets VS Code connect directly to a Colab runtime. You write and run code in your editor. The execution happens on Google's servers on a free T4 GPU.

Your local files. Their compute. One environment.

What this looks like in practice:

Before this extension existed, a typical workflow looked something like:

1. Write code in VS Code
2. Manually move it to Colab
3. Realize something's missing, go back to VS Code
4. Session times out
5. Start over

Now it's just... open VS Code, connect to Colab runtime, run your code. That's the whole thing.

Why does this actually matter beyond the convenience?

Here's the part worth discussing:

The GPU access problem in AI development has never really been about the cost alone. It's been about the friction. Enough friction that a lot of beginners gave up before they started, and a lot of indie devs just paid for cloud instances because setting up free alternatives was annoying.

Google just removed a significant chunk of that friction. Free compute + a proper editor + your existing workflow = a genuinely low-barrier entry point for AI development.

This is particularly meaningful for:

• Students who can't afford AWS/GCP credits
• Hobbyists running weekend ML experiments
• Developers in regions where paid cloud compute isn't easily accessible
• Anyone prototyping before deciding whether a project is worth paying for compute

Honest limitations (because hype without caveats helps no one):

• Free tier Colab sessions still have time limits and aren't guaranteed GPU access during peak hours
• Not a replacement for production training runs or large model fine-tuning
• Colab Pro/Pro+ still exists for heavier workloads
• Best suited for experimentation, learning, and smaller model work

The bigger picture

What's interesting isn't just the feature, it's what it signals. Google is clearly trying to make Colab the default compute layer for VS Code users doing AI work. That's a strategic move, and it happens to benefit developers enormously in the short term.

Whether this is the beginning of the end for GPU gatekeeping in hobbyist AI dev genuinely open question. But it's a meaningful step.

The Flutter team dropped Agent Skills for Dart & Flutter today, domain-specific instruction packs you install into your AI agent to close the knowledge gap between LLM training data and the latest Flutter/Dart features.

The core idea: AI agents are generalists, but Flutter development isn't. Skills load progressively, only pulling context when relevant, improving accuracy and reducing token usage.

install command for Flutter's new Agent Skills

Source: https://blog.flutter.dev/introducing-skills-for-dart-and-flutter-23837c6ec0ae

Sounds great. But here's my take:

Claude Code has CLAUDE.md, a file it reads every session with your coding standards, architecture decisions, and preferred libraries. It also builds auto-memory as it works, saving learnings across sessions without you writing anything. You can create custom Skills for repeatable workflows like /review-pr or /deploy-staging.

Flutter's new "Skills" are essentially a CLAUDE.md + custom commands combo with a npx install wrapper and official Flutter branding.

Where Flutter Skills actually win:

• Officially maintained by the Flutter team, when a new Dart feature drops, the Skill updates. Your CLAUDE.md won't.
• They pivoted away from doc-dumping to purely task-oriented Skills. That's a genuinely thoughtful call.
• Agent-agnostic, works with Cursor, Copilot, Claude Code, anything.

Where Claude Code wins outright:

• It maps entire codebases in seconds using agentic search, without you manually selecting context files. Flutter Skills give the agent better instructions. Claude Code gives it eyes.
• It operates at the project level, reads the full codebase, plans across files, runs tests, and iterates on failures. Skills don't do any of that. They're context, not capability.

Hot take: Flutter Skills are fantastic if you're using Copilot or Cursor. They're largely redundant if you're already on Claude Code.

The deeper question, by staying agent-agnostic, are Flutter Skills doomed to always be a lowest-common-denominator solution? The more capable your agent, the less you need pre-packaged Skill files.

Change my mind.

Sharing this from Android Studio because it caught my attention. They've released a new suite of resources aimed at making Android development faster with agents and LLMs, the headline piece being a revamped Android CLI.

The pitch: it's a lightweight, programmatic interface that lets you use any agent or LLM of your choice not locked to one provider. According to their numbers from internal testing, you get:

• 3x faster task speed
• 70%+ less token usage reduction

The token reduction especially stands out, if you're running any kind of agentic workflow on Android, that's a real cost difference. Would be curious to hear from anyone who's tried it or has context on how it compares to what was there before.

Try it out → https://goo.gle/42cUteR

Has anyone here been using agents for Android dev workflows? What's your current setup and is token cost actually a pain point for you?