Beacon Demonstrator App

beaconzoneI recently wrote about how many articles on iBeacons and Eddystone obscure or confuse what beacons actually are due to over emphasis of the (retail) business benefits or description of proprietary server side CMS features. I also mentioned I had written some articles explaining the basic concepts.

Following on from this I have created some simple Android and iOS apps for BeaconZone that demonstrate beacon triggering. The apps work with any iBeacons and allow you to set up triggering within the app itself rather than via a web-based CMS. The triggering settings can be shared, via a common ‘group name’ across phones and even across iOS and Android. If fact, it’s easier to set up on Android as you can detect any beacons but on iOS you can only detect predeclared ones. Hence, it’s easier to set up on Android and sync the trigger data with iOS. Both iOS and Android apps also trigger on beacons when the app isn’t running.

It has been a while since I last developed for iOS. As it happens, getting back into iOS development prompted an existing client to ask me to write an iPhone app for them. So it seems I am back into iOS development for a little while. I have been writing predominantly in Swift which I am enjoying but the change in syntax over time has broken many online code samples. I haven’t ever come across a language that breaks the old syntax over time. It’s very strange because languages are usually forward compatible in that old code never breaks but just becomes deprecated. The iOS app review process is still as onerous as ever and is particularly troublesome for iBeacon development. It took four times as long to get the Beacon Demonstrator app reviewed as it did to write it. However code signing, uploading and sharing beta versions is much easier than it used to be in the early days. Regarding newer iOS features, someone was having a bad day (or a joke) when they added auto layout to iOS, especially the Xcode tooling which is unintuitive and frustrating until you know the quirks. Apple should have taken some time to look at Android Studio.

The beacon ecosystem is maturing what with companies such as Estimote getting substantial funding and Nokia funding Sensoro. However, beacons are still only mainly being used in retail and visitor spaces. I believe they can do a lot more. The link between Bluetooth Beacons, IoT and sensors provides some opportunities and is an area I will be exploring further.

TrendForce Smartphone Research

trendforceTrendForce has new research that shows that Samsung smartphone shipments are in decline while Chinese OEMs are making larger market share gains…


What does this mean for developers? While Samsung is still very strong, over time we will have to broaden our device testing portfolio to include more of the long tail of devices. The good news is that such devices will be less expensive than the high end Samsung devices we have been used to having to purchase in the past.

Security Vulnerabilities Through Depending on 3rd Party Code

trendmicroTrend Micro has an article titled High-Profile Mobile Apps At Risk Due to Three-Year-Old Vulnerability. The problem has come about due to a vulnerability in libupnp that allows a buffer overrun to run arbitrary code on an affected device that can give the attacker the ability to take control of the device.

For Android, the architecture of Java is such that it is immune to buffer overflow problems. However, c/c++ written using the NDK can be vulnerable.

This shows iOS and Android developers need to be more careful when including 3rd party libraries that use c/c++. Being careful means keeping an eye out for security fixes in included c/c++ libraries and updating apps accordingly.

Counterpoint on Phone Shipments

counterpointCounterpoint has a new infographic based on data from their latest Mobile Market Monitor report showing mobile handset and smartphone shipments. The report covers over 75 OEMs globally. Global phone shipments grew 4% annually. Three in four mobile phone shipped globally is smartphone.

The following chart is for smartphones and shows which OEMs and, by inference, what platforms are most popular in the various geographic regions…


Android Permission Complications

I previously wrote about the new Android M Permissions scheme and how, while more transparent permissions is good for everyone, they introduce a lot of complications. These complications are yet another example of something that developers usually know a lot about but their product managers and some designers won’t know how to resolve. This leads to lots of trouble agreeing/deciding how screens and messages should look and feel, especially when developers aren’t included in the pre-development stages of a project.

There’s discussion that even top apps might be avoiding the move to targeting Marshmallow so as to avoid the complications. I have one such client project where I did some small changes that involved fixing on M devices but I didn’t have the time budget to go through the new permissions implications with my client. Hence the app stayed targeting Lollipop. I have another client who isn’t interested in M at all until it is seeing a greater uptake on devices. I suspect these scenarios are typical at the moment. However, most apps will one day have to ‘bite the bullet’.

This week’s Android Dev summit, particularly day 1, has some great recommendations on to how to handle the new permissions scheme. However, the real problems are with edge cases that can seriously bazooka your app. The first was an Android Dev summit audience question and involves what happens if the user taps “Don’t ask again” and the user then has to go to App… Settings to fix the problem, The Android team said that if this happens, you have lost the trust of your user and that’s that. However, Manideep Polireddi has some thoughts on how you might recover from this situation. Another edge case is if the user does “Reset app preferences” as explained by the CommonsBlogs.

Stepping back, is all this worth it? What is this all about? There’s a very recent article on the Forrester blog where it says…

“Consumers are more willing than ever to walk away from your business if you fail to protect their data and privacy”

Some might say that this is something for older users and that younger millenials have a different attitude to privacy. However, the Forrester research shows this isn’t true…

forresterprivacy Forrester says that privacy concerns are very much alive and are set to be a competitive differentiator in years to come. For apps, this means that those that do it well will be rewarded with better user retention.

Insights for Mobile Developers from Ericsson’s Mobility Report

ericssonlogoEricsson has a new free Mobility Report (pdf). Ericsson expect smartphone subscriptions to achieve 10% compound annual growth between now and 2021 while mobile data traffic will increase by 50% compound annual growth. That will be x10 increase in data traffic by 2021 mainly driven by video.

The report has an interesting section on smartphone switching patterns…

“82 percent of Android users and 73 percent of iOS users selected a smartphone with the same operating system when switching to a new device”


Note that this analysis pertains to switching trends from old to new devices, where users remain with the same operator.

As might be expected, analysis of mobile data traffic consumption on days following a device upgrade shows a significant surge in software download traffic share from app stores after a device switch.

This might give us a clue as to when promoting and marketing our app might be of most influence – when there’s a major new phone on the market or during the holiday season.

The Latest from Blackhat

blackhateurope15If you are a mobile developer, you should take a look at the white papers and presentations that have become available following the recent blackhat Europe 2015.

Of particular interest to Android developers is (In)Security of Backend-as-a-Service (pdf) that shows how hard-coding service credentials for services such as Parse, Cloudmine and Amazon AWS not only puts particular user’s data at risk but the whole platform at risk. The easily-obtained credentials can be used to access huge amounts of sensitive data. The apparent ease of using BaaS has caused mobile developers to cut and paste sample code without thinking of the security implications.

Wondering what else your app might be doing wrong? The AndroBugs framework presentation allows you to scan APKs for known coding mistakes. It decompiles the app and looks for bytecode patterns that signify vulnerabilities in the code. Androbugs has recently become open source on GitHub.

Another way your app data might become visible is if it’s stored in the OS sandbox and subsequently backed up either on a rooted device or via ADB. The presentation on Authenticator Leakage Through Backup Channels on Android (pdf) goes into a lot more detail.

As usual, black hat activities look into the problems but don’t give many ‘white hat’ recommendations how to fix apps. It’s easier and more fun to find problems than it is to provide fixes. If you are looking for some answers then my site provides some recommendations.

Flutter – Cross Platform App Development from Google

fluttericonFlutter is a new cross platform app development framework from Google that allows apps to be created for both Android (KitKat or later) and iOS (iOS 5 or later). It’s still being developed, primarily by engineers at Google.

Flutter is a high performance (60fps) 2D rendering engine with framework and widgets on top. There are also Material Design widgets. It’s all open source.

Internally, Flutter is a mix of C, C++, Dart and Skia (the 2D rendering engine). On Android, there a Dart VM that isn’t an interpreter. Instead, the Dart VM generates JIT-compiled optimized native code. On iOS the code is compiled with LLVM and Dart code is AOT-compiled into native code. On either platform you can call native services via IPC.

The programming language used is Dart which is also open source. Dart, which became available about a year ago, was once thought to be a future replacement for Javascript in the browser but now seems to have taken a new direction. Dart is a mix between c++ and Java and supports classes with single-inheritance. It supports interfaces, abstract classes, reified generics and optional typing.

Flutter isn’t suitable for production apps just yet and you can’t yet produce installable apps that easily. On the plus side I can see it will be enable us to produce high performance, cross platform apps with much less effort and cost. However, I have some reservations.

The first is that the widgets don’t use the respective system’s underlying widgets. There are Material Design widgets but who is going to want these on iOS? iOS look and feel widgets are needed. Even if these were available, it will create ‘look and feel’ problems when Apple and Google update the system widgets in the future. Also, I can’t see how Flutter widgets would ever provide for all the theme/style customisations provided by the native platforms.

Of course, we have been here during Nokia’s ownership of Qt. Providing for respective platform UIs, especially over time, is a monumental task. Getting developers to learn a new language also requires some sort of motivation. Apple is managing it with Swift but people are coming from the much more unfriendly Objective-C. Another unknown is the Google internal politics of where this fits into existing Android dev tools. Again, internal politics helped to kill Nokia Qt. However, the wildcard is Oracle that could tip things the other way. Much longer term, there’s a (small?) chance Oracle’s continual battles over Java IP could tip Google into using an alternative.

Finally, Flutter isn’t the only cross-platform framework trying to use Dart. Fletch is also based on Dart.