Open Source - James Montemagno

Introducing Tiny Clips Studio: Screen Recordings You Can Keep Editing

James Montemagno — Tue, 03 Nov 2026 22:00:00 GMT

You finish recording a demo, play it back, and notice that your camera bubble is sitting right on top of the button you were explaining. Or the recording looks good, but you want to zoom in on one little detail and switch to a different layout halfway through.

Trimming the beginning and end isn't going to fix that!

Today, I'm introducing Tiny Clips Studio (Preview) for macOS and Windows. It adds an editable recording workflow to Tiny Clips, the little menu bar and system tray app for screenshots, videos, and GIFs.

The idea is pretty straightforward: record now, choose the look afterward. Keep your screen and camera separate, arrange them in Studio, and create the final MP4 when you're ready to share. Want a different look later? Reopen the project and change it.

Here is a quick look at Studio in action:

Watch the launch video on GitHub.

A 45-second overview with music and no narration, showing editable screen and camera layers, layouts, zooms, cuts, and export. It combines real editor controls with illustrative compositions; preview capabilities vary by platform.

Download Tiny Clips for macOS and Windows, then enable Settings > Studio > Tiny Clips Studio (Preview).

Let's take a look at what had to change in the recording pipeline, how two native apps agree on a project, and some of the decisions that went into building the editor.

From a recording to a project

The biggest change in Studio happens before you ever touch an editing control.

An ordinary Tiny Clips recording produces a finished video. On Windows, the camera and overlays are drawn into the frames while recording. On macOS, the screen and camera are captured separately, but the normal workflow combines them after recording. Either way, by the time you start trimming, you're working with one flattened picture.

Studio takes a different path. A Studio recording keeps:

The screen recording, without the camera composited on top.
A separate camera recording, when you include your webcam.
Cursor and click timing data, for features such as zoom suggestions.
Project settings, describing the layout, styling, and edits.

Instead of immediately combining everything, Studio opens those pieces in an editor. The final composition is rendered when you export.

That is what makes moving the camera after recording possible. It isn't trying to erase a camera bubble from an existing video. The screen underneath was kept in the first place.

The Studio workflow: keep the ingredients separate, edit the project, and render the video when you're ready to share.

One important distinction: Studio needs those original pieces. It doesn't magically separate the webcam from an older, flattened MP4.

Give the recording a look, then tell the story

You can start with a screen-only layout, add a camera bubble, put the screen and camera side by side, or switch to camera only. Change the background, padding, and rounded corners, then adjust the camera's size, position, and shape.

The real Windows Studio Preview editor, captured in an isolated test host. The color bars and frame markers are synthetic clips used to check composition and timing, not a UI mockup.

For a quick demo, that might be all you need: record, frame it nicely, trim, and export. No need to turn every clip into a production.

But the layout doesn't have to stay the same for the entire video. Scenes let different parts of a recording use different arrangements. For example, you could open with the camera, switch to the screen with a small camera bubble for the walkthrough, and finish side by side. Transitions can be instant or animated.

There are also timeline tools for zooms, cuts, and speed changes. Zoom in on the setting you're explaining, cut out a pause, or speed through a repetitive step. Zooms can focus on a fixed point or follow the pointer when that recording includes pointer data. Click-based suggestions give you a starting point that you can adjust rather than committing you to an automatic edit.

A closer look at the actual timeline: scene layouts, zooms, cuts, and speed changes each have their own lane. Cropped from the test project's editor window.

This is still a preview, and the two platforms aren't identical in every detail. Audio controls, camera background effects, and playback behavior have platform-specific limitations. The Studio development pull request tracks the implementation and known issues; the shared project design isn't a promise that every preview control behaves identically on both systems.

One design, two native implementations

For the developers out there, this is where the project gets interesting.

Studio wasn't built by putting the same web editor inside both apps. The Mac implementation uses Swift and SwiftUI, with AVFoundation and Core Image handling composition and rendering. Windows uses C# and WinUI 3, with Direct3D/Direct2D rendering and Media Foundation for video processing.

Different stacks, but they need to agree on what a project means.

Architecture at a glance. The shared layer is a specification and test data, not a common UI runtime; preview capabilities still vary by platform.

The foundation is a shared project format and rendering specification. Layout positions use normalized coordinates rather than assuming a particular recording resolution. Edits refer to the source recording's timeline, and a time map handles the relationship between that timeline and the exported video after cuts and speed changes.

Why does that matter? Cutting out five seconds shouldn't require rewriting every zoom and scene that comes after it.

The layout resolver takes a project, a time, and a canvas size, then calculates what belongs in that frame. There is a Swift implementation and a C# implementation, checked against the same shared fixtures. The time mapping and zoom-suggestion logic use shared fixtures too.

That gives both implementations concrete examples to agree on, rather than relying on two screenshots that look roughly similar. It doesn't guarantee interchangeable projects or pixel-identical exports, but it makes the common rules testable.

Some of the most useful changes weren't rendering features

The development history starts in early October and includes plenty of work on renderers, exporters, and timelines. It also records the smaller decisions that shape what using Studio actually feels like.

For example, an early version had an "After recording" setting and a separate "Record for Studio" choice. That became one explicit entry point: Studio Recording... on the Mac and a Studio tile on Windows. Ordinary Video stays ordinary Video.

The inspector changed too. Instead of putting eleven sections in one long scroll, Studio uses a rail that opens one panel at a time: Scene, Background, Screen, Camera, Zoom, Cut, Speed, Audio, and Project. Selecting a zoom on the timeline brings up its controls. Dragging the camera opens the Camera panel.

The Camera panel and inspector rail, cropped from the running Windows editor. One set of controls at a time, instead of one long list.

Those aren't flashy export features, but they save you from hunting through a wall of sliders.

Testing also had to go beyond compilation. One Windows inspector issue survived builds and unit tests because the problem only appeared when the actual window was constructed: a referenced UI style didn't exist. Opening and exercising the real window caught what the model tests couldn't.

The work includes shared data tests, rendered-frame checks, export checks, and Windows UI Automation. A build passing and an editor being usable are different questions, and the development notes deliberately distinguish what was compiled, what was checked automatically, and what someone actually tried.

Keep the project, not just the MP4

An export is the video you share. The project is what lets you come back and make another version.

Studio manages projects inside the app, but you can also save a project as a folder containing its recordings and a .tinyclips project file. Opening that file imports a copy as a new draft, leaving the saved folder alone.

Two different things to keep: the MP4 you share and the project folder you can edit again. Pinning a managed project is not the same as saving an independent copy.

There is an important storage trade-off here: keeping editable recordings takes more space than keeping only the finished MP4.

By default, exported projects are eligible for cleanup after 30 days without use, with a 10 GB limit for cleanup-eligible projects. Drafts and projects marked Keep this project are protected from automatic cleanup. Those settings are adjustable.

Keep this project protects against Studio's cleanup; it isn't a backup. In particular, Windows stores its managed projects in the app's data folder, which can be removed when you uninstall or reset the app. Save a project folder somewhere you keep your work if you want to retain it independently of the installation.

And once Studio has cleaned up the source files, the exported MP4 still plays, but those separate editable layers are gone.

Try Studio Preview

Studio Preview is included in the new store releases for macOS and Windows. There is no separate Pro gate for Studio, and it is off by default.

To get started:

Update Tiny Clips. You can find the downloads and store links at tinyclips.app.
Open Settings > Studio.
Turn on Tiny Clips Studio (Preview).
On macOS, choose Studio Recording... from the menu bar menu. On Windows, choose the Studio tile in the tray menu.
Record a short demo, arrange it in Studio, and export an MP4.

If you just want your usual recording workflow, keep using Video. Turning Studio on doesn't turn every video recording into a Studio project, and leaving it off keeps the ordinary workflow unchanged.

Explore the design and source

Want to dig into how it works? Here are a few useful places to start. The implementation links below point to the revision used for this write-up, while the pull request tracks ongoing preview work.

Design and implementation notes: the milestones, product decisions, platform trade-offs, and hands-on testing history.
Project format and layout math: how sources, scenes, zooms, timing, cleanup, and saved project folders fit together.
Native implementations: macOS and Windows: follow the models, editing logic, preview, and rendering code.
Shared test fixtures: concrete project inputs and expected results used to check the common rules.
Studio development and preview status: the development history and known limitations as Studio evolves.

The diagrams are available as editable Excalidraw files too: recording workflow, native architecture, and projects versus exports.

Give Studio a try with a short recording, move the camera somewhere else after you've finished, and export a second version. That is the idea in one little experiment.

If something doesn't work as expected, or you have an idea that would make recording demos better, open an issue in the Tiny Clips repository. I'd love to hear what you create with it.

AsyncCommand & More Come to MVVM Helpers

James Montemagno — Mon, 19 Aug 2019 19:30:00 GMT

Having to write boilerplate code over and over again is not only annoying, but it is a time sink when trying to build apps. That is why nearly 4 years ago I created a small little open source library to get rid of MVVM boilerplate code that I called MVVM Helpers. It contains all sorts of goodies including an ObservableObject, BaseViewModel, ObservableRangeCollection, and all sorts of small utlilities. I use it in every app that I have ever built since its original release and it has been downloaded nearly 500,000 times.

What's Next for MVVM Helpers

The library has been moving along pretty nicely, with small enhancements here and there, but I never really planned for much more. Until Holly tweeted at me last week about using lambas in Commands:

Am I the only one that thinks using this syntax should be punishable by death?

public ICommand MyCommand => new Command(async () => await DoAsync());#XamarinForms
— Holly Schilling (@sgtholly) August 15, 2019

This eventually lead me down a path of reading a great blog by John Thiriet on going async with async command. I immediately thought to my self.... Why isn't this in MVVM Helpers?!?!?!? So this weekend I sat down and combined a bunch of code from John, Xamarin.Forms, and Brandon Minnick's AsyncAwaitBestPractices library, and jammed it into MVVM Helpers.

So, I am pleased to introduce MVVM Helpers version 1.5.0 packed full of all sorts of new goodies for developers!

Enter AsyncCommand

Let's first look at Holly's tweet and the code you would normally write with the build in Xamarin.Forms Command.

public ICommand MyCommand { get; }
public MyViewModel()
{
    MyCommand = new Command(async () => await DoAsync());
}

async Task DoAsync()
{
   // do stuff async
}

The issues here is that the code is a bit gross and also handling exceptions is a bit tricky if something goes wrong. Now with AsyncCommand built into MVVM Helpers the code looks like this:

public ICommand MyCommand { get; }
public MyViewModel()
{
    MyCommand = new AsyncCommand(DoAsync);
}

async Task DoAsync()
{
   // do stuff async
}

The nice part here is that you are still creating an ICommand, which will work great with Xamarin.Forms.

The other thing that you can do is pass in a bunch of other parameters to handle exceptions and also if it can execute or not:

public ICommand MyCommand { get; }
public bool canExecute;
public MyViewModel()
{
    MyCommand = new AsyncCommand(DoAsync,
        (t) =>
        {
            return canExecute;
        },
        (ex) =>
        {
            // Handle exception here
        });
}

async Task DoAsync()
{
    // do stuff async
}

There is also AsyncCommand that can be used if you need to pass in a parameter to the method:

public ICommand MyCommand { get; }
public MyViewModel()
{
    MyCommand = new AsyncCommand<string>(DoAsync);
}

async Task DoAsync(string parameter)
{
    // do stuff async
}

Command and WeakEventManager

Additionally, I decided that sometimes you may want to use a Command in your shared code and not have to bring in Xamarin.Forms. This is why I ripped the code directly out of Xamarin.Forms and put it into MVVM Helpers!

public ICommand MyCommand { get; }
public MyViewModel()
{
    MyCommand = new Command<string>(Do);
}

void Do(string parameter)
{
    // do stuff async
}

Finally, there is a new WeakEventManager also pulled out of Xamarin.Forms that handles raising of EventHandlers. The nice thing about using WeakEventManager is that it will allow for garbage collection when an event handler is still subscribed. I made it public so you can also use it if you are creating EventHandlers in your own project.

readonly WeakEventManager weakEventManager = new WeakEventManager();
public event EventHandler CanExecuteChanged
{
    add { weakEventManager.AddEventHandler(value); }
    remove { weakEventManager.RemoveEventHandler(value); }
}

Available Now

You can grab the library on NuGet right now and of course open an issue or send a PR on GitHub.

See it in action

It is fun to look back to when I first started The Xamarin Show and some of the early episodes I did, including one on MVVM Helpers:

The Beautiful & Complex FlexLayout Comes to Hanselman.Forms

James Montemagno — Fri, 08 Mar 2019 18:22:00 GMT

Last week I wrote about my new quest to fully optimize and enhance Hanselman.Forms. This involves using the latest and greatest in Xamarin.Forms and Xamarin.Essentials, but it also means spicing up the app with some lovely visuals and design. My first quest was to re-design the podcast section of the mobile app to create a list in grid form of different podcast that Hanselman produces.

So, first things first we should design a card to hold each podcast in. This can be accomplished with a simple Frame with a drop shadow on it:


    Padding="0"
    VerticalOptions="Start"
    HasShadow="True">
     Padding="0">
        
             Height="Auto"/>
             Height="Auto"/>
        
         Source="{Binding Art}" Aspect="AspectFill"/>
         Grid.Row="1" Margin="10,0" Text="{Binding Title}"/>

This simple code results in a pretty nice look for album artwork:

I will absolutely want to try out the new Visual Frame/CardView enhancements now that Xamarin.Forms 3.6 is out to make sure it also looks great on iOS.

Wrapping Podcasts

Wrapping the multiple podcasts into columns and rows dymanically would be pretty ideal for something like a CollectionView, but it is still in preview. I thought instead that the the FlexLayout would be a great option because it can arrange its children horizontally and vertically in a stack in addition to wrapping items. Here is one of the samples from the documentation:

Taking this concept I was able to combine the FlexLayout with a BindableLayout to make something pretty spectacular:

 
     BindableLayout.ItemsSource="{Binding Podcasts}"
           Wrap="Wrap"
           Direction="Row"
           JustifyContent="Start"
           AlignItems="Start"
           AlignContent="Start"
           Padding="8">
        
            
                 Margin="4,4,4,4"
                      FlexLayout.Basis="{OnIdiom Phone='50%', Tablet='33%'}"
                      FlexLayout.AlignSelf="Start">

                    />

It tooke me a long time how to figure out how to space each of the cards correctly and wrap to the next line while still starting on the left hand side. This was accomplished by setting all of the Align properties to Start as well as the JustifyContent. It resulted in a really great Android version:

Better yet, when I ran it on UWP or changed the orientation the FlexLayout reacted very nicely:

Seeing this in action I was very content and wrapped up a great week 2 of live streaming updating the app on Twitch.

You can check out the full pull request on GitHub to see how I setup a full mock data source, handled tab transitions, and the final implementation for FlexLayout in the app. Don't forget that I am accepting pull requests and feature requests too on the official GitHub page.

My final take away thoughts are that while the FlexLayout is relatively complicated and has tons of little settings to tweak, it is still extremely powerful and worth dedicating some time to.

Xamarin Evolve + Open Source Save The Date App

James Montemagno — Mon, 24 Aug 2015 17:51:15 GMT

In just under eight months in Orlando, FL thousands of mobile .NET developers will be heading to the next Xamarin Evolve conference. Xamarin Evolve 2014 was one of the most spectacular conferences that I have ever been part of and have ever attended. The most amazing developers came together for five action packed days of training, sessions, hacking, and collaboration. To keep it short, you do NOT want to miss Xamarin Evolve 2016.

I had the joy last year of crafting multiple mobile applications for Evolve including the main conference application and an interactive scavenger hunt based on iBeacons called Evolve Quest.

With Evolve 2014 coming to a close there isn’t much need for the mobile application to hang around on the app stores, which is why I teamed up with Xamarin’s very own Mike James to craft an updated Save the Date application for Evolve. We decided that we wanted something simple but native. It had to be elegant with the latest iOS and Android designed, but still have deep integration into the platforms. The new Save the Date application for Evolve can be installed from both the Apple App Store or Google Play for Android enabling you easily sign up for updates, add Evolve to your calendar, and of course share Evolve with your friends.

Best yet, is that you can see exactly how Mike and I created the application and create your own Save the Date application for your upcoming event. Simply head over to the github repo to download the entire source code and get started today.