Microsoft acquired the Australia-based Clipchamp video editor for an undisclosed amount in September 2021 and began bundling it with Microsoft 365. Until now, it never appeared that Clipchamp is on the back burner, but I’m now having second thoughts. Microsoft has quietly confirmed it’s retiring Clipchamp for iOS and wants you to use the desktop app.

If you open Clipchamp on iOS, you’ll see an alert that the iOS app is being discontinued and that you need to take action before your projects are lost.

But why is the Clipchamp iOS app being retired? According to Microsoft, most users prefer to edit videos on their desktops using Clipchamp, so it makes sense to focus only on Windows 11 and web versions.

That means Clipchamp for iOS will eventually stop working, and the official retirement date is June 6, 2026. It also means Clipchamp for Android will never happen.

“We have found that most users prefer editing their video projects on our web and desktop applications. In order to deliver high-value features and improvements, we are focusing our efforts on these applications to benefit users,” Microsoft noted in a support document spotted by Windows Latest.

“After 10/06/2026, the Clipchamp iOS app is going away. Take action before then to ensure your projects are not lost,” the company warns. “To ensure your video projects are not deleted when the Clipchamp iOS app goes away, export your video projects and save the videos to your mobile device before 06/09/2026.”

Clipchamp for iOS has 4.8 ratings in the United States’ App Store, and it’s actually really liked by consumers, who, according to Microsoft, don’t really use the app on mobile.

Microsoft also confirmed that it’ll delete your video projects on mobile devices if you don’t export your edits or sync everything to OneDrive.

What to do if you use Clipchamp on iOS?

Microsoft told me that you should export all your videos to MP4 on your phone before June 9, 2026.

In case you pay for Microsoft 365, which includes access to Clipchamp Premium, you’ll still need to move away from the iOS app and simply sync everything to OneDrive.

Clipchamp for iOS might continue to work after June 9, 2026, but Microsoft told Windows Latest that it will automatically stop connecting on iOS. In fact, Microsoft says you should just delete the video editor app and consider using Windows 11’s Clipchamp or just open clipchamp.com in any browser.

I asked Microsoft if Clipchamp is on the back burner, but I’m told that’s not the case, as Windows 11’s video editor and web-based Clipchamp will remain fully supported.

“The Clipchamp web and desktop applications will remain fully functional. There are no changes to these applications,” the company said.

More recently, Clipchamp on Windows 11 made it difficult for users to export their videos without syncing to OneDrive, but the app is still getting new features.

The post Microsoft retires Clipchamp’s iOS app, says Windows 11’s built-in video editor is here to stay appeared first on Windows Latest

Bug Fixes

• 14be92b fix: model generator yield resumption paths in code path analysis (#20665) (sethamus)
• 84a19d2 fix: no-async-promise-executor false positives for shadowed Promise (#20740) (xbinaryx)
• af764af fix: clarify language and processor validation errors (#20729) (Pixel998)
• e251b89 fix: update eslint (#20715) (renovate[bot])

Documentation

• ca92ca0 docs: reuse markdown-it instance for markdown filter (#20768) (Amaresh S M)
• 57d2ee2 docs: Enable Eleventy incremental mode for watch (#20767) (Amaresh S M)
• c1621b9 docs: fix typos in code-path-analyzer.js (#20700) (Ayush Shukla)
• 1418d52 docs: Update README (GitHub Actions Bot)
• 39771e6 docs: Update README (GitHub Actions Bot)
• 71e0469 docs: fix incomplete JSDoc param description in no-shadow rule (#20728) (kuldeep kumar)
• 22119ce docs: clarify scope of for-direction rule with dead code examples (#20723) (Amaresh S M)
• 8f3fb77 docs: document meta.docs.dialects (#20718) (Pixel998)

Chores

• 7ddfea9 chore: update dependency prettier to v3.8.2 (#20770) (renovate[bot])
• fac40e1 ci: bump pnpm/action-setup from 5.0.0 to 6.0.0 (#20763) (dependabot[bot])
• 7246f92 test: add tests for SuppressionsService.load() error handling (#20734) (kuldeep kumar)
• 4f34b1e chore: update pnpm/action-setup action to v5 (#20762) (renovate[bot])
• 51080eb test: processor service (#20731) (kuldeep kumar)
• e7e1889 chore: remove stale babel-eslint10 fixture and test (#20727) (kuldeep kumar)
• 4e1a87c test: remove redundant async/await in flat config array tests (#20722) (Pixel998)
• 066eabb test: add rule metadata coverage for languages and docs.dialects (#20717) (Pixel998)

I'll be honest. I resisted primary constructors for a while.

When C# 12 extended them from record types to regular classes and structs, my first reaction was skepticism. An implicit mutable capture instead of explicit readonly fields? That felt like trading safety for convenience.

But after using them across several projects, I changed my mind. The boilerplate they eliminate in DI service classes is significant, and the pitfall I was worried about is manageable once you know about it.

Here's what convinced me to switch, and the one thing you need to watch out for.

What Changed My Mind

Here's what my service classes used to look like:

public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly ILogger<OrderService> _logger;

    public OrderService(
        IOrderRepository orderRepository,
        ILogger<OrderService> logger)
    {
        _orderRepository = orderRepository;
        _logger = logger;
    }

    public async Task<Order?> GetOrderAsync(Guid id)
    {
        _logger.LogInformation("Fetching order {OrderId}", id);

        return await _orderRepository.GetByIdAsync(id);
    }
}

And here's what they look like now:

public class OrderService(
    IOrderRepository orderRepository,
    ILogger<OrderService> logger)
{
    public async Task<Order?> GetOrderAsync(Guid id)
    {
        logger.LogInformation("Fetching order {OrderId}", id);

        return await orderRepository.GetByIdAsync(id);
    }
}

The field declarations, the constructor body, the assignments. All gone. The parameters are captured and available throughout the class body.

This is the most common use case for primary constructors: dependency injection in service classes. You declare what you need, and use it directly.

Where I Use Them Most: DI Service Classes

The place where primary constructors sold me is ASP.NET Core service classes. This is where I spend most of my time, and the boilerplate savings add up fast.

Here's a more realistic example from a checkout flow:

public class CheckoutService(
    IPaymentProcessor paymentProcessor,
    IOrderRepository orderRepository,
    ILogger<CheckoutService> logger,
    IOptions<CheckoutOptions> options)
{
    public async Task<CheckoutResult> ProcessAsync(
        Cart cart,
        CancellationToken ct = default)
    {
        var settings = options.Value;

        if (cart.Total < settings.MinimumOrderAmount)
        {
            logger.LogWarning("Order below minimum: {Total}", cart.Total);
            return CheckoutResult.BelowMinimum;
        }

        var order = Order.Create(cart);

        await paymentProcessor.ChargeAsync(order, ct);
        await orderRepository.SaveAsync(order, ct);

        logger.LogInformation("Checkout complete for order {OrderId}", order.Id);

        return CheckoutResult.Success;
    }
}

Four dependencies, zero boilerplate. The class reads top-to-bottom without any noise.

This pattern works well because service classes typically don't need to validate or transform their dependencies. The DI container provides them, and you use them. Primary constructors are a perfect fit for this.

Entity Construction (With a Caveat)

I also started using primary constructors for domain entities and value objects where you want to enforce required parameters at construction time:

public class Order(Guid customerId, Money total)
{
    public Guid Id { get; } = Guid.NewGuid();
    public Guid CustomerId { get; } = customerId;
    public Money Total { get; } = total;
    public OrderStatus Status { get; private set; } = OrderStatus.Pending;
    public DateTime CreatedAt { get; } = DateTime.UtcNow;

    public void Confirm()
    {
        if (Status != OrderStatus.Pending)
        {
            throw new InvalidOperationException(
                $"Cannot confirm order in {Status} status.");
        }

        Status = OrderStatus.Confirmed;
    }
}

There's no way to create an Order without a customerId and total. The primary constructor makes this constraint visible at the type declaration level.

Notice the key difference from the service class pattern: here, I'm assigning primary constructor parameters to properties with initializers (= customerId). This is important, and it leads to the biggest pitfall.

The Pitfall That Almost Stopped Me

This was the reason I held off for so long.

Primary constructor parameters are not readonly fields.

When you use a primary constructor parameter directly in the class body (like we did in the service class), the compiler captures it as a mutable variable. There's no readonly backing field generated behind the scenes.

This means you can accidentally reassign a parameter:

public class OrderService(
    IOrderRepository orderRepository,
    ILogger<OrderService> logger)
{
    public async Task<Order?> GetOrderAsync(Guid id)
    {
        logger.LogInformation("Fetching order {OrderId}", id);

        return await orderRepository.GetByIdAsync(id);
    }

    public void SomeOtherMethod()
    {
        // This compiles. No warning. No error.
        orderRepository = null!;
        logger = null!;
    }
}

This compiles without any warning.

With a traditional constructor and private readonly fields, the compiler would stop you immediately. With primary constructors, it stays silent.

If you need immutability guarantees, explicitly assign the parameter to a readonly field:

public class OrderService(
    IOrderRepository orderRepository,
    ILogger<OrderService> logger)
{
    private readonly IOrderRepository _orderRepository = orderRepository;
    private readonly ILogger<OrderService> _logger = logger;

    public async Task<Order?> GetOrderAsync(Guid id)
    {
        _logger.LogInformation("Fetching order {OrderId}", id);

        return await _orderRepository.GetByIdAsync(id);
    }
}

But now you've lost most of the benefit of primary constructors. You're back to field declarations and assignments, just with a different syntax.

In practice, I've never actually hit this bug in a DI service class. You're unlikely to accidentally reassign logger in the middle of a method. But it can bite you in entity classes or value types where immutability actually matters. That's the one place where I still stay cautious.

Where I Still Use Traditional Constructors

I haven't switched everything over. Here are the cases where I stick with the traditional approach:

Complex validation logic. If you need to validate parameters before assigning them, you need a constructor body:

public class EmailAddress
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (string.IsNullOrWhiteSpace(value) || !value.Contains('@'))
        {
            throw new ArgumentException(
                "Invalid email address.", nameof(value));
        }

        _value = value;
    }
}

Primary constructors don't give you a place to put validation logic before the class body runs.

Multiple constructor overloads. Primary constructors support one constructor signature. If you need overloads, you'll have to chain secondary constructors with this(...), which gets messy fast.

Too many parameters. Once you hit 5+ dependencies, the primary constructor line becomes hard to read. At that point, your class probably has too many responsibilities, and refactoring it is a better solution than formatting tricks.

Summary

Here's what I've settled on after using primary constructors across several projects:

• I use primary constructors for all my DI service classes. The boilerplate savings are worth it.
• They're useful for entity construction when you want to enforce required parameters at the type level.
• Primary constructor parameters are captured as mutable variables, not readonly fields. This is the one thing you need to know.
• I'm not afraid of the mutable capture pitfall in service classes, because it's unlikely to cause real bugs in that context.
• I stick with traditional constructors for validation-heavy types, multiple overloads, or classes with too many dependencies

The switch was worth it. My service classes are shorter, easier to scan, and the pitfall is manageable with the right tooling.

That's all for today. See you next week.

Heading to Las Vegas tomorrow for the prep ahead of Google Cloud Next 2026. Today was all about clearing out my queue of work beforehand. I also updated my bio here to reflect a change in my job.

[article] Salesforce launches Headless 360 to turn its entire platform into infrastructure for AI agents. The first move from most SaaS vendors was to offer their own agents and agent platforms. Build gravity. The second play is to ensure their platforms can play in any agent ecosystem.

[blog] A new way to explore the web with AI Mode in Chrome. People seem to like this change, judging from posts and comments I saw online.

[article] Canva won’t make you use its new AI. Nice. AI should be one way you interact with a product. Not the ONLY available way.

[blog] A year of open collaboration: Celebrating the anniversary of A2A. This community accomplished a LOT in the past year. The protocol itself improved, vendors adopted it, and agent frameworks supported it.

[blog] Build to Learn vs Build to Earn. Whether you’re a product manager or not, know when you’re doing discovery and learning, and when you’re actually building the real product.

[blog] A2UI v0.9: The New Standard for Portable, Framework-Agnostic Generative UI. I’m going to spend more time with this. It’s gotten much easier to empower agents to create UIs.

[article] How does codebase familiarity shape collaboration with coding agents? I didn’t find this research surprising. Core maintainers are more diligent on the codebase than casual contributors who offload more work to AI agents.

[blog] Bringing AI Closer to the Edge and On-Device with Gemma 4. Post from NVIDIA with all sorts of details about this open model and how to run it.

[article] Why AI readiness training fails. I think we all know that any training that isn’t applied within two weeks is forgotten. Can we rethink how we’re upskilling people with AI.

[blog] Streaming Gemini 3.1’s expressive new TTS model in Java. Sweet example of this frankly amazing text-to-speech update for Gemini.

[article] Sleep Deprived. I don’t think more of people who brag about not sleeping. That seems like a dumb decision. I’ll be tested next week in Vegas, but still plan to prioritize rest.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below: