Microsoft now lets iOS developers deploy, run and test their apps on Windows
techcrunch.com
techcrunch.com
Which is interesting, since I thought that interpreters were strictly against Apple rules?
https://developer.xamarin.com/guides/cross-platform/applicat...
"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 )."
This is my best guess of what's happening based on this article: https://arstechnica.com/information-technology/2017/05/xamar...
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.
You can make it more technically complicated.
The technology you used can not make that harder or easier.
"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...
Sadly, they went bankrupt, though not because of their app quality!
Here are some of the more visually appealing apps we've made with Xamarin:
Each example across multiple industries says whether they're using test cloud, or the app was developed with the platform :)
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.
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.
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...
(I'm the CTO there)
"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...
"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"
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)
* 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).
I work for Microsoft
It iOS vm or it is just deploys to your IPhone from windows?