Architecting for Features

A few months ago, I gave a talk titled Build Features, Not Apps at iOS Conf SG – you can view the full talk here. It was clearer than ever to me after WWDC 2016 that the future of apps is a web of distributed features instead of one concentrated app. Think of Apple Watch, Today’s Widget, Interactive Notifications, App Search, iMessage Stickers, Apple Maps Integration and the list goes on…

If done right, each of these extensions will be just that – extensions (or features) of your app. For example, you shouldn’t have your whole app functionality in a Today’s Widget – just the part that is useful to the user on a quick glance (such as the weather right now).

But increasingly, these types of extensions allow the user to break free from your app. They can just glance at the relevant information – such as the weather right now – without ever bothering to open your app. They’re still using your service, but not in a traditional “opening your app” sense.

These small and invisible interactions with your app really change the concept of what an app is. An app is now something that gives the user the information or interaction they need at the moment they need it – again, without ever needing to remember to open the actual app. This paradigm shift, while disruptive to apps that do rely on being opened (e.g. they have advertisements in there), also gives a lot of new ways of interacting and building an even stronger brand with consumers. Your app is now everywhere! Not just stuck inside your app waiting to be opened!

This is why for the try! Swift app, I really focused on setting it up for features instead of adding new functionality to the app in time for try! Swift Tokyo.

The key here was decoupling the data layer, including Realm, from the iOS app. The same data layer would be re-used for the Watch App, Apple TV App (in the future maybe), the iOS app, and iOS extensions (such as a Today’s Widget and Interactive Notifications).

Unfortunately, that’s much harder to do than it should be. I recommend the article Creating Cross-Platform Swift Frameworks for iOS, watchOS, and tvOS via Carthage and CocoaPods by Basem Emra to get started.

I personally have never made a CocoaPod, especially one with a dependency on Realm, so I had a really hard time getting everything to link and work together. Luckily, @aaalveee helped us get started, @k_katsumi helped make the pod work across extensions, and @TimOliverAU did a lot of work to set the project up for Realm Mobile Platform (still some work to do there).

It was a lot of work (and still a lot of work left to do), but I’m super happy with the result – you can see the trySwiftData framework on Github here. The best part is that the data framework includes a lot of complicated data formatting code – such as session titles based on speakers vs announcements – that used to be duplicated in code both in iOS and watchOS apps. We were even able to add a Today’s Widget with limited time, using the same data pod.

I’m looking forward to now move a lot quicker with adding new features, including Interactive Notifications and App Search in time for the next try! Swift in NYC 🚀

Enjoy the article? Join over 17,500+ Swift developers and enthusiasts who get my weekly updates.