iOS8 for #fintech

Apple's announcement of iOS8 at its recent developers conference was one of the biggest OS announcements it has made since the original iPhone. Much of the new OS capabilities are aimed at developers, with over 4,000 new APIs, new developer tooling and even a completely new programming language.

There was so much new content, its hard to see the wood for the trees. I thought it might be interesting to interpret some of the announcements and ask “what does this mean for #fintech (the world of finance technology and innovation)? I've pulled together some of the more significant announcements, that seemed to me to have some relevance, and provided some commentary below about what they might mean.

Of course, being new OS function, the new capabilities are currently available in beta for natively coded apps only. Other development approaches (e.g. frameworks that build hybrid apps) will need to be updated to support the new features. But even for those apps, calling out to native code is a possibility to exploit some of the new iOS8 capabilities.

TouchID API access

This was an obvious and a biggie. Now that we can progratically access the TouchID fingerprint sensor, we can use that to authenticate the user in any app. Begone, complex passwords!

API access means that TouchID can play a role in sophisticated authentication scenarios. For example, a bank may choose to retain their existing authentication method for their mobile app, but use TouchID as an additional security mechanism for money transfer. The use of password and fingerprint is a very secure combination. Apple have used TouchID for convenience. That is a choice, but it can also play a role as an additional layer in high security situations.

The TouchID implementation is quite elegant, because it keeps all the security processing separate from both iOS itself and also your app. It means that apps never get access to fingerprints and the details of those remain locked away in the Secure Enclave. This maintains the users trust in the integrity of the system and of TouchID itself.

Of course this is great and has obvious applications in banking, finance and payments. PayPal are already investigating TouchID use, and I think it's a fair bet that it will start cropping up in many, many apps once iOS8 ships.

Widgets

The ability to place widgets in Notification Centre brings many possibilities.

For example, what about a widget that shows your account balance, maybe with a TouchID authentication for the super paranoid? I'm not sure we need authentication though - many banks happily send account balance and more over unsecured SMS channels. Either way, the ability to embed function outside of a specific app brings all sorts of possibilities for convenient access to information.

Inter-app communication

The announcement of 'actions' that allow function from one app to be accessed in another brings some intriguing possibilities. Apple demonstrated a Bing language translation inline within a Safari web page - very impressive.

How might the #fintech world use this? Well, the data we have is often transaction data - so function that works on that is the most obvious choice. Maybe a 3rd party service that translates the sometimes cryptic transacting party name into something more readable? (I used to have a regular debit to "BDMLConnect" - which turned out to be Admiral Insurance after I disputed its authenticity). Or maybe there are opportunities to integrate with third-party 'spend analysis' services? Looking another way, a banking app could expose a currency calculator, so when you see a price in another app (or website) the bank could translate that into your chosen currencies value.

Virtual Currencies

Apple garnered a fair degree of criticism for banning Bitcoin apps from its App Store. However, at WWDC it updated its App Store Guidelines to state “Apps may facilitate transmission of approved virtual currencies provided that they do so in compliance with all state and federal laws for the territories in which the app functions.” Exactly what this means is unclear, but many are betting this deliberate change means a softening of the fruit companies stance to Bitcoin and its ilk.

Swift and Playgrounds

The introduction of an entirely new programming language was very unexpected. However, Swift looks like a well thought out language with some clever attributes. It has the readability and simplicity of JavaScript, but the robustness and speed of Objective C. In fact, Apple says Swift is faster than Objective C.

However, the big thing about Swift is how much faster it is to write code than other languages. Within a day of Swift being released, a clone of the famous Flappy Bird game had been released.

Swift is impressively easy to learn. Compared to Objective C, its a massive increase in simplicity. Where Objective C is clever but complex, Swift is simple and straightforward. There is also much less 'boilerplate' code in Swift. New programmers are going to be effective much, much quicker. And less/simpler code equates to more maintainable code with fewer bugs.

“The line of code that's the fastest to write, that never breaks, that doesn't need maintenance, is the line you never had to wite.” — Steve Jobs.

Equally impressive is the new interactive 'playgrounds' feature for Swift that's built into the XCode tooling. A playground interprets and runs code as you write it. Write 'println (“hello world”)' and you see 'hello world' immediately. Write a line of code to draw a shape, and see that shape immediately. Or, view a timeline of a variable, seeing how it changes over time in a 'for' loop. This immediacy and interactivity makes Swift a dramatic breakthrough in simplicity. Rather than wait to compile and run your code to see the results, you see those results as you type. Xcode and Swift promise real productivity breakthroughs. Quicker coding, more reliable code, these are benefits to all domains, not just #fintech.

New WebKit framework & API

Some portray the position of HTML-based and hybrid apps as some form of competition against apple-backed native apps. However, I think that is an entirely misguided characterisation. It's often forgotten than Steve Jobs originally resisted the provision of native app development, instead pushing HTML apps. Apple is nothing but pragmatic on this point - if they wanted to ban hybrid apps, they could easily have done so; but they have not.

Hybrid apps were made possible through Apple's UIWebView API, which allows embedded web content in a native app. All hybrid apps use this API and are completely dependent upon it. One of the App Store rules is that web content can only be displayed with this official API, which is why even Google's Chrome browser on iOS uses Apple's web rendering engine, rather than Google's.

However, there have been some significant issues with the UIWebView API. Firstly, it does not support the more advanced JavaScript engine that Safari uses, relying on an older and much slower implementation. This means that all hybrid apps are slower than Apple's Safari. This included Chrome, which is forced to use the old, slow JavaScript engine.

The second problem with UIWebView is with the bridge between native Objective C and JavaScript in the web view. Typically there is a need to pass data from the native side of a hybrid app into the UIWebView control and pass results back again. There's a standard bridge into the web control, but none to receive the results of a JavaScript call back into Objective C. Instead, hybrid frameworks are forced to use a giant hack that relies on intercepting the user web taps and response html. It works, but is very messy.

In iOS8, both of these problems are fixed. Apple is introducing a completely new web API that supports both the latest JavaScript engine and returning the results of JavaScript calls back to native code. It's a big improvement and puts to rest the lie that Apple is anti this style of app. The new API also supports smooth 60fps hardware-accelerated scrolling, so the stuttery scrolling that made many hybrid apps appear so clunky is now banished. I think this new API will make it much easier to embed web content into native apps and to do so in a way that is imperceptible to users. Apple is making web content a first-class citizen. Sadly the new web API will require some engineering work in the hybrid frameworks to switch over to it, so we might not get to see the advantages immediately, but they will come.

The new improvement to web support don't mean that all apps should use HTML and JavaScript. Native code still executes an order-of-magnitude faster (which might be important not just for speed, but also restraining battery usage), the development tools have some advantages (eg Apple has specific tools for diagnosing animation framerate issues and memory leaks that are much harder to identify with web content) and there is a very rich ecosystem of developers and experience. New innovations like Swift help keep native code a great choice.

The reality is that native code has many advantages, mainly in UI consistency, ease of adopting new OS capabilities, speed and easy exploitation of the very rich native app development ecosystem. However, hybrid apps also have their advantages, particularly in corporate environments where the reuse of componentary across web, iOS and other mobile devices is important to support efficient delivery of the same function to multiple environments.

IMHO it's not about native or hybrid/HTML technologies, but about the appropriate use of both to build the best user experience. Many of Apple's own apps use embedded WebKit HTML content - iBooks uses it to render the text of books, Mail uses it to layout HTML email and even Messages uses it to render conversations with your friends. An intelligent use of native and HTML technologies, where the choices are guided by user experience rather than religious zeal, is the best approach. In my experience, good mobile developers don't talk about native versus hybrid apps; they talk about the appropriate use of all of the tools available to them, to best solve the user experience challenge that's presented. Anyone who starts the conversation with an assumption that there is only one way is best ignored.

Interior positioning

iOS8 brings a new interior positioning capability. Just as GPS allows navigation outside, now Apple allows clever use of the M7 motion processor and RF signals to report position when the user is inside a building. This is important, because GPS need line-of-sight to a satellite, which is impossible when there's a ceiling above you and walls around you. In iOS8 we have interior navigation, as well as exterior navigation.

This means that maps and location-tracking of users inside of buildings is now possible. Maybe this could be used to help guide a customer to an ATM in a shopping mall. Or to help guide the visually impaired to the right place in a bank branch. Or a payment app might use this capability to guide customers to receipt points in a store. I have to admit it though, I really want the real-life Pacman game that I'm sure someone is going to make.

Per-app battery drain information

The addition of information about per-app battery usage is a great feature to help users diagnose apps that are causing battery issues. It's been suggested that the Facebook app has at times been a particular issue, but this is hard to track down, until now.

That is now fixed, with simple data being reported on a per-app basis for all to see. And it makes it very obvious to users which are the quality apps and which are the poorly coded battery hogs.

This means we need to be more conscious of battery usage. An app that churns the battery, has runaway code, makes use of background resources poorly or leaves the GPS turned on when not being used, will now be obvious to the user. Users are very likely to simply delete apps that show as battery hogs, so developers will need to make sure they aren't at the top of the list of battery eaters on customer's devices.

Location-based app suggestions

Location-based app suggestions are a great way of making users aware of apps that add value to a particular physical location. A discrete outline of a suggested app icon is placed on the lock screen when a user is in the vicinity. So, when a customer is near a bank branch, the bank's app might be suggested on the lock screen.

What is interesting, is that the suggestion is made even if the app isn't installed, so this capability might act as another way of encouraging users to download #fintech apps, in the right circumstances.

Exactly how Apple makes theses suggestions isn't completely clear yet - I suspect it's using the same underlying location-based app popularity algorithms as the App Store “Near Me” tab. If this is true, and app usage at a geolocation is the key, it implies some interesting possibilities. For example, Flypay is a mobile payment service used in Wahaca Mexican restaurants in the UK. If Flypay is the most popular app in those restaurants (possible) does this mean it will pop up on the lock screen of all iOS8 users in Wahaca restaurants? If it does, this could be an incredible way of generating interest in #fintech apps.

Cloudkit

Cloudkit was a big surprise. Apple has never been known for it cloud capabilities, so to see them offer cloud services to developers raised a few eyebrows. Cloudkit is similar in concept to many of the existing “back end as a service(baas)” options like Parse(now owned by Facebook), BlueMix(IBM), and many others. These services provide many of the server-based features that mobile developers need, but without the usual complexity of finding a hosting provider, provisioning an OS, installing databases and middleware, etc.

Cloudkit and its competitors provide things like pre-configured server-based databases to centrally store information, push-messaging servers, etc. This can dramatically simplify app development and mean that you don't need to worry about all the server technical gubbins that used to distract you from building the actual app.

CloudKit isn't as rich in breadth as something like IBM's BlueMix, but does have some unique Apple twists that have some intriguing possibilities. It uses AppleIDs as user accounts - and allows some aspects of discoverability. For example, it's possible to find out who else in a user's address book is also using your app — assuming those participating allow sharing. This implies function that we would normally look to Facebook for. This is interesting, because I know quite a few people who don't use Facebook, but do have AppleIDs. I wonder if there might be a class of app that uses AppleIDs and Facebook to get a more complete social view? It's fascinating that Apple isn't building a Facebook, but might be allowing others to do so by leveraging the CloudKit APIs.

Augment this with some sophisticated change notification and delta-download capabilities, and it feels like CloudKit might enable some new types of function.

Obviously CloudKit is very Apple-centric, so other BAAS services are much more appropriate in multi-device situations. And those other options have many more capabilities. But CloudKit does hint at new possibilities that are unique to the Apple ecosystem. Whilst many #fintech companies need to be cross-platform, maximising the attraction of a service on iOS can also be an important business priority. These strategies don't need to conflict; it's perfectly possible to use a cross-platform BAAS option, with CloudKit augmenting where it has unique value. In other words, there is nothing to stop devs using both ClloudKit and a competitor to get the best of both worlds. At the end of the day, your choice comes down to business strategy and market focus decisions.

Interactive & Silent Notifications

Notification prior to iOS8 were pretty basic, but now you can include action in them. So, instead of just having an 'ok' button in a notification, you can have a number of buttons that initiate different actions.

How about a notification that you're bank account balance has just gone over your overdraft limit. Instead of 'ok' (huh, how is that ok?) The bank can offer a 'transfer from savings' button in the notification. When the user presses that button, the app is launched and makes the transfer (after using TouchID to authenticate, of course). This prevents the user needing to find the app, find the 'transfer money' option in the app, enter source, destination accounts and choose an amount. Instead, the whole process can be automated, with the user just pressing one button.

Another interesting feature of notifications (which was actually introduced in iOS7), is the ability to send an app 'silent notifications'. These are invisible to the user and wake the app up in the background, where it can then connect to the server and download data. The silent notification lets the app know there has been an event and there is data to retrieve.

Silent Notifications are perfect for #fintech - i.e. send the app a silent notification when a transaction occurs. Then, the app connects silently in the background, downloads the transaction details and stores those, encrypted of course, in a local database. This means the user's device has all the transaction data cached locally and is always bang up-to-date. Such an implementation would make a banking app incredibly responsive and fast - most of them today are quite tedious to use, because of the need to download data from the server all the time.

Summary

The overriding impression I'm left with from iOS8 is one of potential and possibilities. To take advantage of this potential is going to need some lateral thinking. Quite how the #fintech world can exploit this, only time will tell. Using TouchID is an absolute no-brainier - I will be astounded if we don't see a rash of enabled apps. Some of the other features have perhaps subtler but further reaching potnetial. There are definite possibilities for those that choose to open their minds.

 

Posted with Blogsy