This is my final post on this site. While I still occasionally create mobile apps, this is no longer the sole focus of my work. This site will remain operational as it receives lots of traffic and still contains lots of useful information/links related to mobile development.
The BHW Group has recently posted about Mobile App Maintenance Costs. They say people often forget to consider the ongoing maintenance costs of mobile applications. Costs include hosting, monitoring, continued engagement, marketing, app updates, and customer support.
For experience, I think the most significant factor is app updates. For any non-trivial app, it’s almost always the case that once the app is live, it’s the first time stakeholders are able to really think through what they have asked to be created. They suddenly see the limitations, user experience problems and scope for improvements. Then there’s new OS versions. When Apple or Google have major updates to their operating systems, some things sometimes don’t work as well as they did and other times new APIs offer opportunity for improvement. Then there’s devices. On Android AND iOS it’s impossible to test all variants of operating system on all possible devices. There are always bugs to be fixed. Also, as new devices are released, there will be new problems. Hence, any non-trivial app undergoes ongoing maintenance. Then there’s Apple. Their T&C’s continually evolve and what passed review last time might not pass next time. Passing review is a moving target. What people consider as a ‘small change’ can become a larger change due to the need to address some new review issue.
Hence, as the BHW Groups says, you need to consider the ongoing maintenance costs of mobile applications. More specifically, you need to plan human and financial resources. On the human resource side, you need someone who will be around not just to create the app but also to perform longer term updates.
MobiForge is reporting that 68% of digital media time is now spent on mobile devices. 50% of digital media time is dedicated to using mobile apps.
As the article says, this is leading to the situation where the smartphone experience might be considered the first and primary platform. However, conversion rates are lower on mobile (3.89% desktop vs 1.43% mobile) which means we have to think harder how to retain mobile users.
I believe the poorer conversion rate is partly due to the smaller screens and shorter attention spans on mobile. While there’s little that can be done about this, we can add and promote features that allow users to save or share things for later when they are viewing on larger screens or have more time.
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.
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.
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 have been 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.