Does Xamarin owe its existence to Unity & Apple?

Yes, Xamarin owes its existence to two other bits of technology that were huge around 2008 - the Unity Game Engine and the iPhone. The reason is that a confluence of events around 2008 provided the push to get the Mono project into mobile app development. This resulted in MonoTouch (for iOS) and Mono for Android, which eventually became Xamarin as we know it today.

The Mono project was founded in 2001 as a free open source implementation of Microsoft's .NET framework on Linux. But Mono had struggled since its inception to find its reason for being. According to Mono's founder, Miguel De Icaza, the hardcore free open source community never fully got behind Mono. The FOSS community feared that Microsoft would eventually cause problems for Mono, due to Microsoft being the creator of .NET. 

Outside of the Linux world however were other more pragmatic people from the MacOSX world who had no problem with Mono. One of these people was Joachim Ante, from Unity. Around 2005 the Unity game engine was just starting out and had a performance problem - their original scripting language of Python was far too slow - they needed something that was an order of magnitude faster. So Unity decided to replace the Python scripting with Mono/C# and immediately got all the performance they needed. This was the early days when the Unity Game Engine ran on MacOSX only. Mono filled the need of being a free open source JIT compiler with the modern language of C#.

Fast forward to 2008 when the iPhone App Store launched; Unity quickly set their sights on being able to compile games for the iPhone. Unity wanted to use Mono, but the additional requirement was that it had to be statically compiled for iOS, because Apple had banned the use of JIT (Just In Time) compilers in iOS Apps.

Unity comes back to us and says “Hey, we have this product on iOS, we need .NET to be statically compiled. Can you do that?” We were like, “Oh, that’s kind of impossible. Well, let’s think about it.”

One of our guys, Zoltán Varga - they went and made a static compiler for .NET, and it was amazing. We gave it to Unity. At this point, Unity is probably four or five employees.
    
They were working at somebody’s garage. And they shipped their product for iOS, built games for iOS using this thing, this 3D tech. They were the kings of this space.
    
- Miguel De Icaza (Xamarin)

Within a year of the iPhone App Store launch, Unity went from 4-5 employees to 80 employees. The iPhone and the App Store had launched Unity's massive growth, and along with this the Mono project had finally found its reason for being - mobile apps. The Mono developers realised there was interest in using .NET for mobile apps - so using the same tech given to Unity, they built their own product - MonoTouch, which allowed developers build native iOS apps using C#. Soon afterward, Mono turned its attention to Android and created Mono for Android.

Mobile app development was new and there were many developers who wanted to get into mobile apps but didn't really want to have to learn Objective-C and Java. So Mono now had a C# based cross platform app development platform with truly native performance. This was the killer combination that ensured Mono would take off in popularity.

The developers behind Mono founded the Xamarin company in 2011, MonoTouch became Xamarin.iOS and Mono for Android became Xamarin.Android. Xamarin was acquired by Microsoft in February 2016 and became a subsidiary of Microsoft, fully focused on the development of Xamarin's open source projects.

Inspiration for this article:

The History of GNOME, Mono, and Xamarin
https://changelog.com/podcast/275

Follow @dodgy_coder on Twitter

Inactive/Failing Mobile Apps: The Many Benefits of Regular App Updates

This article applies mainly to mobile apps which are not in active development. It applies equally to mobile apps on the public app stores and also to enterprise mobile apps which get distributed via other means (such as MDM software).

Example scenario of an inactive/failing app:

• The active marketing of your app that happened at launch has now stopped
• Your app's last update was several months ago
• The uninstallation rate has started rising above your installation rate month on month

A way to prevent this happening is to release regular app updates, even when there are no major changes to your app's code.


Benefits of releasing regular app updates:

• Gain new users; many users look at the last release date on the app store page before downloading your app. Anything over a year old can be immediately rejected as out of date.
• Prevent uninstalls; seeing your app has been updated on their phone keeps it in the user's mindshare, so they know you are still actively developing it.
• Update the dependencies; you will likely have several dependencies on open source libraries and mobile SDKs. The more often you release, the more often these can be updated too.
• Update the toolchain; Xcode / Android Studio / Visual Studio get updated once every month or two. Same applies to hybrid and cross platform toolchains such as Unity, Ionic and Xamarin.
• Update the store listing; since you're doing a build, take the opportunity to review and tweak the store listing and screenshots. Apple's App Store Connect website and Android's Google Play Console get updated regularly with enhancements you can take advantage of.
• Less build issues; there will be a lower chance of a major build issue if you regularly update your toolchain and its dependencies. In my experience, the longer you wait between app builds and releases, the greater the chance of a major build issue the next time.
• Source control change visibility; the project is kept active in terms of source control history; especially relevant if its an open source project with other potential developers able to see the change history on github or bitbucket.
• Developer benefits; you don't end up with a legacy mobile app that noone can get building anymore.

What if there are no significant changes to your code?

• Have the dependencies or toolchain been updated? If yes, that means your app has gained some potential bug fixes and enhancements for free - just by doing a build.
• There's always some minor refactoring you can do to make small improvements to your codebase. Just spend a couple of hours if that's all you can spare.
• The release note; just use the standard "Bug fixes, performance and stability improvements" if you can't think of anything else.

How often to release?

• The more often the better.
• Aim for a regular release cycle of between 1-3 months.

Further reading

Distribution of Android apps per download range
https://www.statista.com/statistics/269884/android-app-downloads/

Download distribution of Android apps, and lifetime growth rates per download range
https://www.appbrain.com/stats/android-app-downloads

Statistics about the release schedule of apps on the Apple app store
https://stories.appbot.co/how-often-should-you-update-your-app-9405b85a967c

Best practices for Apple app store updates
https://developer.apple.com/app-store/app-updates/


Follow @dodgy_coder

Subscribe to posts via RSS