You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 28, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on May 28, 2025. It is now read-only.
Bring WinObjC to WSLg, either exclusive to CUDA and DX12, or for all Linux with Vulkan. #2948
Is your feature request related to a problem? Please describe.
I don't like that you can't run any apps on both Unix-like, Windows and Mac.
Describe the solution you'd like
If WinObjC was supported in WSLg, this could mean WinObjC finally has a unix environment and makes tolerantly written Mac apps run on Windows via Linux.
Describe alternatives you've considered
Darwin based solutions are underdeveloped and not Linux, however there is Swift toolchains for Windows and Linux, which could be handy for this project.
Additional context
This is also for developers who want to run XCode to create mac apps on Windows/Linux.
Swift toolchain is an idea, but this repository is named "WinObjC" mean this focus to Obj-C, may be create something is named "WinSwift" better idea.
I like your idea: develop iOS or Mac apps on Windows/Linux without buy Mac. It will save us a lot of money buy Mac
But I don't think this idea will become true:
Microsoft isn't interest port this project to other platform because this will require a lot of resource. In business aspect, this is app gap solution for MS store with App store, and Dustin (this project maintainer) was moved to PowerToys project, so mostly it was became abandoned project. In technical aspect, many of components are base on C++/CX standard so it can't run on other platform, this will need a lot of code to convert C++/CX to modern C++ (14/17/20/...) to run on them.
Apple doesn't care about create a IDE for Windows/Linux develop iOS and Mac app, because they will sell more Mac devices. However, a statement from Apple in 2010 says they relaxed some of the App Store review guidelines to allow any tool to be used, as long as the resulting binary does not download any code, which means it should be OK to use the cross-compiling the binary. So that mean, you can try is Darling, it will help you run Mac app on Windows via WSL and follow tutorial install XCode on it. Other solution is OSXCross it will help you cross-compile Mac app via WSL.
I am also looking a tool for Metal framework (Apple property graphic API) on Visual Studio (since VS is standard industry for game development) but Metal API is only API not work on VS. May be or I never will find a project help me about that. So I think: fork this project and create my own tool is better solution. Some famous project base on this repository is ipasim (iOS app simulator on Windows) is a great example for create own tool.
Swift toolchain is an idea, but this repository is named "WinObjC" mean this focus to Obj-C, may be create something is named "WinSwift" better idea.
I like your idea: develop iOS or Mac apps on Windows/Linux without buy Mac. It will save us a lot of money buy Mac
But I don't think this idea will become true:
Microsoft isn't interest port this project to other platform because this will require a lot of resource. In business aspect, this is app gap solution for MS store with App store, and Dustin (this project maintainer) was moved to PowerToys project, so mostly it was became abandoned project. In technical aspect, many of components are base on C++/CX standard so it can't run on other platform, this will need a lot of code to convert C++/CX to modern C++ (14/17/20/...) to run on them.
Apple doesn't care about create a IDE for Windows/Linux develop iOS and Mac app, because they will sell more Mac devices. However, a statement from Apple in 2010 says they relaxed some of the App Store review guidelines to allow any tool to be used, as long as the resulting binary does not download any code, which means it should be OK to use the cross-compiling the binary. So that mean, you can try is Darling, it will help you run Mac app on Windows via WSL and follow tutorial install XCode on it. Other solution is OSXCross it will help you cross-compile Mac app via WSL.
I am also looking a tool for Metal framework (Apple property graphic API) on Visual Studio (since VS is standard industry for game development) but Metal API is only API not work on VS. May be or I never will find a project help me about that. So I think: fork this project and create my own tool is better solution. Some famous project base on this repository is ipasim (iOS app simulator on Windows) is a great example for create own tool.
WinObjC's focus was the problem, they wanted it to be a base for developing UWP apps via the iOS app source code, but there had to be many changes, and for example some UI element was originally supposed to emulate the iOS equivalent but then it was changed to UWP equivelent. WinObjC should be a way to 1:1 make a recreation of iOS libraries, and something like ipasim should be part of the project. WinObjC should make Windows "iOS compatible", one codebase, both iOS, iPadOS, macOS, and Windows can be developed for and published on both the App Store and Microsoft Store.
Activity
VOM7HC commentedon Oct 8, 2021
Swift toolchain is an idea, but this repository is named "WinObjC" mean this focus to Obj-C, may be create something is named "WinSwift" better idea.
I like your idea: develop iOS or Mac apps on Windows/Linux without buy Mac. It will save us a lot of money buy Mac
But I don't think this idea will become true:
Microsoft isn't interest port this project to other platform because this will require a lot of resource. In business aspect, this is app gap solution for MS store with App store, and Dustin (this project maintainer) was moved to PowerToys project, so mostly it was became abandoned project. In technical aspect, many of components are base on C++/CX standard so it can't run on other platform, this will need a lot of code to convert C++/CX to modern C++ (14/17/20/...) to run on them.
Apple doesn't care about create a IDE for Windows/Linux develop iOS and Mac app, because they will sell more Mac devices. However, a statement from Apple in 2010 says they relaxed some of the App Store review guidelines to allow any tool to be used, as long as the resulting binary does not download any code, which means it should be OK to use the cross-compiling the binary. So that mean, you can try is Darling, it will help you run Mac app on Windows via WSL and follow tutorial install XCode on it. Other solution is OSXCross it will help you cross-compile Mac app via WSL.
I am also looking a tool for Metal framework (Apple property graphic API) on Visual Studio (since VS is standard industry for game development) but Metal API is only API not work on VS. May be or I never will find a project help me about that. So I think: fork this project and create my own tool is better solution. Some famous project base on this repository is ipasim (iOS app simulator on Windows) is a great example for create own tool.
upintheairsheep commentedon Nov 9, 2024
WinObjC's focus was the problem, they wanted it to be a base for developing UWP apps via the iOS app source code, but there had to be many changes, and for example some UI element was originally supposed to emulate the iOS equivalent but then it was changed to UWP equivelent. WinObjC should be a way to 1:1 make a recreation of iOS libraries, and something like ipasim should be part of the project. WinObjC should make Windows "iOS compatible", one codebase, both iOS, iPadOS, macOS, and Windows can be developed for and published on both the App Store and Microsoft Store.
kevinsan commentedon Nov 9, 2024
VOM7HC commentedon Nov 9, 2024
sorry guy,s M$ never update this repo anymore. If you want, fork it as you own
upintheairsheep commentedon Nov 9, 2024
Please adjust your auto-reply settings to not reply to GitHub emails please.
upintheairsheep commentedon Nov 9, 2024
They may do it in the future, but check out touchHLE for now.