FinniversKit holds all the UI elements of the FINN iOS app, the main reference for our components is our design system, you can find the docs here. This framework is composed of small components that are meant to be used as building blocks of the FINN iOS app.

In order to develop our components in an isolated way, we have structured them so they can be used independently of each other. Run the Demo project for a list of all our components.

Installation

Carthage

github "finn-no/FinniversKit" "master"

Usage

Import the framework to access all the components.

import FinniversKit

Interesting things

Folder structure (tests and demo)

Inspired by Kickstarter (and Ruby on Rails) we place relevant files next to each other, even if these files are placed in different targets. We believe that having files closer together makes you aware of the different elements that might be affect after a change.

Delegates and data sources (instead blocks and injection)

In order to maintain consistency we have opted for using data sources for giving data to our recyclabe views and using delegates to interact for actions inside views.

If the view isn't recyclable then we use ViewModels. There are tradeoffs when you choose to be consistent instead of pragmatic but we hope that by having a clear pattern it reduces the discussion points and let's us focus on improving the UI and adding value to our users.

Why not playgrounds?

Our Demo project has been setup in a way that every component is isolated, we initally started by using Xcode's playgrounds but we quickly outgrew it's capacitiy, reloading times weren't quicker than making the change and running the project again, also it wasn't possible to debug and set breakpoint on things and we couldn't use many of Xcode's useful utilities such as View herarchy inspector. Finally, the fact that we had to rebuild the project after making any change in the framework meant that we weren't as efficient as using plain Xcode projects (where rebuilding isn't necesary after making a change).

Accessibility

Everything we do we aim it to be accessible, our two main areas of focus have been VoiceOver and Dynamic Type.

Snapshot Testing

When making UI changes it's quite common that we would request an screenshot of the before and after, adding Snapshot testing made this trivial, if there was UI changes you would get a failure when building through the CI.

FinniversKit uses Uber's snapshot test cases to compare the contents of a UIView against a reference image.

When you run the tests FinniversKit will take snapshot of all the components and will look for differences. If a difference is caught you'll be informed in the form of a failed test. Running the tests locally will generate a diff between the old and the new images so you can see what caused the test to fail.

Testing a new component

To test a new component go to DemoSnapshotTests.swift and add a new func with the name of your component under the section that makes sense, for example if your component is a Fullscreen component and it's called RegisterView then you'll need to add a method to FullscreenViewTests your method should look like this:

func testRegisterView() {
    snapshot(.registerView)
}

Note that the snapshot method is a helper method that will call FBSnapshotVerifyView under the hood.

Verifying changes for an existing component

If you make changes to any components you'll have to run the test for that component after changing recordMode to true. Doing this will generate a new reference image that will be used later to verify for changes that affect your component. After you've generated the reference image change recordMode back to false.

License

FinniversKit is available under the Apache License 2.0. See the LICENSE file for more info.

The FINN.no branding, icons, images, assets, sounds and others are solely reserved for usage within FINN.no, the main purpose of this library is for internal use and to be used as reference for other teams in how we do things inside FINN.no.