"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."
Which is interesting, since I thought that interpreters were strictly against Apple rules?
According to the App Store guidelines, applications can't download code, and must use the built-in Javascript interpreter for Javascript execution (those are the two rules in the App Store review guidelines that are relevant to the execution of downloaded code).
In practice, though, Apple has generally accepted applications that pass user-supplied code to an interpreter, as long as that code is actually user-generated: see Pythonista (embedded Python interpreter), Continuous (embedded .NET CIL interpreter, akin to what Xamarin's doing here with Live Player), Ruby for iOS, etc.
You won't find any compiled languages (which compile down into native machine code) in the App Store, though; even ignoring the review process, there are technical restrictions in place in sandboxed iOS apps that prohibit applications from running arbitrary code.
"OS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available (see Xamarin.iOS Limitations )."
Normal deployed apps are. Here though, the app that's actually running is the Xamarin Live Player which comes with an IL interpreter. In the normal cycle of Xamarin iOS development from Windows, the DLLs are compiled, and then there's another step where they are AOT compiled to ARM assembly on the Mac. In this case though it avoids the step of compiling on iOS, it just builds the DLLs and sends them to the device.
Are there any examples of solid, stable, cross-platform apps developed with Xamarin? I tried looking at their website, but it doesn't seem possible to tell the difference between apps being tested using Xamarin Test Cloud, and apps developed using the Xamarin Platform.
We have done several high profile cross-platform applications with Xamarin. As a user you can't really see the difference while using it. The most noticeable difference is that the app startup time is couple of seconds slower and the application bundle steals at least 10MB of app size. As a programmer the Developer Experience™ is a little rough around the edges with casual bugs. But hey you get to write your core business logic only once and in C#.
Here are some of the more visually appealing apps we've made with Xamarin:
I've worked on a number of Xamarin apps. You can definitely make stable cross platform apps, it's just very tedious; sometimes it requires more effort than developing 2 separate native apps.
rdio had award-winning iOS, Android, and Windows Phone apps based on Xamarin, with around 70% of the code shared across all platforms. The remainder was all platform-specific code, but still in C#.
Sadly, they went bankrupt, though not because of their app quality!
There's nothing in that description that indicates the Slack app is written using Xamarin. From that link:
"Slack's friendly, easy to use messaging platform is the future of work. Given its preeminence in the enterprise and among mobile workforces, mobile is critical to Slack’s success. Over three million daily users rely on Slack to communicate with their teams, and Xamarin Test Cloud helps Slack make sure customers are productive in all scenarios. Its mobile quality engineers view test reports to see how features look and behave on devices — and can quickly solve customer issues."
Sounds like they just use Xamarin Test Cloud.
Here's a list of decent looking Xamarin apps:
- BitWarden (it's made the rounds recently on HN)[1]
- Microsoft Pix [2]
- A bunch of games that look pretty slick (I've downloaded a few and flipped through some of the screens) [3]
It's cool to see xamarin growing after the microsoft acquisition. Replicating good existing features that other environments have (like exponent, etc) is a good sign that things are progressing.
Building apps with Xamarin however is still not a pleasant experience whether it be Native or Forms.
Although Microsoft has built some cool apps with forms (check the microsoft github and you can find them), it's still a pain to work with things visually. Odd bugs and restrictions that require dense workarounds occur if you deviate from the standard application uses (tables and forms). It makes sense it being a targeted API so I'll leave it at that.
Native was something I really wanted to like. I built 2 PoC apps that later got translated into swift/java and react-native respectively. Building your own libraries and widgets is fun, but not when you have a deadline. For non-visual libraries, it's awesome. I've worked with the .Net ecosystem for a while, and while the way libraries are written isn't my favorite (OverkillOOP sometimes), everything is consistent. Visual Libraries are rough. Quite a few I wanted to use were abandoned with no source code and just a link to download the nuget from the xamarin store. I could spend the time building the 10 custom widgets that the client REALLY wants (even though the app could work fine without it), or I could use native/RN UI libraries to wow the client giving them what they wanted and a little bit more in the same visual/design style.
To sum it up: it's more work to write a xamarin application when I'm more than capable of handling 2 similar languages (most app requirements are just applying known patterns and library gluing anyways) or using Exponent/ReactNative.
As a side note, I prefer F# and while the Xamarin team says they "like it", it is a pretty 2nd class system and definitely not something you want to use with a deadline.
Ive only dabbled in Xamarin briefly before, but I can imagine the numerous ways it could complicate things. If you have ever been deep into Windows Forms or the windows API in general, even native has its own unpleasant experiences, though I cant speak for Apple stuff.
We recently went the hybrid route using Cordova, and while it too had its share of shenanigans, I think it was much faster/better than separate apps.
So I take it you still need a mac with xcode to properly codesign and submit release versions of apps to the ios app store? I'm assuming the preview player ios app is just interpreting c# in debug mode? No way apple blessed microsoft's preview app with jit entitlements?
I'm Chris Hardy, a program manager at Microsoft working on the Xamarin Live Players. Yup, you will still need a Mac, to deploy to the app store, to work against different APIs that require special provisioning (such as Push Notifications, etc.), sign and provision applications to share via TestFlight. The goal for Xamarin Live Player is to provide an easier and faster way to work and iterate on applications with C# and Xamarin without the need to commit to downloading and provisioning different devices to get up and running.
I don't think you are correct. For a proper release, yes, the C#/F#/VB is AOT compiled. For this "Live Player" app, the IL in the DLLs is interpreted. Basing this off of this:
"Microsoft believes its Live Player system is entirely compatible with Apple's rules and regulations for App Store apps. Behind the scenes, the Live Player includes an interpreter for .NET code. This means that running an app through Live Player is slower than it would be if natively built on a Mac, but that's not such a big deal for many aspects of user interface development."
So there are a couple of additional important limitations then, probably (beyond the speed loss of interpreting instead of compiling)
* Won't show up as a separate app on the device (so you can't test that your app icon is OK, or use push notifications, or any other apple service that needs per-app-id provisioning)
* Can't distribute through testflight
* Inconsistent iOS/UIKit behavior. iOS and UIKit enable and disable various compatibility behaviours depending on the iOS SDK used to link the native app you are launching. Obviously this will be set to the SDK that microsoft used when they distributed Live Player to the App Store. Your own application, when distributed on the App Store, may very well be built with a different toolchain version which may trigger different compatibility flags. The most user visible of this was the iOS6->iOS7 total UI redesign (old app builds retained the iOS6 look, newly re-compiled apps got the iOS7 look for everything), but there are tons of similar gotchas in every release (things surrounding table views, button tap behaviors, status bar padding, keyboard sizes, etc etc).
"iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available"
Because apple does not allow runtime code generation, then obviously the Live Player preview app won't be able to make use of any ARM assembly language binary produced by .NET. The only way this Live Player preview app stands a chance of being approved by apple is by interpreting everything. Mapping memory executable is impossible for "mere mortals" on iOS, only a few specially-blessed first party apps like MobileSafari can do that (to support JIT javascript). And the whole reason for using the Live Player as a conduit is to avoid the need for a native mac xcode toolchain to package a real .ipa app.
The section you quoted is only applicable for native builds to .ipa (which you probably still need a mac for, since iOS requires the app to be code signed and provisioned even for debugging/development modes)
Yeah, these days it's easy to use an online service to submit to the App Store. Buddybuild (buddybuild.com) is really helpful for this. It acts as a CI system, and it can deploy builds to iTunes Connect with one click.
I came here to ask about submitting to the App Store. Does this mean that a Mac is, technically, no longer required for the entire process of development -> release of iOS apps?
You'd probably want to performance test your app with a full MacOS compile, but the whole UI implementation, function and experience testing can be done without a Mac. And you need a Mac for deploying to the store.
You are correct. They actually have a tool that scans the Cocoa libraries and generates API bindings for Xamarin to use. Source: Miguel De Icaza on the .NET Rocks podcast.
I have been working on a huge Xamarin app for weeks now and both Xamarin Studio and Visual Studio for Mac are horrendous. There are so many bugs and quirks in those things. Almost always when I think I found an issue with the underlying libraries (we use the native Android & iOS libs as well as Forms and a mix of both), it is an issue with either of the IDEs. I have a solid Macbook Pro and yet it comes to a halt and requires reboots after a bit. I even currently do parts with Vim and only compile/run with the IDE. I tried Rider but that's even worse. VS for Windows with this release might be worth a try. Did anyone try?
Wow, for a second I thought I was looking at an old post since this functions almost identical to how repl.it[0] is working and they just posted their framework on here a few days ago.
Anybody used this yet? This could end up be really helpful for me. I hate developing for android, but I collaborate with people that don't own macs enough that it ends up being my de facto OS for prototyping mobile crap.
Hey, PM at Microsoft here. I have used this often, and I find it to be perfectly suited for quick mockups and testing new ideas. However, it is still a preview, so there may be cases where live apps may fail on the device. Be sure to let us know, we are eager to improve this product!
Which is interesting, since I thought that interpreters were strictly against Apple rules?