The big news from Google I/O is Android Instant apps which will allow apps to be run from a URL without installation. Once they have been used, they will disappear and not appear in the usual applications list.
My first thoughts were that this will be very useful for one shot apps where the user needs to do something just once. However, I am not as overly enthusiastic as some some of the technical press. First, you won’t be able to use background services. This makes sense as it’s a quick one-off run of an app. However, many apps use services and re-architecting them to also work without a service is significant extra work that somewhat goes against Google’s aims of simplicity in converting apps to support Instant.
A larger barrier is that this obviously won’t be supported on iOS. Most projects are on iOS and Android these days and functionality needs to be similar on both. You can’t, for example, have an Instant car parking payment app just on Android – it’s a dumb thing to do. Non-orthoganal functionalty across iOS and Android tends to get used less.
Instant apps will mainly be used with URL-producing mechanisms such as QR Codes, NFC and Physical Web Beacons. In some ways the Physical Web/Eddystone and Instant apps are a great marriage. In many cases the Beacon URLs don’t do enough and a simple single use app will bring people back into app-land where a lot more functionality can be provided.
There’s an interesting article at XDA developers on Why Material Design Didn’t Achieve the Grand Unification it Originally Aimed For.
The article describes Material Design as being stifling, contradictory (U turn on splash screens and bottom tabs) and more of a “Google brand” rather than something that is supposed to be generic. The article says…
“The given rules are vague, and lack definition, and with navigation being a crucial springboard for the entire product, its rules and recommendations could use an upgrade.”
I wasn’t a great fan of the introduction of Material Design in 2014. I questioned whether a complete re-design was really needed, asked what it would end up costing developers/stakeholders and observed that there would be old apps and old devices/apps so it would end up being a mishmash anyway.
Such is the problem with many well-meaning and ambitious large initiatives. On their own, they might look amazing, new and innovative. For some strange reason, developers cheer and croon at such things at developer conferences. However, when such things hit the real-World, things get messy.
Perhaps it’s a lesson for such projects to have more pragmatists and real practitioners on the project to help drive things in such a way they will be practical.
Something happened last week that should have got more press. Google started to rollout support for the Physical Web in the release version of Chrome. Up to now, the Physical Web has been a bit of sideline activity for Google. It was previously only available to those few people who took an interest and downloaded the beta version of Chrome, a standalone app or the the relatively few people using Chrome on iOS.
The Physical Web is similar to a QR codes in that it provides web addresses. Instead, the web address comes from a Bluetooth beacon that’s typically up to 50m away but this can reach up to 200m with some beacons. Chrome can now scan for these beacons and prompt the user, via notifications, whether they want to open the URL. What’s more, Google has said they will be prompting users to enable the Physical Web when they walk by a beacon for the first time. This should build awareness.
Some people are asking if we might be entering a post app World. I don’t think so. There are barriers to entry, the largest being you need Bluetooth and Location on in the first place. Even if it were to ignite the mass-market’s imagination, I am sure there will be group of people ready to spoil the party with spammy URLs and URLs leading to sites with malware. Also, Google is still rolling it out and it will be two weeks before we all have Physical Web enabled Chrome browsers. Meanwhile, there’s a workaround if you want to be an early adopter.
However, I do see a large potential for use of the Physical Web in more controlled situations where the user purposely enables and uses it in a proactive situation – much like using QR codes now but with much better ease of use. So, lots of places and things could become Physical Web enabled and users could actively choose to seek the URL for more information.
If you want to experiment with the Physical Web, BeaconZone, which I have an involvement in, currently has a choice of 16 Eddystone beacons.
Occasionally, I see patterns in enquiries for mobile development. At the moment there seems to be a significant increase in the number of companies looking to port apps from iOS to Android. I am not sure why. All I can think is that Android might have reached a tipping point where only having an iOS version of an app isn’t acceptable (to end users) any more.
Ironically, in the last few months my development efforts have been moving in the other direction. My last two projects were porting Android apps to iOS. However, this week I am back on Android and porting an app from iOS. Whatever way you look at it, it’s looking that mobile developers ideally need to be proficient in both platforms.
If you are looking to port from iOS to Android, my notes might help you to start thinking about the issues.
Occasionally companies pre-announce porting tools and I wonder how such tools will ever be possible. One such tool was MyAppConverter that I came across in late 2014 when I thought their aims were impressive and hugely ambitious. However, I didn’t think what they were trying to achieve was possible in a reasonable time and/or with a reasonable team size.
It was with this in mind as I read, via SlashGear, about Microsoft cancelling Astoria for Android, another over-ambitious porting tool. It seem like Microsoft finally realised the scope of what they promised and instead decided to focus on (buy) Xamarin that partially solves the problem from the ‘creation’ rather than ‘created’ end.
Re-visiting MyAppConverter, it appears they now only solve part of the problem and you have to ask them for a quote to manually convert the parts that can’t be automated. App converters are the silver bullet that doesn’t really exist.
I 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 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.
Trend 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.