That’s 5 million in one quarter. Certainly over 20 million over the next year. Suddenly, wearables seem to have more traction than I had envisaged. Wearables are bigger than I thought – in more ways than one.
Arxan has a free State of Mobile App Security research report (pdf) that claims a very large proportion of the top paid/popular Android and iOS apps have been hacked. Hacked apps either have IP stolen that’s used in other apps, have clones created or the apps are modified to remove payment mechanisms.
One of the problems of mobile development is that it’s a human resource driven activity that’s expensive. Multiply that by iOS and Android and the costs double (or more). Wouldn’t it be good if you could develop on Android or iOS and a tool could automatically generate for the other platform? Well, MyAppConvertor has that ambition. Really. This isn’t some limited, poor html-based or intermediate language-based ambition. It’s the real thing – Objective c to Java and vice versa.
MyAppConverter is currently in beta and is limited to online conversions via their web site. It only works for games, only converts from iOS 7.1 to Android 4.4.2 and only on Samsung Galaxy S5. However, the aim is to eventually support IDE-based conversions, for all types of app, to and from all major mobile platforms and versions of those platforms.
The presentation outlines their approach based on models and meta models to not only directly map code but to also do it in such a way that creates the right algorithmic and UI idioms/patterns on the respective devices. While the converter can create source code for completion by a developer, they are aiming for 100% conversion so that anyone can use the tool. Anything less is much less useful as it then needs a developer and the ‘extra stuff’ the developer adds needs to be somehow added every time there’s a new version of the app which would get difficult to manage.
This isn’t just about mapping APIs which is complex in itself. It’s also about knowing all the nuances of the APIs that are documented in places like stackoverflow. It’s also about mapping idioms and patterns of doing things, somehow mapping 3rd party libraries, knowing fragmented differences between (target) devices and knowing differences in APIs across OS versions. Even then, it won’t cover apps that use ‘real native’ c/c++ NDK code – previously estimated by Intel to be of the order of 25%. Once all this is solved, consideration has to be given to keeping all this up to date into the future. APIs can become deprecated over time and new API’s are created. For example, in Android Lollipop there are over 5000 new API’s. New devices will also become available with new nuances.
I don’t think what they are trying to achieve is possible in a reasonable time and/or with a reasonable team size. The World really needs tools like MyAppConverter. I sincerely hope they prove me wrong.
If I am wrong and the tool comes to fruition then there are some interesting possibilities MyAppConverter might not have considered. It might be possible to create a new tool to create apps by visually (or otherwise) building up the pre-existing meta models. These meta models, together with some kind of configuration data (the static, unchanging data in an app), would then be able to auto generate to multiple platforms with no actual developer coding thus putting developers such as myself out of business. Lay people, capable of wiring things together, could create complex apps.
There’s a thought-provoking article and discussion at Intercom on "The End of Apps As We Know Them". The premise is that we will use apps directly less and less and instead interact with rich notifications or cards.
While I can see some notification-rich apps might work this way, I am less convinced that the majority of apps will end up working that way. Most apps do too much to be shoehorned into a notification style app. Also, people are more used to invoking apps via icons and I can’t see that going away. I think cards/notifications are great for end user consumption but not end user content creation. If the majority of apps were to use this paradigm then the user would become overwhelmed with notification overload.
Gartner has new research that compares sales of PCs, tablets and smartphones across the respective operating systems. The headline is that tablet sales are slowing. However, does it matter?
The ever insightful Benedict Evans also has a new post where he explains that we are in the uncharted territory where a minority market share is still very large. He talks of the potential fallacy of "winner (platform) takes all" and suggests that we should look at other things such as the geographic region we are targeting.
Benedict talks a lot about developer revenues and geographic region when choosing a ‘mobile first’ platform and concludes…
"It isn’t so much that ‘maket share doesn’t matter’ (the mantra of Apple fans for decades’) as that you need to think about what kind of market share, where, and whether that matters."
I’d advise you to think and analyse even deeper. I find the emphasis on app revenues and market share slightly concerning. People should be think more about the benefit to their company. This benefit can take many forms. Whether an app is financially viable depends on the kind of app/company as much as it does the platform.
Taking Benedict’s examples of Citibank, Tesco and Carrefour they don’t even sell their apps nor use store in-app purchasing. The fact that iOS users are more affluent probably doesn’t matter for Tesco and Carrefour as iOS customers might be shopping at, at least in the UK, John Lewis and Waitrose anyway. Conversely, I very much doubt many Citibank customers use Android and they would prefer iOS. The key thing here is that these are hunches and guesses.
You need to assess what platform to use on a case-by-case basis and do some market research beforehand as to what devices your users are using and whether they would access your product/service via an app, smartphone, tablet or indeed anything else.
Back to the Gartner headline that tablet sales are slowing. Does it matter? Sales are still of a similar order to PCs and it’s still a large market. What’s probably just as important is whether your end users would access via a tablet and if so, what kind of tablet are they using?
Branchfire have a new US mobile app study of 2,042 adults, conducted by by Harris Poll on app-buying habits. 76% of people download apps while 57% have never paid for an app. 70% of people have downloaded more than 10 apps. The study also gives useful information on highest amounts paid for apps, monthly app subscription by category and subscription pricing thresholds.
It’s interesting that people are open to subscriptions as this gives longer term revenue for developers. The study says that streaming and movies are the top types of app people are willing to pay for via a subscription. These are the kind of things that can exist and be consumed outside of the phone and be accessible via other means, for example the desktop. The app is just a gateway to consumption (and payment). The value is seen as the content rather than the app. This is probably a good indicator of whether it’s viable to use app subscription in a particular app.
- Onerous fees charged by Apple
- Inferior technology
- Little incentive for merchants to adopt Apple Pay-compatible devices
More reasons then, why Apple should open up NFC before interested parties develop alternative solutions.
Looking wider, this provides learnings for any new venture. Are the fees you expect to charge reasonable in the current (and future market), can people easily circumvent your solution using other technologies and are you expecting too much of third parties to change/update their systems in order to be part of your solution? I suppose it’s really about having an old fashioned business model which is one of the stages of my primer.
I have previously written (here, here, here, and here) about Android apps that fail to validate SSL certificates. CERT has started to name and shame libraries and apps that their Tapioca tool has detected to be vulnerable to Man In The Middle (MITM) SSL attacks. There’s a blog post on how they have automated the analysis, a vulnerability note explaining the problem and a large spreadsheet of vulnerable libraries and apps.
Libraries that have been found to be vulnerable are Flurry, Chartboost, Adcolony, MoMinis, Inmobi, Tapjoy, Appsflyer, Gameloft, Zopim, Fiksu and Batch of which only the first two, Flurry and Chartboost are noted as fixed.
CERT are testing one app at a time so progress is slow. Nevertheless, over 1000 apps are listed as having failed. However, some of these failed because of the included vulnerable libraries.
If you think this is just an Android specific problem then you might like to consider that Veracode previously found 7% of Android apps and 33% of iOS apps had cryptographic problems. Developers can be inexperienced or lazy on both platforms.