> 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....
> 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.
You are running the same framework by the same author, which certifies that they behave the same to some extent. It's the same way, that Gnustep is not an adequate replacement for Cocoa.
> 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.
Are you still interested in arguing in circles? I'm not, it makes no sense and is a waste of time. You demonstrated that you are not willing to understand the point, you just want to win an argument on the internet. Go find someone else for that.
> You haven’t had to ship C binaries to various Linux distributions....
Now it is C binaries... It was just binaries before. You can move Go binaries with no problem, the crosscompiled ones too, because they do not have problem with importing symbols nilly-willy.
You can do that with C binaries too, but you have to take care. Just make sure you know what are you linking against, bundle it if it is not present on the target or just link statically. It no problem for a competent developer, who knows what a linker is and can maintain ABI hygiene.
If you think that is something complicated, go setup apache with mod_wsgi on windows, you will run into the same problem. There you will have to align the right Visual Studio version (because each msvcrt version has its own ABI) with Apache version with Python version, otherwise the hell will break loose. Of course, all the native python extensions you are going to use will have to be compiled with the same Visual Studio version. Yet nobody is saying, that it is impossible to distribute binaries that run on all Windows releases, mainly because it has nothing to do with specific system, but with the apps you chose to run, how they are built, and also boils down to ABI hygiene.
You are running the same framework by the same author, which certifies that they behave the same to some extent. It's the same way, that Gnustep is not an adequate replacement for Cocoa.
Have you done mobile development?
If you run on top of the iOS simulator, you still don’t have any “guarantees” that they will run the same way. I’ve been doing mobile development since before the iOS App Store every existed (Windows Mobile), you always had to run on the real device and the behaviors and the performance characteristics were nowhere near the same.
When you are developing with Xamarin, you smoke test on the simulator at first and then you run on the device using the Xamarin player - the same way you are going to deploy your code.
Now it is C binaries... It was just binaries before. You can move Go binaries with no problem, the crosscompiled ones too, because they do not have problem with importing symbols nilly-willy.
You can do that with C binaries too, but you have to take care. Just make sure you know what are you linking against, bundle it if it is not present on the target or just link statically. It no problem for a competent developer, who knows what a linker is and can maintain ABI hygiene.
Excuse me for referring to the most popular language for writing native code (and the language that Linux itself was written in) instead of specifying that I’m not talking about Go of all things. Almost all non C languages that I’m aware of have a way to call native C code - not Go.
Your “solution” for distributing C code is “statically linking”? So if I have four python modules that all have native dependencies they should all ship with statically linked libraries? Not only will my code be larger, so will the memory requirements. If you have four processes all using the same dynamically linked library, the library is only in memory once, with statically linked libraries, you are increasing your code size and your memory footprint.
How well do you think that with work with the 128MB VMs that you get to run Lambdas? Or do you think I should just spend more on higher capacity lambdas? If I wanted to use heavyweight VMs and Docker containers, I might as well use Windows.
But this whole thread you’ve shown when it comes to developing mobile applications, you’re speaking hypothetically while I’m speaking from a perspective of doing mobile development for over 10 years.
I’ve even played around with J2ME development.
The largest issue is that you’re over indexing on the value of the simulator. Mobile simulators have never been a good way to validate the functionality, user interaction, performance, etc. of a mobile app. They are pretty good for development, and okay for negative testing (if it doesn’t work on the emulator it probably won’t work on the device), but you can’t depend on it for positive testing.
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?
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.