It was with some disappointment that I read that Google aims to train two million Indian developers on Android platform. It’s not the competition but the number of extra people who will end up ringing me to see if I have excess work that can be outsourced. I get a few such enquiries by phone and email every week. They must be desperate or misinformed because the kind of work I do is for people who definitely don’t want their work offshored.
In many ways, training two million extra Indian developers misses the real problem. The fact that the existing Indian developer base is already contacting me eager for work shows there isn’t a supply problem. For India, the real developer problem is one of incorrect expectations. Creating yet more developers that say ‘yes’ to everything and then under-deliver isn’t a solution. Instigating more projects that will need excessive developer management isn’t what’s required. Instead, Google and the Indian training partners should be looking to impart cultural, software process and engineering skills as opposed to just Android skills.
There’s a thought provoking article at TechCrunch where it’s said that ‘The App Boom is Not Over’. The author points to data that shows that app revenue is expected to continue growing possibly driven by increased subscription revenue.
From my position, people are still looking to have apps developed and we seem to be in a period of consolidation where apps are being ported from iOS to Android and vice versa.
I believe that gaining revenue from selling apps is indeed waning. However, using apps to gain revenue by other means, through what they do, has never been stronger and we are moving past ‘infoware’ to more useful apps that do real things and provide value to users.
Developers such as myself are having to diversify AND specialise. I have had to diversify back into iOS development as existing clients have been demanding both iOS and Android apps. I seem to be porting both ways these days. However, I have also been starting to specialise in specific app (domain and technology) niches in order to continue to attract leads for work.
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.