Vendors
日本語
  2. //
  3. Reports & insights
  4. //
  5. How Big Is Mobile Banking's App-etite?

How Big Is Mobile Banking's App-etite?

Create a vendor selection project & run comparison reports
Click to express your interest in this report
Indication of coverage against your requirements
A subscription is required to activate this feature. Contact us for more info.
Celent have reviewed this profile and believe it to be accurate.
2 February 2010
I have to admit, I have app-envy. Owning an old Windows 6.1 Motorola mobile phone, I look on with a certain longing at my friends, colleagues and fellow airplane passengers who enjoy endless, happy hours with their iPhone/Android/Blackberry "iBeer" apps. I am even more jealous of their mobile banking apps, which seem to me the coolest retail banking technology ever. But truthfully, I am beginning to get a bit dizzy contemplating the options that await once I finally trade in my current mobile device. At the last count I saw, the iPhone App Store had 120,000 apps. This got me to thinking about the plight of banks offering mobile solutions, which are increasingly feeling the pressure to keep up with the app explosion. A very quick check on Wikipedia revealed the following:
  • There are about 6 versions of the iPhone OS (operating system), with a new one in beta
  • Since April 2009, there have already been 3 versions of the Android OS
  • There are at least 30 versions of the Blackberry OS, more if you include those for the Canadian market -- I stopped counting, but see for yourself.
  • The Windows Mobile OS has been around for a while, but it's probably safe to say that phones with 5 or 6 versions are still in use
  • Let us not forget the Palm and BREW OS'
Yikes... Undoubtedly, more of the above will come. I'm no developer, but common sense dictates that this is a lot for a bank to keep up with. Prioritizing, developing, maintaining and owning apps for a myriad of operating systems and mobile devices has got to be daunting and expensive. In recognition of this, some banks are just creating apps for the iPhone, which often constitutes a large number of mobile banking users. But what about addressing all the other phones and OS' out there? It would seem to me that a bank has two choices to keep up with apps. The first is to outsource work to a vendor, whether a full-on mobile banking technology vendor, or an app "development shop". The second is to provide a minimal level of apps (say, just for the iPhone) in the nearer-term, and wait for a "post-app" era in the longer-term. HTML 5 may have the potential to enable mobile browsers to offer the same functionality/integration with a phone's native capabilities (e.g., locationing) that apps currently perform. In either case, both banks and vendors have a lot to think about in terms of development roadmaps. Again, I'm no developer. I would love to hear from our readers. Are apps here to stay? Will HTML 5-enabled browsers eventually usurp apps? Is there some other approach that can replicate the attractiveness of apps?

Comments

  • I have only one option, and that is to agree with you.
    The myriad of OS combinations, ensuring backwards compatibility, and the continual lifecycle development required in maintaining an Online Banking platform can only lead to an explosion in cost.

    It is certainly true that iPhone bankers, as far as audience is concerned, exceed the rest of the field 10 fold.

    Phone's in general are becoming more capable, so all the questions posed above are valid, and the fact remains, you can't excludea portion of your customer base if they don't have an iPhone.

    If cost/budget is a constraint (when isn't it?) I'd be leaning towards a Mobile Web Standards/best practice approach in developing a functional browser based solution. I would design with the iPhone in mind, and no different to web development practices use agent detection to serve the exact same functional capability, but maintain separate stylesheets for your core mobile browser/platform target audiences. HTML5 while not as slick as app development does still allow for some pretty funcky stuff to be done on a phone.

    The end result, a easily maintainable, cost effective single codebase to test against functionally, with only look and feel to optimised for your core audience.

    Perfection on every phone won't be achievable, but a functional, scalable, cost effective, and all inclusive solution for your customers, without a plethora of apps to maintain, is not a bad place to be.

    ... then wait and see what the post-app era demands. My guess, at a minimum, what you have built will at a minimum be able to be re-used.

    AJ

  • Adrian, thanks for your comment. You are certainly more of an expert than I am!

    If I understand your comment, it appears that there is a trade-off between "slickness" and the cost savings of a single (browser-based) solution. However, it appears that the trade-off wouldn't necessarily be too drastic, that a browser solution wouldn't be that bad in terms of functionality relative to apps.

  • Too many choices and fairly complex ecosystem .... we missed one important Symbian OS here according to wiki article (http://en.wikipedia.org/wiki/Symbian_OS)

    "On 21st of July 2009, more than 250 million devices running Symbian OS was shipped"

    and the recent development that Symbian goes open source four months early -

    http://www.computerworld.com.au/article/335048/symbian_goes_open_source_four_months_early/?fp=16&fpid=1

    Another piece related to this is and further complicating mobile space are other touch screen devices that are going to hit market soon like Ipad or google Tablet (Chrome OS) ....

    Mobile Strategy Nightmare ... what say?

  • @Red That's correct, I see the trade off as definitely being an acceptable one. As HTML5, and CSS2 and beyond come into production, I'd say that the gap would again be further reduced.

    @sid could become a strategic and financial nightmare if you get caught up in the hype. One functional code base, with multiple (scalable) and possibly device specific presentations if demand demands it, reduces the nightmare significantly.

    I think the importance of standards based development, while always being a consideration will/should be more so to minimise the logistical nightmare of maintaining too many versions of everything, and trying to satisfy everyone. the fact remains, devices, interfaces and interactions will continue to develop and change. A standards based approach allows the widest range of support, and longer term scalability (as we're starting to see online, with more consistent behaviour across the various browser families due to their wider adoption of standards)

  • [...] As I wrote earlier this year, I have a confirmed case of iPhone envy. As I scan industry news, that sense of envy is getting stronger. This is because lately, I have been noticing iPhone apps that are leveraging the role of mobile devices in payments — i.e., the ability to receive/present data that encourages purchasing behavior. [...]