Visionmobile has an interesting post Look Ma, No Apps, Just Messages where it’s said that there will be a move from apps to messaging. The “transition to a conversational paradigm” will be driven by Facebook.
I first read about this idea in UK Wired magazine but I am not so sure this will be the case. I see messaging apps are much like web (html) apps and notifications vs apps in that the limitations are such that they can’t be all things to all companies.
Take just one example. I am current working on apps for iBeacons. How will these integrate? Will the messaging apps detect beacons? Probably not. However, assuming they will, where will the rules lie of what to trigger on and what to show? Facebook or some other messaging platform provider can’t extend this far to be flexible enough. This is just one such example. Think about GPS, SMS, using the phonebook, sharing data, branding and analytics. How will these be integrated in custom ways? Then there’s availability, security, data privacy and service longetivity. As someone recently said to me, “if you don’t own it, you don’t control it”.
I can’t yet see messaging platforms replacing apps even with Facebook pushing in that direction.
It’s less than a month since I posted about being impressed with Parse and talked about it’s “presumed longer-term continuity through being owned by Facebook” and yesterday parse announced it is shutting down.
I have always been cautious about using BaaS in production apps due to unknown service levels, uncertain longer term continuity, privacy issues and security concerns. Just as BaaS was getting my trust, it lost it again. Remember, take care if you are using a backend service provider, whatever their pedigree.
However, all is not lost. The closing of parse.com has caused the server side to be open sourced. This now provides a new way of providing for an easier server side. You get most of the advantages of Parse (no server side development and easy to use app SDKs) without the uncertain longevity risks of using a BaaS provider. I also expect a few ‘hosted parse server’ providers might surface to make the installation and setup easier and ease migration for the 600,000 developers using parse.com.
When I created ActiveVault, one of the thoughts was to also try to protect Java code. However, whatever way I looked at it, it wasn’t possible. You can encrypt code but as soon as you decrypt and load the Java, it becomes visible in two ways:
The first is that, since ART and Android 4.4, it’s not possible to dynamically load (decrypted) Java code without it appearing in storage. Previously, with Dalvik, it was possible to dynamically load extra code to memory. For devices with the ART runtime, an OAT file containing the DEX file has to exist in the file store, in the dalvik-cache directory. This is world readable even on un-rooted, unmodified devices. The technical reason why the file has to be in storage is so that it can be paged out by the OS. There’s DexExtractor available to extract such files on the emulator.
The second, more involved way, that involves tampering with the OS, is via hooked functions. This is where attackers can intercept function calls to do extra things such as read files/data. Utilities such as DexHook and DexHunter (research paper pdf) can intercept the code as it is dynamically loaded.
Yes, there are some code protection utilities or packers that claim to encrypt code or classes. These do what they say, they encrypt code, but they are of not much use if the code is easily readable later on when processed by the OS. There’s no way to fully protect Java code. It can only be obfuscated.
If you are creating an app targeting my home country, the UK, then there has very recently been a surplus of stats. Deloitte have a press release saying Britons collectively check their smartphones 1.1 billion times a day.
More than 32 million smartphones will be shipped in the UK in 2015; one for every other person in Britain. Over a third (36%) of smartphone owners look at their device more than 25 times a day. What’s new? Well, mobile payments are increasing.
Meanwhile, 34sp has a new UK Mobile Usage Study (pdf) based on a survey of 1000 people. 30% of respondents said their mobile phone is the main device they use to access the Internet. 1 in 4 of said their mobile is the main device they use to read the news.
What’s new? 20% say they have argued with friends for being distracted by their mobile phone. 25% admitted to having argued with a partner over checking their phone. It seems that ‘social’ is actually making us less social.
Appindex, the app development marketplace and organisers of the app promotion summit have an interview with me where I talk about my involvement in mobile development, the types of apps I have worked on, tools I use, what app I have been most proud of, trends in mobile development and my current views on mobile development.
Appindex also previously kindly listed me in their Top UK App Developer Agencies.
Last week I highlighted how, with in-app purchases, 1.14% of paying customers generate 30% of the sales. This links in well with a recent report by Flurry on Mobile Addicts. These are super users that use apps between 16 and 60 times daily. Flurry has worked out that this class of user has grown by 34% over the last year…
This group of users isn’t necessarily that small. Flurry says…
“If the number of Mobile Addicts there were in 2014 had been the population of a country, such country would have been the 8th largest in the world last year, slightly below Nigeria. In 2015, the growth of the Mobile Addicts population would have propelled that country to the 4th spot, just below the United States”
Here’s what these people are actually doing…
What does this mean for 3rd party developers? First, I think it vindicates the use of ‘Messaging & Social’ if it works within your kind of app. It also shows that there’s plenty of opportunity in ‘Utilities & Productivity’.
As well as thinking about short term retention, think about longer term users. Try to design your app to also help your best and longest users. How? For example, let them save things, let them see what they have done in the past, allow searching when data gets larger, allow old or unwanted data to be purged to save space. Reward your longer term users with things like larger quotas or extra features. Over time, migrate their existing data as the app gets updated. Allow them to backup data so they can use the app when they upgrade their smartphone. Think longer term.
In the past I have mentioned the need to be careful about using WebViews in apps, particularly apps that are security sensitive. The number and complexity of WebView vulnerabilities are such that a pragmatic approach might be to not use WebViews in security sensitive apps. Recent news has shown that the same vulnerabilities can be a security problem for the Chrome web browser app itself.
If you have been following the IT news, particularly the security news, you will know that the Italian spyware company Hacking Team recently got hacked themselves and their source code was posted on the Internet.
It turns out they developed an Android ‘remote2local‘ exploit that cleverly combines three known Chrome vulnerabilities and the root-enabling put_user or TowelRoot vulnerabilities to allow pre-defined code to be executed as root from the user simply clicking on a link in the browser. The details are on the Tancent blog (Google translated).
How bad is this? The Hacking Team have a compatibility file that says it covers Android 4.0 to 4.3 and lists some tested devices…
One of the vulnerabilities, CVE-2012-2825 Arbitrary memory read, was fixed in June 2012 and another, CVE-2012-2871 Heap-buffer-overflow was fixed in August 2012 so end users allowing Chrome and WebView to update via the Play Store will have had these vulnerabilities fixed a long time ago.
However, this demonstrates how vulnerabilities can be combined to run code as root without the user even knowing. The Hacking Team compatibility file and subsequent vulnerability fixes show that in some ways, Android’s fragmentation aids security. It’s difficult for exploits to cover all types of Android OS and device and they usually only work on smaller subset of devices. As I previously mentioned, this won’t be much consolation to large companies with thousands of employees or customers which greatly factor up the chances of encountering exploits that might end up accessing sensitive company information.
Localytics have new research that shows that in-app messages drive 3.5X higher user retention. But, as Localytics say…
“Many app owners wonder how to create content that isn’t viewed as spam and doesn’t detract from the user experience.”
The problem is that unless the message is event/content triggered and is useful to the user then the notification is likely to be seen as an annoyance. For example, as some developers do, reminding the user about some feature of the app that isn’t pertinent to specific new content in the app is likely to be viewed unfavourably. If your app isn’t event/content driven then in most cases I’d avoid notifications as it’s harder to justify their use.
Localytics also have some recommendations for you to consider to help drive use of notifications…
- Get the user to opt in (rather than have to opt out)
- Provide personalised recommendations (rather than serving them with everything)
- Provide notifications for upgrade or achievement notifications
- Get users to share app content (I am less sure this is a good idea)
- Provide app quick tips (I personally think this will annoy all but the most ardent fans of your app who will probably already know about the feature anyway)
You might also consider filtering notifications based on what content the user has previously viewed or what they have favorited/saved. Whatever you do, provide the option in the app for the user to turn off notifications otherwise some people might uninstall the app instead.