The iPhreaks Show
The iPhreaks Show
206 iPS Build Special 1: Embeddinator 4000 with James Montemagno
43 minutes Posted Jul 13, 2017 at 3:00 am.
] – Introduction to James Montemagno
] – What is it that you wanted to talk to us about?
] – C# library, not Xamarin-based
] – How do you take a C# / .NET library and give it an Objective-C interface?
] – Difference from Microsoft Windows Bridge for iOS
] – Libraries and frameworks available
] – What else is brought in?
] – Is there a reason you’re not using frameworks on MAC OS?
] – Development cycle
] – Debugging
] – How to integrate with Visual Studio?
] – Microsoft announcement with regard to Embeddinator
] – How large is Mono
] – Microsoft as open-source supporter
] – How to fix a bug
Download MP3
Show notes
iPS 206: Build Special 1: Embeddinator 4000 with James Montemagno
This episode is live at the Microsoft Build 2017 in Seattle with Andrew Madsen and Jaim Zuber. We have James Montemagno from the Mobile Developers Tools Team at Microsoft. Tune in and learn more about Embeddinator 4000!
This is James Montemagno’s third time on iPhreaks. He is a Principal Program Manager on the Mobile Developers Tools Team. He is a long-time Xamarin developer for almost 6 years now.
The Embeddinator 4000 is an open-source project. It falls underneath the Mono open-source. It’s a Github organization so it’s not under Microsoft branding. It’s been around for a while but the team re-tooled it in a way that every single iOS, Android, Mac, Linux, and Windows developers is going to love. Their goal is to bring .NET to every developer.
Developers still want to find a way of sharing code. There are a few ways to do it today. You can write a bunch of C++ but no one wants to do that. The Embeddinator has the ability to execute C# and .NET code anywhere. It enables every developer writing applications in any language to take a .NET library to write some business logic. And then, compile that through a tool into a native library that they can consume in Objective-C, Swift, Java, or C++ library.
It’s not Xamarin-based so you don’t need the Xamarin toolkits. You could use Visual Studio 2017. It’s just a command line tool so you can run it on Mac or PC. You don’t need anything besides the ability to write a C# library. Run that into the Embeddinator, which would then give you a dynamic library if you’re just doing an Objective-C Mac OS app, or it would give you a framework for iOS.
Each platform whether it’s Objective-C for Mac, for iOS, or Swift for iOS, will be able to create those specific libraries, which will go to their own tooling.  Obviously, the syntax is different. There are some things in C# that don’t necessarily exist in Objective-C. So it has to be converted into a call block or maybe you’ll not write that type of code because you know you’re going to consume this library.
All the code is open-source on the Github page. You can think of it that it is going to provide the native interfaces and then, kind of P/Invoking into the compiled-up run time or the machine code that’s there.
That bridge application is focused on iOS applications, specifically, on games. These games are brought over into to a UWP application. On the other hand, Embeddinator is very powerful for companies which are literally doing the same thing over and over again. This also allows collaboration with other teams. If mobile developers are calling their mobile API, they could just have one shared mobile API that’s being called across each platform.
The difference here is you’re not porting any application, you’re creating a common framework or a common element that’s going to be running natively on each platform. You’re first writing it in C#, and then, embedding it into each application.
All of .NET is available to them. When they’re creating .NET libraries, Embeddinator supports almost everything in .NET 4.6, which is a large amount of .NET. It can be embedded into your applications.
What you’ll see inside of this framework is a bunch of registers and header files.  The bindings that get created are all here. It will create the header files that will talk and communicate to that framework specifically. It's executing .NET code based on the device you’re running it on - ARM32, ARM64, i386, your simulators, x86, x64-bit.
The team got a dynamic library that they’re working first but the plan is doing framework. They want to keep it simple and do frameworks everywhere. They’re also going to be adding Swift support, Java support for Android, C, C++, Linux support, and continuously putting it into more and more platforms.
The getting started is you have this library, run this command line, and then, drag and drop some files. That’s just day one. But you don’t want to do that over and over again. The command essentially says. “Run this Objective-C generation in this DLL. I want to create a framework. It’s iOS. Put it in this directory.”
You have 2 IDE’s open. Visual Studio for Mac and Xcode. When you’re writing your C# code, you’d write that in Visual Studio. In each of the libraries, you can have a post-build step. When you hit compile, you can essentially run this command line. The output directory would be your Objective-C, iOS or Mac application. And then, it’s available immediately inside of Xcode.
At this point, you’re not going to be debugging across Xcode. Think of it like you’re debugging another framework. Think of creating a library but then, create a unit test around it. You can test it. You can write a console application. You can write a Xamarin application that is a bunch of buttons that you click to test the Native functionality.
It’s not yet super integrated into Visual Studio, where you can right click and say Export to this.
When you go to the Github page, there are walk-through tutorials – Getting Started with Mac OS, Getting Started with iOS, etc. There’s a download package that you have to install that will install all the Embeddinator and all of the requirements. It requires Mono, which is the .NET runtime on Mac. But when you install Visual Studio for Mac, it will bring it in. That’s all you really need. The Embeddinator 4000 is literally inside the /Library/Frameworks/Xamarin/.Embeddinator-4000. And then, you start executing some commands, which are documented.
The Embeddinator is available. It’s part of the Mono project. Microsoft is actively working on it. Core members of the Xamarin team are working on this tooling to make it a great experience. Give it a try. Essentially, it’s under development but it’s a v1-type of release for Mac, iOS, and Objective-C, Swift applications, etc.
There is an advanced optimizer and linker so you’re not bringing in the entire Mono runtime or the entire .NET installation. The actual Mono runtime is extremely small. It’s usually in a few MB. But on different devices, there’s a difference in runtime because they’re executing code a little bit different. And it’s not as big as Swift.
The Embeddinator project started under the Mono organization. The license should be under MIT license. It’s copyright Microsoft, technically. The project is also accepting external contributions.
When you go to the Embeddinator source code, it’s all just C# code. There’s probably going to be command line and build things. There’s documentation to getting started.
For iOS developers, if you can read Swift, you can read C#. It’s still object-oriented, still, have classes and methods.
James Montemagno
Coffeehouse Blunders podcast
Andrew Madson
Merge Conflict podcast