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.
Gartner has a new press release Top 10 Worldwide Mobile Phone Vendors Increased Sales in Second Quarter of 2016. Gartner says Apple has had three consecutive quarters of slowing demand and now has only 12.9% market share vs 86.2% for Android.
Probably more interesting for developers is that Windows has only 0.6% and Blackberry 0.1% market share and can probably be considered ‘dead’ with regard to financially viable app development.
Vision Mobile’s latest State of the Developer Nation Q3 2016 report is worth reading. It contains insights generated from 16,500+ developers, from 150 countries across mobile, desktop, cloud, IoT, augmented and virtual reality.
Of interest to mobile developers is that 47% of professional developers now consider Android their primary platform (vs 31% for iOS). Vision mobile says there have been a move away from monetisation via paid downloads, in app purchasing and advertising to apps that are business enablers. They also say there’s a shortage of talent familiar with Apple platforms to fill professional roles.
My personal view is that the huge Android market share has created pressure on iOS wielding (and hence Android averse) CEOs to take it more seriously. For every iOS-only app there has been the weight of Android end-users asking “Where’s the Android app?”. At last, mobile platforms are being considered as business tools rather than regions.
Canalys has a new press release where they say Smartphone shipments to grow 5% in 2016. This is despite the fact that Apple is expected to see its first annual decline.
It’s interesting that while most of the growth will be outside established markets, EMEA and North America will still see a slight growth.
We are now in a stable phase where iOS and Android market shares are likely to stay roughly as now. This provides some medium term stability for mobile app developers choosing their mobile platforms.
One of the first questions I usually get when people come to me to port apps is ‘How long will it take’? A very rough estimate is the same order of magnitude it took to develop the iOS (or Android version). Obviously, you will have probably re-designed and re-implemented parts as you developed for the first platform. If you take off some time for such re-work then this will give you a very rough idea of the effort required for a port. Yes, Android and iOS have their quirks, testing and app review respectively, that can conspire to complicate timescales but on average, iOS and Android apps take of the order of the same effort. The projects I have seen that have had vastly different timescales per platform has been mainly due to differing developers having totally different personal approaches to development.
When porting either way, discuss with your developer how the screens might be represented on all the target screen sizes and orientations. For example, you might need to remove features or restrict orientations in some circumstances. These days, iOS also needs to use adaptive layouts so don’t start demanding or expecting pixel perfect layouts as used to be the case. Thinking things through beforehand will enable more accurate effort/time estimates.
Your developer will need to analyse what parts of the app need to be ported line by line and which parts are better ported by examining the intent of the app. Complex business logic tends to need to be ported line by line while os-specific things need new code that follows the intent/behaviour of the donor app.
When porting from Android to iOS, I recommend you read the App Review Guidelines carefully, even if you have previously published an iOS app. The guidelines have changed over time. I seem to spend considerable amounts of time explaining things to product owners who ask me to do things that won’t pass review. However, it obviously saves a lot of time not trying things that won’t ever pass!
There are more tips and hints in my post on Porting iOS to Android.