Advantage of using visual studio on windows for iphone app development over native environment - ios

I am reading a way to setup iphone application development environment on my windows. It states that “A network-accessible Mac set up with Apple's build tool” is required. My confusion is that, if i need to buy a mac machine and need to setup an envionment then why i will use windows and visual studio?
I am exploring why it is advantageous for me to build ios app in xamarin when i need to buy mac machine and install xcode. Why i will use xamarin when i am new to both C# and swift?
Please ignore my limited knowledge and flaw in question.

Using Xamarin to build apps
enables C# developers (there are millions of them) to leverage the language and framework they already know instead of learning a completely new one
allows them to share code between existing C# apps written for the web or desktop (very important in an Enterprise environment)
using Xamarin Forms, allows you to create a single codebase that targets multiple platforms (iOS, Android, UWP, etc)
if all you care about is iOS and you don't already know C#, then Xamarin may be of limited benefit to you

Related

RakNet for iOS on Xamarin

I have developed a Windows game that uses RakNet.
Now I'm interested in porting it over to iOS using Xamarin but I can not find any pre-compiled RakNet library for use.
Does anyone know or have any info on how to get RakNet to work with Xamarin for iOS?
Note:
Please do not suggest any alternative development environments such as Unity. I am very well aware of other development environments, but I need to take this approach instead of switching to a different environment altogether.

Why I cannot set other platforms when using Firemonkey Metropolis UI application?

Testing the different options of platform targets i have found this information on the delphi xe5 help:
Note: You cannot set OS X as the target platform for a Metropolis UI application.
FireMonkey Metropolis UI Application
I have searched for more answers on that and could not find what is the real reason it is not permited.
I would like to have the same looking of the application on windows and android tablet. (I know that I can use a "regular" FMX app and make that other way, however I have no idea what are the restrictions, since I believed FMX should be always crossplatform, considering just plain FMX app)
EDIT: My final objective for my current project is to create an application with the look and feel of Win Metro, but not WinRT compatible, and use this app on Win32(XP/7/8) and Android Tablets. I dont want to follow ANY platform specific rules, only have the closest possible working behavior as the Delphi generated win32 application.
Different platforms use different backend frameworks and have different UI requirements. That is why you cannot add OSX to a Metro project (OSX is not a Metro platform), just like you cannot add OSX to a Mobile project (OSX is not a mobile platform) or a Mobile platform (iOS/Android) to a Desktop project (they are not desktop platforms). Do not try to create a single application project that supports every UI platform that Delphi supports (a package project is a different matter - you can create multi-platform packages). You will need to create separate projects - a Metro project for Metro UIs, a desktop project for desktop UIs, and a mobile project for mobile UIs. You can share source files between them, but you should not share UI Forms between them. Use platform-appropriate UIs instead.
Metropolis UI is a hybrid system that uses IPC with a WinRT process. The WinRT process is used to display tiles and whatever else is needed over in WinRT land. This can only exist on a system that runs WinRT. Which means Windows 8 and not Mac or the mobile platforms.
It is true that you can build and run Metropolis UI apps on Windows 7 so clearly they can exist without the WinRT part. But the entire purpose on Metropolis UI is to be able to launch fake WinRT lookalike Delphi apps from the WinRT subsystem. So they don't really make sense anywhere else. I don't see any reason why Embarcadero would have invested effort making Metropolis UI apps work anywhere that does not have WinRT.
What you could do is use the style part of an FMX Metropolis UI project. That would give you the visual look that you are after. It would not be a Metropolis UI project, but would look as you wish. So you make a standard FMX desktop application targeting OSX. Then apply your chosen Metropolis style. This certainly works for desktop applications and I see no reason why it won't work for an Android tablet application.
Just open the style(*.style) file in a text editor. And you will see some thing like :
PlatformTarget = '[MSWINDOWS][MODERN][DEFINEFONTSTYLES]'
And then just add the Platform you need.

What Xamarin is actually doing when using an iOS build host?

I've noticed that there is a possibility in Xamarin to connect Visual Studio to an iOS build host.
What is this build host, is there any documentation about its architecture? What code does Xamarin.iOS send to this build host?
[Edit]
I want, as a personal project, make an iOS build host in Windows. I know that this can be achieved, and I'm sure that technically, I have all the needed tools to re-create one. My concerns is about the architecture of an original iOS build host. I want to know what is the communication between Xamarin and a iOS build host, and what is the build flow. And this is not documented.
A great explanation from here.
Xamarin.iOS compiles c# source code against a special subset of the
mono framework. This cut down version of the mono framework includes
additional libraries which allow access to iOS platform specific
features. The Xamarin.iOS compiler, smsc, takes source code and
compiles it into an intermediate language, ECMA CIL (common
intermediate language), however it does not produce ECMA ABI
compatible binaries unlike the normal mono compiler, gmcs or dmsc.
This means any 3rd party .Net libraries you want to include in your
application will need to be recompiled against the Xamarin.iOS subset
of the mono framework using smsc.
Once a Xamarin.iOS application has been compiled into CIL it needs to
be compiled again into native machine code that can run on an iOS
device. This process is carried out by the SDK tool ‘mtouch’, the
result of which is an application bundle that can be deployed to
either the iOS simulator or an actual iOS device, such as an iPhone or
iPad.
Due to restrictions placed by Apple, the iOS kernel will not allow
programs to generate code at runtime. This restriction has severe
implications for software systems that run inside a virtual machine
using just-in-time compilation. Just-in-time compilation takes the
intermediate code, for example mono CIL and compiles it at runtime
into machine code. This machine code is compatible for the device it
is running on at the time of execution.
To work around this restriction the mtouch tool compiles the CIL ahead
of time. A process that the mono team describe as AOT, ahead of time
compilation.
Some quotes from Xamarin docs:
Xamarin iOS for Visual Studio accomplishes an amazing feat: it lets
you create, build and debug iOS applications on a Windows computer
using the Visual Studio IDE. It cannot do this alone, however - iOS
applications cannot be created without Apple’s compiler, and they
cannot be deployed without Apple’s certificates and code-signing
tools. This means that your Xamarin iOS for Visual Studio installation
requires a connection to a networked Mac OS-X computer to perform
these tasks for you. Once configured, Xamarin’s tools will make the
process as seamless as possible.
Starting with Xamarin.iOS 4.0, there are two code generation backends
to Xamarin.iOS. The regular Mono code generation engine and one based
on the LLVM Optimizing Compiler. Each engine has its pros and cons.
Typically, during the development process, you will likely use the
Mono code generation engine as it will let you iterate quickly. For
release builds and AppStore deployment, you will want to switch to the
LLVM code generation engine.
Conclusion
So there is no way to make an iOS build host in Windows, as you said.
I guess Xamarin send to the build host the .Net assembly file (Orange part of the picture), to be compile into native ARM code using Apple llvm, and others tools like xcode-build to signed, link and build your application.

How to use Xamarin in Visual Studio and Mac in the same time

I have just developed and android app using eclipse and now I want to develope its IOS version. I want to use Visual Studio and C# (I feel pretty much comfortable in these environments).
I read that, to achieve this I can use Xamarine. Everything is OK with configuring Xamarine on Visual Studio and using it in Visual Studio (I understood this part). I couldnt understant the "mac" part. They are saying that in order to build this app I need a mac running in my local network. Unfortunately I have no idea about Mac. Instead of using it in a local network, could I just install it in a Virtual Machine in windows and configure it on that way that I can see this mac from Visual Studio (How can I do this ?! :S).
I am sorry if my question is unclear but I would be greateful if any of you helps me understand these issues and help me develop my first IOS app in Visual Studio.
If you are going to do iOS development using Xamarin you need a Mac. A Mac will always be required to submit the app to the app store, and the way Xamarin works, you need to use a Mac to create the UI for iOS apps as well.
To get the most of the Xamarin, you ideally would develop your base code using Xamarin and C#, then build separate UI's for both Android and iOS. While your UIs are separate, your base core code is all the same for both apps.
It really does not make sense to have a native Android app all in Java, and then write the entire iOS app in C#. Either stick to completely native apps for both platforms, or use a wrapper like Xamarin for both.
Xamarin.iOS for Visual Studio makes it possible to develop iOS
applications on Windows, but you will still need a Mac in order to
compile and run the code.
Today, Xamarin.iOS integration in Visual Studio is focused on enabling
developers to develop in C#. Xamarin developers who write Xamarin.iOS
applications on Windows typically hand-code their user interfaces—or
they will need to switch to the Mac to use Xcode (or a beta version of
Xamarin’s new iOS Designer) to interactively design an iOS user
interface layout.
"or use a wrapper like Xamarin for both"
I have discovered the term wrapping is not correct for this product.
Unlike other products (Corona, Phonegap, Titanium, ...) that wrap up in a common, genericized library, Xamarin compiles at core level with no penalty. It is 100% native. All functionality in all it's supported platforms is 100% available and not watered down.
Wrappers can be faster to program in, in theory, but when you factor in the time you will spend looking for workarounds for the one piece of functionality that is available natively but not in your wrapper library. When you factor in the constant bugs because wrapping for 3 or more platforms is a constantly moving target and you can't count on it working from day to day.
When you factor all those things in, writing native in c# for all platforms is the better option.
I tried them all, and xamarin was my last choice as I was distracted chasing that perfect golden goose wrapper product.

Is it possible to write a GUI desktop app in F# + mono on Mac and have it run without modification on Windows?

I'm interested in developing desktop apps for Windows, but it would be most convenient if I could develop these apps on my Mac OS X Air laptop, without running a virtualization environment. How far can you get developing Windows GUI Desktop apps using mono and F# on OS X?
If you aim for WPF - not far. Sadly, you will have problems with WPF even in a virtualized Windows environment, as it uses 3D acceleration.
Sticking to the "traditional" Windows Forms works, but they are not the preferred way to create new applications nowadays.
You could use a cross-platform UI toolkit. Monodevelop uses GTK#, there are probably others. It'll run everywhere without modification but will look somewhat alien everywhere. That's the tradeoff you make for not having to make a different UI per platform.
Instructions for using F# from Monodevelop are detailed here. Hopefully with that you should be good to go!

Resources