Because it's by design. It's not that it is difficult to add a aarch64/ios backed to your favourite compiler. Making the artefact provisionable to emulator (which you would get on macOS only anyway, because what's inside is copyrighted and thus non-distributable) or physical device is entirely another game.
Apple is locking you in and you reward them for that.
There is no such thing as an “iOS emulator”. The iOS simulator uses an x86 compiled version of your code and links to it an x86 build of the iOS framework.
Again there is an existence proof you can deploy code directly from Windows to iOS devices....
Microsoft tells us that it talked to Apple about this functionality and that it has its rival’s blessing and that the Live Player application complies with all of Apple’s usual rules..
> There is no such thing as an “iOS emulator”. The iOS simulator uses an x86 compiled version of your code and links to it an x86 build of the iOS framework.
Now you are playing word games, just to avoid the point.
What matters is, that you cannot run it on another OS,
But as Microsoft has just shown, you don’t need to run “thier” emulator to develop on another platform.
because Apple does not supply one. You cannot supply your own,
Yet Microsoft did just that....
because the emulator/simulator/whatever has to run Apple code inside, and you don't have permission to distribute it, even if you had the inclination to make your own emulator/simulator/whatever.
Microsoft had the inclination to do just that....
So OK, Microsoft made an agreement and can now provision iOS packages. They had to find a way to test-run them somehow, and their solution won't allow you to write against native frameworks, only against theirs, which they can run on their platform.
So first you said that thier was no way to run on any OS, you couldn’t write your own emulator, etc. but now that I’ve shown you that you can do all that, now it’s that you can’t write against the native frameworks.
Guess what? You can’t write the same binary against different versions of Linux.
No, you run the .net code on the .net runtime. If you use UIKit namespace, for example, you will run with the dotnet shim.
> Microsoft had the inclination to do just that....
Because Microsoft doesn't have emulator or simulator. Not anything comparable with what Apple has, or what Google has (and what Microsoft is shipping for Android).
> So first you said that thier was no way to run on any OS, you couldn’t write your own emulator, etc. but now that I’ve shown you that you can do all that, now it’s that you can’t write against the native frameworks.
It is not a first-class solution.
> Guess what? You can’t write the same binary against different versions of Linux.
No, you run the .net code on the .net runtime. If you use UIKit namespace, for example, you will run with the dotnet shim.
And when you run your code on the iOS simulator you are also not running against the same code that’s is running on your phone...
You aren’t running ARM code.
Because Microsoft doesn't have emulator or simulator. Not anything comparable with what Apple has, or what Google has (and what Microsoft is shipping for Android).
When you run on your code on your desktop you run on a simulated environment - the Xamarin runtime on top of Windows. When you run your code on MacOS, you run on x86 version of the iOS runtime. By definition, you are running a simulator.
It is not a first-class solution.
So in your experience using both, what capabilities were you missing?
Actually you can
You haven’t had to ship C binaries to various Linux distributions....
For instance, the official MySQL driver for Python is not pure Python. Even if you are on Linux, you can’t just do a pip install from your box, create a zip file and guarantee it will work. You need to use the package built for whatever version Amazon Linux is based on....
Now you are playing word games, just to avoid the point.
It’s not a word game. Both of your assertions were incorrect. You no more need Apples proprietary “emulator” to develop apps for iOS - Xamarin is proof of that, nor is there a “policy” against developing or deploying iOS apps without a Mac - again Xamarin is proof of that.
Calling Apples simulator an emulator is just as technically incorrect as saying using Safari and setting the window size to match mobile screens an “emulator”
In the context of this debate it does not matter, whether it is emulator or simulator underneath.
What matters is, that you cannot run it on another OS, because Apple does not supply one. You cannot supply your own, because the emulator/simulator/whatever has to run Apple code inside, and you don't have permission to distribute it, even if you had the inclination to make your own emulator/simulator/whatever.
So OK, Microsoft made an agreement and can now provision iOS packages. They had to find a way to test-run them somehow, and their solution won't allow you to write against native frameworks, only against theirs, which they can run on their platform.
And you think that developing on Android is better? The emulator is running in x86 with an ARM emulator that running a Java virtual machine is giving you any “guarantees” (your words in a previous post) on how it will work on the device?
Apple is locking you in and you reward them for that.