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.
Tomi Ahonen has a useful post on his blog showing the latest installed base numbers across mobile operating systems. Installed base numbers, as opposed to current sales market shares, can provide a better view of the real makeup of the user base…
“Note that in my model I already had a very strong long-life factor for the iPhone and the iPhone installed base has for this whole decade been above the actual unit sales market share – due to the long life span of iPhones”
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.
There’s a strange article at The Hacker News that claims that Google might adopt Apple’s Swift Programming language. It’s said that Google is considering making this a “first class language choice for programmers making apps for its Android platform.” Is this a late April fools joke?
While the article mentions Google’s ongoing battle, over Java, with Oracle as the reason for the adopting Swift, I can’t see it happening. Google has too much effort invested in Java in terms of tools, libraries, APIs and documentation. Repeating all this for Swift and making it “first class” would be a gargantuan effort. Also, I believe it wouldn’t be a great move as Swift is a moving target. Having done some Swift development myself, existing 3rd party libraries and documentation tends to be out of date and Apple have no qualms about changing the language syntax thus breaking backward source code compatibility. The Google Android team would end up chasing their tails.
Also, anyone thinking that the availability of Swift on iOS and Android might make cross platform easier should think again. While it would be useful for the (usually small amount of) business logic, the UI and platform APIs programming would still have the separate. I don’t think it would really help that much.
There’s also more commentary on this on TheNextWeb.
Gartner has new research that says Global Smartphone Sales to Only Grow 7 Per Cent in 2016 and will be the first year to see single digit percentage growth…
“The double-digit growth era for the global smartphone market has come to an end,”
I guess most people who want a smartphone now have one. Any changes in OS market share will be due to switching. This isn’t necessarily bad news for developers as it means that mobile platform market shares are now stable and can probably be relied on for staying so for some time.
This month’s net magazine (May issue to be exact) has a great article on 15 tips for cross-device optimisation. Craig Sullivan gives some rules to remember when testing cross platform.
Four insights of particular use for mobile developers…
- Track people, not devices. Many people use their phone to find items to buy and complete the purchase on the desktop or laptop where it’s easier to checkout. Use tools such as Google Analytics user view to track the user rather than the device to gain a better appreciation of whether leads are coming via mobile or desktop.
- Don’t ignore the wider context. Think about varying the functionality depending on the context. Craig gives the example of an airline app where what the user needs might be very different 48 hours before a flight than it is when it’s used at the gate.
- Don’t assume everyone uses iPhones. Avoid concentrating on what happens to be your personal device. Look to user base numbers and ideally recent domain specific metrics.
- Segment testing by device class. Different devices might look very different and might need different testing.
There’s an interesting recent post on re/code by Raj Aggarwal, Co-Founder and CEO, Localytics where he says we are in a mobile engagement crisis. He phrases the problem as a request to Mary Meeker of KPCB Internet Trends Report fame, to ask her to consider what she puts in this year’s report and encourage companies to do more.
Raj says that…
“the majority of businesses have failed to innovate at anywhere near the same pace of consumers’ demands and expectations for mobile”
and that there’s a
“temptation to just do “something” and check off the box is greater than ever”
Naturally, his company has the answer in the form of “deep insights from the data”. Nevertheless, I think Raj is right. Companies generally aren’t trying hard enough and consumers really want more (of mobile).
Looking at this from another angle, it means that the fewer companies who currently take mobile seriously and do it well can use it to competitive advantage. While data is one aspect that can be used to drive change, I believe the changes need to be at a higher level than this and are more about addressing end user needs rather than company needs.
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.