dotnet / dotnet/xcsync

Current state of xcsync project

Open
#244 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
C#
Stars
25
Forks
10
Avg merge
12h 50m
Merged PRs (30d)
10

Description

Hi folks,

I was about to upgrade my project to .NET 10.0, but since Visual Studio for macOS only supports .NET 8.0, I’ll also need to switch to either VS Code or Rider.

My project is built on net8.0-macos tfm, that is composed from NSWindow/NSWindowsController files, not sure about the terminology but I guess that's not important right now. The project contains around 8 Windows and severals custom controls that can be edited through XCode. Total around 30 objects having RegisterAttribute.

To be able to use VS Code I need to synchronize the XCode with C# project, so I need to use xcsync so I give it a try and I found out that currently it's basically unusable because of several issues I discovered:

- #183 - The xcsync doesn't create .h/.m files for NSObjects that are not in the root namespace. This is critical issue.
- #241 - If I use watch/sync command, it takes around 1 minute to propagate all changes from XCode to C# project, it causes unpossible to use the tool because it is frustrating to wait minutes for applying my changes. In VS for macOS it was immediately instant.
- #242 - The generated XCode project missing necessary imports in .h files if there is a custom control, then during sync/watch command the xcsync strips the component and remove it from the designer file.

Other two issues I didn't create yet:
- If I wire a new component to XCode (through UI to .h file) like WebViewKit, the XCode won't add the import in .h file and the sync fail to generate the Outlet for the WebViewKit in a designer file. This was working in VS for macOS.
- The generated designer files don't respect strong types for actions, the designer file always contains NSObject only instead of the one defined in the .h file such a NSButton, MyControl etc...This was also working in VS for macOS.

I fixed all the issues mentioned above (including the two I haven’t created tickets for yet), though I have to admit I had help from AI, as some parts of this codebase are not easy to catch up on. After fixing all mentioned issues I'm able to built my project after using xcsync generate/sync.

**The question**: What’s the current state of xcsync? From looking at the repo, it kind of feels like it’s dead, and not many people are really using it. The issues I mentioned aren’t some weird edge cases—they seem like pretty common situations in real production work. I haven’t done any iOS or MAUI development, so I’m not really sure what things look like there. So either not many people switch to .NET 10.0 and still using VS for macOS, or there aren't many people developing C# App with XCode sync.
So now I’m wondering if it even makes sense to rely on xcsync (especially since I don’t know if my PR will get approved), or if I should just start moving my project to Avalonia, switch to something else, or maybe give Rider a shot.

Many thanks for any response. I hope @mcumming can shed some light on this question.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.