Why SkeleKit

Let me start by saying: I love C#. From the syntax and quality-of-life features to the whole .NET ecosystem, it is simply the language I feel most comfortable with. When I just started my programming journey, I started building Visual Basic .NET WinForms apps. And let me be clear, they were truly awful. Later, I switched to WPF and C#, then eventually to UWP and WinUI. Over the years, I had more ideas and started more hobby projects, but mobile apps were always the missing part.

What I wanted was pretty simple: a lightweight way to build modern, native-feeling iOS and iPadOS apps using my beloved C#. I am not really an app developer, but I wanted to get into it with the knowledge I already had and at-the-same-time the way Tim Apple intended it.

Existing .NET options

The .NET ecosystem has a bit of a history with mobile UI frameworks: Xamarin.Forms had a reputation for being unstable and was eventually replaced by .NET MAUI. MAUI looks a lot better, but you still hear the same questions: Is it stable? How is the performance? Will Microsoft kill it again? Then there are frameworks such as Avalonia and Uno Platform, which are great for cross-platform Desktop apps, but not so much for mobile.

I did try Xamarin.Forms back in the day and, to be honest, it was fine. The developer experience was decent, and a lot of WPF knowledge carried over. The performance was not amazing, but it was also not a deal-breaker. On Android, the app felt quite at home with Googles Material styling. On iOS, it just did not feel right.

That native feeling matters a lot to me. Cross-platform UI can work very well on desktop, but on my phone I notice controls, spacing, navigation, and interactions that do not behave like iOS. That does not make MAUI, Avalonia, or Uno bad frameworks; they just solve a different problem from the one I had.

I could also pretend this was mainly about performance, but honestly, MAUI probably would have performed well enough for me. It was mostly about the look and feel.

A return to UIKit

Okay, so what was left? SwiftUI, as the modern iOS framework? No, thank you. I tried it, but with every line I wrote, I wanted to go back to my beloved C# and my familiar MVVM patterns.

So UIKit it was. With .NET for iOS (formerly Xamarin.iOS) you can use UIKit directly while keeping C# and the .NET ecosystem. For a few weeks, I really thought: "This is it."

Then I was three views in and had yet another class approaching 600 lines. You really do have to manage everything on your own with UIKit. Creating the controls was not the bad part. Auto Layout was: You have to write and maintain all the constraints yourself. And don't get me starting on collections... Storyboards were not really an option for the larger, code-focused apps either.

So I thought: how hard could it be to build my own UI framework on top of UIKit? It is not like I had to create a pixel-perfect rendering engine or rebuild iOS from scratch. UIKit already did the hard parts. I mainly needed a layout system, wrappers around the controls, an application layer, and some nice C# syntax with QOL features around it.

A familiar programming model

As a long-time WPF and UWP developer (at least for my hobby projects) I wanted something that worked in a familiar way. View trees, bindings, commands, ViewModels: those were the parts I did not want to lose.

Building a whole XAML parser sounded like a very big project, though, so I decided to ditch XAML for now and write the UI directly in the view class. You can do the same in WPF, and with C# object initializers the syntax is actually quite similar. No XAML is fine with me as long as I can keep MVVM.

Deliberate trade-offs

SkeleKit is focused on iOS and iPadOS. Maybe tvOS will follow one day, but that is just an idea for now. It is not supposed to become another framework that runs the same UI everywhere. The entire point is that it is built for Apple platforms and that UIKit is still underneath it.

There is no XAML, the API is still young, and the biggest compromise so far has probably been a few months of my time. That is fine. I would rather keep the framework focused and understandable than turn it into another huge abstraction that tries to support everything.

Who SkeleKit is for

SkeleKit is for other C# developers who feel the same way: people who want to build native-feeling iOS apps, like the structure of WPF or UWP, and do not want to leave the .NET ecosystem just to build a mobile app.

If you need one shared UI across several platforms, MAUI or Avalonia will probably make more sense. If you already enjoy Swift and SwiftUI, there is little reason to add C# in between. SkeleKit is for the oddly specific group in the middle - or, to put it less seriously, for C# developers who are too stubborn to learn SwiftUI and do not like change at all.