Microsoft now lets iOS developers deploy, run and test their apps on Windows(techcrunch.com)
techcrunch.com
Microsoft now lets iOS developers deploy, run and test their apps on Windows
https://techcrunch.com/2017/05/11/microsoft-now-lets-ios-developers-deploy-run-and-test-their-apps-directly-from-windows
62 comments
I'm confused as well. Either this is a framework which I thought apple outlawed. Or it's a runtime which apple definitely outlawed.
Frameworks are fine.
Deployed apps are compiled to ARM assembly. Bit of info here:
https://developer.xamarin.com/guides/cross-platform/applicat...
https://developer.xamarin.com/guides/cross-platform/applicat...
You got it, the relevant piece:
"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 )."
"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.
This is my best guess of what's happening based on this article: https://arstechnica.com/information-technology/2017/05/xamar...
This is my best guess of what's happening based on this article: https://arstechnica.com/information-technology/2017/05/xamar...
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.
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.
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.
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.
My experience as well. I gave up on it and just used Native tools.
re:more effort
Did you have the freedom to recommend going native or was Xamarin a requirement or was it too late to switch?
I would imagine xamarin is faster when you have a complicated domain.
I imagine it goes faster to make the domain complicated with Xamarin. Make of that what you will...
You can't make a domain more complicated by technology choices.
You can make it more technically complicated.
You can make it more technically complicated.
Probably most notably the Slack App: https://www.xamarin.com/customers/tech
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]
[1] https://github.com/bitwarden/mobile
[2] http://www.microsoft.com/en-us/research/product/microsoftpix...
[3] https://www.xamarin.com/customers/gaming
"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]
[1] https://github.com/bitwarden/mobile
[2] http://www.microsoft.com/en-us/research/product/microsoftpix...
[3] https://www.xamarin.com/customers/gaming
We have a team that wanted to use Xamarin but it seems after working on it for half a year they seem to prefer native.
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!
Sadly, they went bankrupt, though not because of their app quality!
Their mobile app was terrible. God awful UI, Constant stuttering, App crashes. So bad it made me switch to Google Play.
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:
[1] http://valopilkkutaksi.fi/briefly-in-english/
[2] http://www.upmmetsani.fi/
[3] http://fair.online/
Here are some of the more visually appealing apps we've made with Xamarin:
[1] http://valopilkkutaksi.fi/briefly-in-english/
[2] http://www.upmmetsani.fi/
[3] http://fair.online/
https://www.xamarin.com/customers
Each example across multiple industries says whether they're using test cloud, or the app was developed with the platform :)
Each example across multiple industries says whether they're using test cloud, or the app was developed with the platform :)
[deleted]
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.
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.
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.
To be honest, that page about limitations in their docs is a huuuuuge let down
https://developer.xamarin.com/guides/cross-platform/live/tro...
- Android user interfaces designed with AXML files are not currently supported.
- Some iOS storyboard features are not supported.
- iOS XIB files are not supported.
Well, let's see how this evolves over time...
https://developer.xamarin.com/guides/cross-platform/live/tro...
- Android user interfaces designed with AXML files are not currently supported.
- Some iOS storyboard features are not supported.
- iOS XIB files are not supported.
Well, let's see how this evolves over time...
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?
Yes you have to compile with a mac to deploy to itunes connect. No it compiles C# AOT to arm assembly code.
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."
https://arstechnica.com/information-technology/2017/05/xamar...
"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."
https://arstechnica.com/information-technology/2017/05/xamar...
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).
* 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).
Look here https://developer.xamarin.com/guides/cross-platform/applicat...
"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"
"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)
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)
Right, that's how it works if you compile your app and then deploy it to the device. It's not how Xamarin Player works, though.
Are there not online services for this? (Or is that outlawed?)
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.
Bitrise can do that too, and has Xamarin support as well - https://www.bitrise.io/
(I'm the CTO there)
(I'm the CTO there)
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?
Yes. Buddybuild can build IPA files and upload them directly to iTunes Connect.
There is no mention of this process being able to upload an IPA file so I'm assuming we still need to use xCode or Application Loader on a Mac
They do say "the whole process"
https://www.buddybuild.com/features/deployment/
Also http://docs.buddybuild.com/docs/download-ipa
Also http://docs.buddybuild.com/docs/download-ipa
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.
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.
more accurately: Microsoft now lets Xamarin developers deploy, run and test their iOS apps on Windows
Yeah, they left that part off didn't they? Xamarin != Native iOS.
How is Xamarin not native? It's compiled right, not some web view hybrid?
Yes, Xamarin produces a compiled executable, as you would get in Swift or Objective-C. It is not a web view hybrid.
I work for Microsoft
I work for Microsoft
By Native iOS you mean not written in Objective-C/Swift using Cocoa Touch
Xamarin uses Cocoa Touch. It gets compiled to the same thing as something written in Swift. So definitely iOS Native.
It is native code.
Yep convenient ommissions = marketing
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.
[0]https://repl.it/site/react_native
[0]https://repl.it/site/react_native
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!
I haven't used Xamarin yet but I'm really enjoying Ionic framework for multiplatform development with JavaScript.
* written in C#.
Which is interesting, since I thought that interpreters were strictly against Apple rules?