One of the main things pointed out during this year’s Flutter Engage was the ability to build your app to one of six platforms: iOS, Android, Mac, Windows, Linux and web. That’s awesome news! But…
I massively agree with this article, just because you can write once, and deploy to many – doesn’t mean you should.
I approach this from a Xamarin / Xamarin Forms perspective, I haven’t dabbled in Flutter as it doesn’t solve a problem for me, but the same rings true. An app written using Xamarin Frameworks (C# / .Net) can be run and deployed on the Mac (Arm and Intel), Windows, Linux, iOS (Including Watches and Apple TV’s), Android, the Web, Tizen and probably a few more I’m forgetting – it absolutley doesn’t mean you should.
Platform users have different expectations, be it UI, layout, actions and responses (eg swipe to delete from a list in iOS vs press and hold in Android), different platforms have different input mechanisms (touch vs mouse), output standards (Watch screen vs 65″ TV Panel) all change how you the developer need to consider the app, the presentation, the user experience – it’s just not possible for one code base to achieve all of the above, without work from you.
For example, with Xamarin I can make a decision to use Xamarin Native (specific iOS and Android projects, seperate code and UI bases but maybe some shared underlying central code – eg data layers, low level stuff) or Xamarin Forms (Single code base, single UI base). The latter allows me to override, or do platform specific customisations, but at what point do all those exceptions become less efficient than developing seperately. Good development decisions need to be made, and that comes from experience and working with your client.
Still, the premise runs true, just because you can write once, and deploy to many – doesn’t mean you should.
Andy Flisher is a Mobile App Developer based in the North East of England with over 20 years software development experience. He is available for hire and specialises in cross platform mobile app development, web applications, desktop software, bespoke cloud architecture solutions and providing outsourced project management services.
Yesterday at the Microsoft Build conference they announced MAUI, the roadmap to their new cross platform software, single codebase framework, quoting from their release;
As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS. To address this need we are excited to announce a new first-class UI framework for doing just that: .NET Multi-platform App UI, affectionately call .NET MAUI.
This means a lot to us as developers, but what does it mean to you as business owners, decision makers, and end users? To your business?
App languages – how they differ
All computer software (apps are just software applications, all the same really) is traditionally designed to run on it’s intended platform, the Web, Windows PC, Apple Mac, iPhone, Android etc – an app written for one platform will traditionally be written in the language that platform expects, all these platforms have different native languages, ie an app written for one won’t work on another.
In layman’s terms, if you learn French it will stand you in great stead on a holiday to France, but pop next door to Spain and you’re stuck. Unless you learn Spanish too, but that’s twice as much work.
Multiple App Platforms
Which is where us developers come in, most developers speak more than one language, but certainly not all, and in the past you had to be careful that the language choice the developer was making for your project was because it was the right one for your needs. Not because it was the one they knew. But as IT expanded, people started using their own devices, and mobile computing became the norm it stopped being about which platform – Mac vs PC if you will, but which platforms – plural.
So if you ask a developer to create you a mobile app you are probably targeting iPhone and Android, two platforms, two languages (Objective C or Swift, and Java in case you were wondering!) – so that’s actually two apps you need, twice the work, twice the support, twice the cost!!! If only there were some (good – there are bad ways, we don’t do them) way of creating good, native, performant apps on both platforms, from one codebase, one product to support, and only one to pay for – cheaper is better right?
How can Xyroh help?
Well for most cases there is, it’s niche, here at Xyroh we do it, and have spent a lot of time and resources investing in these skills, the platform we use is Xamarin from Microsoft, and in *most* cases, certainly B2B projects it’s perfect – outputting great, custom mobile apps for iPhone, Android, Windows Phone – Tizen even – at good value to your business.
Well that’s what this announcement was about, the next stage. Microsoft’s new MAUI framework will allow us to create line of business apps that run on;
– iOS (iPhone and iPad)
– Mac OS
All from one project, one codebase, one cost – but much more value. So if you have a need for apps, be it a mobile app, a desktop app, or even a web app in your business then we’d love to talk to you.
Andy, the founder of Xyroh, is a mobile app developer, specialising in cross platform mobile apps, iphone apps, android apps, as well as web applications and desktop software for business clients across the North East – feel free to contact him to engage his services
This is a review of the recently published book “Xamarin Cross Platform Application Development” by Jonathan Peppers.
This book is openly marketed at existing, experienced C# developers so it’s certainly not for beginners, and whilst I don’t fall into this category the nature of projects I work in require mostly ‘linear’ development (Web, PHP, Perl, Python, VB etc over the years) so concepts like MVC, MVVM and in particular IOC (Inversion of Control) are newer and less clear. Thankfully this book has resolved that through it’s excellent practical examples.
One area this book doesn’t touch on hugely is the level of planning required for MVC applications, you can’t just ‘jump in and code’, but that’s potentially a book in itself, but what the book does very well for me, is explain the View, ViewModel, Model and Controller concepts in terms of the classes and data layers required. The book also introduces Interfaces (something I always saw as an unnecessary layer of complexity) which I now ‘get’ in terms of flexibility, and in particular to give the developer options in a cross platform environment.
The icing on the cake is ‘Inversion of Control’, whilst the book doesn’t particularly explain this convention in huge detail, I think it is actually to it’s credit, any more and the reader will be bogged down in unnecessary detail and complexity. It basically gives us the service layer that ‘glues’ the application together, allowing use to create and register our ViewModels as Services and thus make them available to use throughout the app with a single line of code. I’m sure that my description is not hugely more constructive than the words in the book themselves, but the working example of the XamChat application completes it.
Which is my main point, am sure many people work differently, but for me working examples of code are what makes it stick in my mind, it helps it all make sense. Throughout this book you will be building bit buy bit a working chat application, firstly in Xamarin.iOS (but using the all important cross platform and code sharing concepts learnt at the beginning of the book), and then re-implementing the same application logic in Xamarin.Android. The nice touch, which some may see as lazy, was that with the Android example you are taken to a certain point and then left to finish off using the examples you already have. A real, and practical exercise which I think will do the reader good. It wouldn’t be a huge leap further to recreate in Windows Phone, for the ultimate practical extension.
The Xamchat application is then extended through the Windows Azure platform to use their backend for data storage (a good example of how the same Interface can be re-used to store on different platforms), and to implement cross platform push notifications.
Lastly there are chapters on using Xamarin Components (including Xamarin.Mobile for Contacts, Camera and Location functionality), and actual App Store submission and their different processes, processes that even the most experienced developer can struggle with (Apple Certificates and Profile expiry anyone!).
In summary, this is an excellent book for any would be cross platform mobile application developer, yes you need a good understanding of C#, MVC and similar concepts, and the individual mobile platforms and general development processes themselves, and those things don’t come over night, but this book binds it all together with real world examples, working code (a novelty for some books) and actual code and methods you can take away and use in the real world.
Buy it, read it, and take as much as you can from it – “Xamarin Cross Platform Application Development” by Jonathan Peppers
Prior to Xyroh, Andy was the founder of dotUK (A software development firm based out of Yarm and Stockton on Tees here in the North East), again specialising as a developer in mobile apps, web applications and desktop software for a number of business clients – this is one of those portfolio case studies
Art Screen Prints based in Guisborough here in the North East specialise in producing print based fund raising merchandise for schools, clubs and other associations. One such product is ceramic mugs printed with the pupils drawing. In order to best represent the potential end product the need to produce Parental Order Forms (POF’s) that are personalised with the pupil’s details, and as close as possible to a final representation of the Mug printed with the pupils drawing. We would also need, within the same workflow, to print the final print ready templates in PDF format for use in the printing process,
Client Art Screen Prints – Guisborough based School and Fundraising Print
Platforms Apple Mac, Windows
Technologies C#, Mono, GTK+, .Net, ImageMagick
Development Desktop Software, Mac Software, Windows Software, Cross Platform Software
One of the unique requirements of this software development was the fact that the client used a mixture of both Apple Macs, and Windows based PC’s and as such this tool would potentially need to run, in the same manner, across both platforms.
The workflow is in essence two fold, presented with a folder of pre-scanned images (grouped by Class, or other equivalent organisational hierarchy), the desktop application we developed would need to take this feed of images, process them, and generate one, or both of;
- Print Ready, PDF Formatted print template for the actual scaled image to appear on the Mug
- A Parental Order Form to be distributed to the schools representing a final printed mug as closely as possible.
To do this we built the application utilising the Mono framework (a Cross platform representation of the C# language that allows applications to be built from a single codebase under Windows, Mac, and Linux). However as this was a desktop application and we had to consider the User Interface (UI) it was also necessary to make a decision on the UI framework. In the end we settled on GTK as the best performing, simplest, multi platform graphical interface framework, for what was as an interface quite simple.
The application itself was mostly a wrapper around pre-generated ImageMagick (A cross platform software suite for manipulating images programmatically) commands that we built to create both the print template, and the POF. Particularly challenging was the need to take a flat two dimensional image, and create the effect of wrapping and warping the image ‘around’ the Mug so as to represent what the human eye would see in the flesh.
In addition, owing to the batch processing and time it would take, we had to ensure to user asynchronous event based programming within the apps interface to ensure that a consistent update on progress was fed back to the user, without the application timing out, or ceasing to respond as it would with lengthy synchronous waits.
Thanks to our success the project grew to encompass a sister project for the generation of Calendar templates, and associated order forms.