Pim_Stolk_-_Future_proofing_your_iOS_apps.md

Pim Stolk - Future proofing your iOS apps

• In 2010 ING started doing mobile banking, they focussed on the iPhone. Koen was the only developer and his task was to make the best experience. But they were missing something, they forgot about the iPad. The iPad was added as a last minute decision so they had to hire more people. And with that, the first technical dept was introduced. In the end they were pretty happy with the universal app.
• And then Swift came out, ING had a huge Objective-C codebase but they wanted to adopt it regardless of all the SourceKit crashes. So they started doing new features in Swift.
• Out came the watch, and notification center widgets, and Apple TV. But they weren’t ready to support that.. they couldn’t securely reuse a lot of their code. Because ING is a bank everything has to be super secure and opening up the app to different targets was a big problem.
• Not just the problem is big but also the ING app is big. There’s almost 1.000.000 lines of code, > 40 developers and over 25500 commits. They’ve been around since iOS3 so there’s a lot of legacy code. And with a lot users, they can’t have any downtime.
• One of the most important rules when ING was looking for a solution to open up their apps to different targets was don’t repeat yourself. Their first idea was to take many targets in a single projects and add files to targets. This got messy really quick so that didn’t work.
• The second option was to make dynamic frameworks. This was easy to work on with a big team and it supports Swift. So there were a bunch of subprojects created that could be added to the main projects. This meant that each framework can be tested on it’s own and it allows for great code reuse. The UI can now be tested with UIInstruments. By using dynamic frameworks it’s possible to separately version frameworks, have teams responsible for a certain frame work and you automatically extract out the UI code.
• By doing this (official) support for iOS7 had to be dropped. This is a huge challenge for a big company like ING. Also, while switching to the dynamic frameworks you still have to develop features. You can’t go and refactor for a year.
• ING still has to figure out things like inter-framework communications. Also, who is responsible for making API calls, especially since they have to be super secure. Who owns the data? And also, how do you navigate this? If every feature goes into a framework it can be harder to couple it all together.
• In the future ING will replace features with frameworks incrementally and they will figure most of it out as they go. While their doing this they have to support a growing range of devices, and be prepared for future devices right away. ING believes that using dynamic frameworks can help them a lot with this.
• Question: Do you have separate repo’s for your frameworks?
  • Right now not, we are planning to do this at some point in order to keep up modularity.
• Question: At some point you have to drop support older iOS versions? What’s ING’s strategy?
  • This strategy changes every year. We look at actual users and their iOS devices. We do this based on what our real users do with the app and if they have other iOS devices they can updates. If we plan to release a ew feature but nobody on iOS6 uses that, we don’t support iOS6. The current app would still be usable it just won’t get updates.
• Question: Do you write all code in-house? Or do you outsource some parts? Especially considering security I think this interesting.
  • We do everything in-house.
• Question: How do you decide to start supporting a new platform? Is this based on user numbers?
  • We want to support everything as soon as possible. We think about an MVP and we launch that as fast as we can, after that we keep on improving based on user feedback.
• Question: I assume you also support Windows Phone and Android. Have you ever considered using a web app?
  • With an app this size you have to consider everything, we don’t think making this a web app is a good idea.