Apple to ban Xamarin and Phone Gap Apps? (Updated)
We knew that Apple was looking to improve the quality of the app store by rejecting templated apps (auto generated, change name, colour, logo – here’s your app type stuff) but this tweet (screen shotted below) seems to suggest that Apple are also going after the cross platform / alternative language app frameworks such as Xamarin (now a Microsoft company) and Phonegap
For those that don’t know or understand this sort of thing, iOS apps are written in Objective C or Swift, Phonegap allows you to use Javascript and Xamarin allows you to use C# (or F#) which basically means a whole load more developers can jump into mobile app development with a familiar language. These frameworks also allow you to create Android and Windows Phone app versions from the same set of code (or near enough), so for a developer you get double the output – a good thing for productivity! There is an argument that this reduces the quality of the app (which Apple don’t want), and certainly with Phonegap (not my thing) you lose out on Native user interface elements which is a problem for the user experience, but with Xamarin you get native look, feel, and API calls so a very high quality product is achievable – certainly not an easy win.
Do I think this will happen? No, at time of posting this has come from one source only, and it seems very un-apple like to name names in an email without backing it up within their published guidelines and the developer community, and from memory the app factory clamp down was mentioned at WWDC last year. Not sure why someone would want to fabricate this (are twitter retweets that valuable?), but watch this space, it’s creating some interesting conversation if nothing else. Beyond all else, Unity uses mono (the engine beneath Xamarin), so Apple want to kick money making Unity games out?
Personally, making it easier to creative native feeling and native operating apps in an environment and with tooling I’m used to is a good thing, I don’t think Apple are that hard up that they need all iOS devs to be buying iMac Pros and living in Xcode – however if anyone wants to buy me one? 🙂 ……
Updated:
Being claimed as fake over at 9to5mac
A screenshot of an email being circulated around the internet in the last day supposedly revealed new strict app review policies. We have confirmed with sources that this email is not legitimate communication and does not reflect a real Apple policy decision.
You can read their diagnosis over at https://9to5mac.com/2017/…
You get what you pay for – Mobile App Security
You get what you pay for – App Security
Andy Flisher is a Software Developer based in the North East of England specialising in cross platform development. Mobile Development experience includes Windows Phone, Android, and iPhone Apps. Desktop Software Development includes bespoke Windows, Linux, and Mac Applications. Web Development Skills include PHP, Perl, Python, Xamarin, C#, ASP (Classic and .NET) – Andy Flisher on Google+
In the course of work this week I had a cause to audit an iOS App that a prospect had had developed by a local competitor here in the North East, the reasoning for this was that the prospective client was looking at moving the hosted back end (ASP .Net, SQL Server – standard stuff) and wanted a price.
The purpose of the audit was to check what network connections the app was making, and correlating with what I knew about the backend hosting, just to make sure there were no surprises, we didn’t have the source code for either end yet, it was just a pricing exercise at this point (As it happens the App is written using PhoneGap so we did have the source code, but my route was quicker).
So, I installed the app, redirected my iPhone through a proxy server, and fired up the app – and proceeded to stare in horror. The app instantly, on first run fired up an un-encrypted, un-authenticated connection to the backend host and promptly downloaded the usernames, password, emails, and more for every user in the system. It then keeps a copy of these locally, and uses those details to authenticate later.
Why is this bad, in laymans terms, because anyone, on the internet, who knew the url the app uses could download the same list. Would people be interested in logging in to this system? Probably not, do people use the same username and password for Amazon, Tesco, Online Banking – absolutely, and there’s the problem.
Solutions, well it’s about paranoia, but key areas;
- Authentication – Implement simple basic authentication so that the app logs in to the webservice it pulls the data from.
- Https – Implement and SSL connection, then at least all traffic too and fro is encrypted (important as Basic Authentication is over plain text, so without https it’s still sniffable)
- Change the login mechanism to completely remove the need to download all user info at all.
What’s really frustrating though, and actually makes the ‘You get what you pay for’ title of this post a misnomer, is this wasn’t a cheap solution. The client paid a very reasonable amount for this app and solution. This is the sort of thing we see, and sadly expect, when a ‘cheap’ solution is offered as a counter to ours. We’re not expensive, but not cheap, we do do things correctly though. It’s a classic case of the customer not knowing what they’re not getting, they trust, and assume that a professional job is being done, without really asking too many questions about why it’s cheap.
In this case no excuses though, I’ll not name anyone, and we’ve raised the issue with the client – We certainly won’t be taking on the hosting until it’s resolved!
Andy works for dotUK (www.dotuk.net) a North East Based Web and Software Development firm he helped found.