There’s a thought provoking piece by James Bourne at AppsTechNews on how Mobility investments are moving more towards the business. The article is based on CCS Insight’s enterprise IT buyers survey:
“Enterprises may well balk at the thought of deploying thousands of iPhones to the organisation – McQuire argues that Apple will begin to see its grip on the enterprise mobile market loosened in 2017”
“Banks are pushing ahead with Android and could form a ‘big change’ for the operating system’s overall perception. You’ve [also] got the broader use case for Android, whether that’s field service, rugged, kiosking…these environments where Android is actually quite successful. Those are some of the areas where Apple just doesn’t play.”
I have always seen Android as a much more capable OS. In the past, this has led me to work on widely varying Android projects that use the OS as a self-service kiosk in hotels, an insurance video recording device in cars and a medical instrument used by consultant Optometrists. What with Android Things, the scope of Android projects can only get wider.
CSS Insight has a new article on The iOS and Android Duopoly and asks if there will ever be a third platform:
“Many mobile platforms have come and gone during the past decade, some created by start-ups and others by some of the world’s largest technology companies. Mobile platform projects such as Firefox OS, LiMo, Jolla, Maemo, MeeGo, Tizen, Sailfish, Ubuntu, WebOS and Windows 10 Mobile have had little impact on the market.”
The conclusion is that the chances of a new mobile platform succeeding aren’t good. Instead, it’s the services on top such as artificial assistants that will alter behaviour.
This is good news for mobile developers and those companies creating apps. After two decades of uncertainty, we can now develop for Android and iOS in the knowledge that the two main mobile platforms are not likely to change in the next decade. However, we need to remain alert to new mobile platform APIs provided by the ‘artificial assistants’ as these might increasingly be the chosen way to interact with apps and services.
It’s taken a long time, but we have finally reached the stage where a significant number of companies are looking for Android to iOS porting. There was a time when most development was iOS only, followed by a time where there was significant porting from iOS to Android. After this, there followed a period of enquiries for work on Android AND iOS. Now, finally we are seeing Android being ported to iOS.
The main problem with Android to iOS ports is that Android allows you to do so much more. More specifically, there are lots of things you can do on Android AND iOS, but the Apple Store T&Cs tie down what’s allowed. There’s even been an Android to iOS porting project this week that I wasn’t able to quote on because I knew two main features were not possible. Therein lies the problem starting with Android and porting to iOS.
MobiForge has an interesting post on how Android seemingly grew at the expense of iOS last year.
What makes this data particularly useful is the fact that it’s based on web traffic, not device sales. It’s the closest we can get to determining changing mobile OS use based on the installed base rather than new device sales.
At one time it was said that Android would grow due to market saturation in developed markets and takeup of Android in other countries. However, looking at the numbers, even the developed countries are losing iOS and gaining Android.
It remains to be seen if this is due to people becoming disappointed with new Apple products or whether it’s just a ‘blip’ caused by something else such as Apple’s device release dates.
I am always interested in iOS <-> Android code converters as they might make my job easier or even put me out of business! As yet, the problem has proven too complex to automate.
I just learnt about MechDome, a new converter that allows you to automatically convert from Android to iOS. It doesn’t even need your source code as it can decompile this from your apk install file. It produces native code with native UI controls.
However, once I started digging deeper I saw the limitations. The Android app must be Android 5.1 or later, not use Google Play Services (e.g. mapping) and not use JNI (c, c++). Unfortunately, just about every project I have worked on or I am currently working on doesn’t fit these requirements. Let’s hope MechDome becomes more flexible with time.
Also, most people tend to be looking at going from iOS to Android as they initially chase the money and then realise they need to go for reach.
About 2 years ago I wrote about the MyAppConverter Objective c to Java and vice versa code converter. At the time I observed that the project was ambitious and questioned whether it was viable:
iOS Android Native App Conversion
The team have gone through what they are calling a ‘product market fit’ phase, and have decided to focus their effort on the native iOS UI to native Android UI porting.
The free alpha version is an online tool that quickly turns common UI components into native Android Java. A beta version will support 100% of all iOS UI components. You upload your Storyboard and xib file and download the native Android UI project that provides a skeleton app to kick-start porting your iOS app to Android.
More details can be found on the MyAppConverter blog.
IDC has new research on smartphone sales that, similar to Gartner, shows Android share at 85.3% and iOS at 13.9%. More significantly, IDC don’t expect the market share to change much up to 2020.
I personally don’t think the market shares will change much over that period. However, there could be outside influences such as mobile operating system security scares, Brexit fallout (at least in the UK) or corporate tax politics that could change peoples’ perception or affect pricing and hence purchasing significantly.
There’s a thought-provoking post on GeekTillItHurts on how Android 7.0 Nougat can be run on the Raspberry Pi 3. This offers new opportunities for entrepreneurs and developers to implement more single board computer (SBC) embedded type applications.
Using Android on SBCs isn’t new. I have worked on a few such projects that have re-purposed media Android TV devices to do more specialised things. It’s very easy to program Android rather than c++ or c and you get much better productivity. It also allows more complex applications to be implemented quicker. In two cases I ended up doing image processing on SBCs that would have been much more difficult, if not impossible, had I not had Android’s hardware accelerated drawing APIs.
These boards often run ‘headless’ without a UI or with a minimal admin UI. In these cases, you need some central event processing for communication between the various modules. I have found using Green Robot’s EventBus simplifies communication between threads, services and the minimal UI if you have one.