Does anyone know if Xamarin build for iOS simulator is somehow different from regular Xcode simulator build?
In other words is Xamarin simulator build "clean" native build?
As stated in Xamarin docs:
When you compile any Xamarin platform application, the Mono C# (or F#)
compiler will run and will compile your C# and F# code into Microsoft
Intermediate Language (MSIL). If you are running a Xamarin.Android, a
Xamarin.Mac application, or even a Xamarin.iOS application on the
simulator, the .NET Common Language Runtime (CLR) compiles the MSIL
using a Just in Time (JIT) compiler. At runtime this is compiled into
a native code, which can run on the correct architecture for your
application.
However, there is a security restriction on iOS, set by Apple, which
disallows the execution of dynamically generated code on a device. To
ensure that we adhere to these safety protocols, Xamarin.iOS instead
uses an Ahead of Time (AOT) compiler to compile the managed code. This
produces a native iOS binary, optionally optimized with LLVM for
devices, that can be deployed on Apple’s ARM-based processor.
Related
Given an app written in C# for Xamarin, can it be built to run on all the supported platforms with minimal changes, including Android, iOS, MacOS, Windows?
I realize that Xamarin claims 90% of the code is shareable across platforms (and 10% needs to be customized), and I'm referring to that "90%".
What I don't understand is whether that 90% is shareable across the different Xamarin tools,e.g. Xamarin.Forms and Xamarin.Mac or if those are substantially different tools with different APIs, etc.
For example, I see that with Xamarin.Forms I can build for iOS, Android, and Windows. But not MacOS. So, on a Mac, can I install Xamarin.Mac and then build the same app for MacOS ?
You can add a MacOS target for your Xamarin.Forms-based UI, of course, this is done via Visual Studio for Mac:
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/platform/other/mac
There are items within Forms that are not feature complete on MacOS and thus it is still in a "Preview" release and those are listed on the "Platform Support macOS Status" wiki:
https://github.com/xamarin/Xamarin.Forms/wiki/Platform-Support-macOS-Status
Xamarin.Forms is the framework that allows you to create cross-platform apps between Android, iOS and UWP. In my experience, a lot of the features of Xamarin.Forms do not transfer over to Xamarin.Android. In fact, a big chunk of the way things are done for UI Xamarin.Forms will not transfer over to the Xamarin.iOS and Xamarin.Android. Most of the times when I find a solution that works in Xamarin.Forms and I try to do the same thing in Xamarin.Android I end up just figuring out the problem myself in Xamarin.Android from scratch.
When they say that 90% is shared, they mean that within Xamarin.Forms... 90% of the work on your models and code behind can be shared between the projects (within that Xamarin.Forms solution) and 10% will have to be custom tailored for each platform (UWP, Android, iOS)
EDIT: Just for clarification in the future, you need an iOS device or an iOS virtual machine to compile the code on iOS
To build Xamarin.iOS apps with Visual Studio 2019 on Windows, you will
need:
A Windows machine with Visual Studio 2019 installed.
This can be a physical or a virtual machine.
Windows system requirements
A network-accessible Mac set up with Apple's build tools and Xamarin.iOS.
Visual Studio 2019 accesses this machine over a network
connection to use Apple's build tools, which are required for
compiling native iOS applications.
Mac system requirements
source: https://learn.microsoft.com/en-us/xamarin/ios/get-started/installation/windows/?pivots=windows
As long as you use .Net code and Xamarin.Forms it is 100% portable/sharable across every single project. Xamarin.Forms are currently in beta for macOS and Windows WPF (but for UWP it is not beta), and for macOS particularly they don't have the true native look.
Xamarin does support using the native interfaces and native APIs and whenever you do that, it is not portable.
So there is nothing like 90% sharable, it may be some estimate for some cases. It can be 100% sharable or it can be only 10% sharable depending on your project and how much you stick to the sharable APIs.
I am able to use OpenSSL static libraries (libcrypto.a and libssl.a) in my iOS app thanks to this help. Now i can also use OpenSSL dynamic libraries (libcrypto.so and libssl.so) in my Android app version thanks to this info. I downloaded the files for Android in the OpenSSL_1.0.2g_Android.zip file from here. I just guessed and used the ARM files (armeabi-v7a folder) instead of the Intel files (x86 folder) and it worked on my Android test phone.
My question: How do I make an Android build that uses the correct library files on ARM devices AND also on Intel? I don't know how to deploy both sets of files for this. Below is snip of project window showing where i test added the second libcrytpo.so library file for x86.
But, this second libcrypto.so does not show up in the deployment window, only the first version i added (the ARM version) remains.
I was hoping i could somehow use compiler directives but maybe i just need 2 independent projects altogether? One built for Android ARM and other for Android x86? Further, all i'm needing in my code is an IdHTTP1->Get() so maybe their is a way i can use the built in BoringSSL fork? If so, how?
russ
C++Builder 10.3 Version 26.0.33219.4899
RAD Studio does not support producing Android apps for Intel, only for ARM, so don't even worry about trying to use the x86 libs on Android.
Also, Indy does not support BoringSSL at this time.
I'm thinking about porting a .NET based desktop application to Mac using the Xamarin.Mac platform. I can't seem to find any info about deployment size of the resulting application. Is it like Xamarin iOS development i.e. the C# code is natively compiled into mac code and I don't have to worry about distributing the .NET runtime? If no, then how large is the .net runtime that I need to distribute with my application?
Xamarin.Mac apps are self-contained and do not require a separate Mono framework to be installed. Only the portions of the framework that your app uses are included inside the app bundle in order to keep the size as small of possible.
A x86_64 Xamarin.Mac Cocca Hello World Xamarin.Mac Mobile Framework based App with the linker set to:
Don't Link: ~48mb
Link Framework SDKs Only: ~20mb
Link All: ~20mb
Note: Sizes based on Xamarin.Mac 2.9.2.81
Note: Using the other Xamarin.Mac frameworks will of course produce slightly larger bundle sizes...
Note: This is a do nothing app, so once you start adding assets, content, code, external packages, etc... your app size is going to grow.
Xamarin.Mac apps are not compiled via LLVM into bit-code and/or machine code like Xamarin.iOS apps. There are some old email threads floating around that this was begin looked at along with AOTing, but I assume lack of demand vs. engineering time required never was justified.
Note: It is possible to use a custom OS-X Mono build that is LLVM-enabled, but I have not done this in x86_64-based Mono OS-X apps for App Store distribution, only local app for private distribution. This is all done outside of Xamarin Studio and not a supported configuration. That said and with xamarin-macios begin open-source now, if you are using Xamarin.Mac Mobile Framework in your OS-X app which is the shared Unified framework, you can wire up an Mono/LLVM-based build environment, but again, not a Xamarin supported configuration.
Dec 2018, Xamarin.Forms + Xamarin.Mac give 16Mb bundle size for a an app with 5+ forms. This is a self-contained application with no dependency on Mono or whatsoever framework installed.
I have a project in Android Studio (on a pc), and as far as I know now Microsoft owns Xamarin and its free once you have a Visual Studio license, then you can develop apps using C#(Already know that I have to port the JAVA code) and then compile in a MAC the IOS app.
My 2 concerns are:
When you can't compile, will the IDE show the IOS related errors?
There is a clear implementation of "cross platform code" vs "specific code"?
How Xamarin manage it?
In addition, our plan is to finish the app for Android which is our primary target and then manage the IOS, besides the other questions, what I need to know is if that is possible.
Yes, the VS IDE will show you build errors from the iOS build server.
Yes, you can build an Android app using Xamarin and later extend it to build an iOS app also. This is easiest if you use Xamarin Forms, but it also possible with native Android/iOS UI, but will be much more dependent on how you architect your applications.
In my Visual Studio Xamarin Forms iOS project, I am linking against a native (c++) library I built and deployed using Visual Studio Cross C++ Platform. I can link and run against an actual device (through the Mac Server), but I cannot get it to work through the simulator. If I build with the same link settings, the build fails, not being able to find the entrypoint. If I choose not to link, then the build succeeds but I get am Entrypointnotfoundexception when running at the point where I try to call into the native code.
I just went through the example from your comment, using his sample code here. I had to do a couple things to get it to run correctly. My problem was on Xamarin.iOS, but the same steps can be applied for Xamarin.Forms, assuming you already have platform-specific integration working.
Since you have the code working on a physical device, you should already have a Native Static Reference to your .a library. But the iOS simulator runs on the x86_64 architecture (iOS 11 and later does not support i386), while your device likely runs on some version/variant of ARM. It sounds like your library is built to support only your device's architecture. You can check this by running lipo from your Mac:
% lipo -info /usr/lib/libCLib.iOS.a
To support the sim's architecture as well (see this article), build the C++ project to the architectures you need to support, then combine them, like so:
lipo -create -output libCLib.iOS.a libCLib.iOS-x8664.a libCLib.iOS-arm64.a
Use that output .a file as your new Native Static Reference file back in Visual Studio. Change Supported Architectures in your project settings to x86_64, and that should be everything. Hope this helps somebody.