runitz

This repo contains the full source code for Runitz, an iOS app to help runners converting distance and time between Kilometers and Miles and also helping predicting paces and duration of races.

Soon to be available on the App Store.

• About
• Getting Started
• Related Projects
• Credits
• License

About

Runitz allows runners manage distance and pacing information between the metric and the imperial unit systems.

Features

It has three main features:

• Distance converter between Kilometers (Km) and Miles (M)
• Pace converter between minuter per Kilometer (m/Km) and minutes per miles (min/M)
• Race pace or duration prediction. For a specific disyance, what is the expected duration based on a specific pace or what the necessary pace in order to achieve a targeted duration.

Why one more converter app?

There are a few reasons behind the creation of this app.

First of all, it is an app to be used by me daily. As someone that operates with the metric system, quite often needs to process information or content using the imperial system.

Second, this codebase is a good opportunity to play and test new and trendy technologies.

Some of the technologies used:

• The Composable Architecture
• latest iOS API (Swift UI, Swift concurrency, Combine, etc)
• Github actions and Xcode cloud

The Composable Architecture

The whole application is powered by the Composable Architecture, a library by Point-Free that provides tools for building applications with a focus on composability, modularity, and testability.

A brief description from the authors:

This means:

• The entire app's state is held in a single source of truth, called a Store.
• The entire app's behavior is implemented by a single unit, called a Reducer, which is composed out of many other reducers.
• All effectful operations are made explicit as values returned from reducers.
• Dependencies are made explicit as simple data types wrapping their live implementations, along with various mock instances.

There are a ton of benefits to designing applications in this manner:

• Large, complex features can be broken down into smaller child domains, and those domains can communicate via simple state mutations. Typically this is done in SwiftUI by accessing singletons inside ObservableObject instances, but this is not necessary in the Composable Architecture.
• We take control of dependencies rather than allow them to take control of us. Just because you are using StoreKit, GameCenter, UserNotifications, or any other 3rd party APIs in your code, it doesn't mean you should sacrifice your ability to run your app in the simulator, SwiftUI previews, or write concise tests.
• Exhaustive tests can be written very quickly. We test very detailed user flows, capture subtle edge cases, and assert on how effects execute and how their outputs feed back into the application.
• It is straightforward to write integration tests that exercise multiple independent parts of the application.

The codebase also employs some of the best practices for modern app development adopted by Pointfree, such as:

• Hyper-modularization

• Preview apps

Getting Started

The codebase strucure follows the same structure adopted by Pointfree on theirs isowords repo.

The root path contains all modules as SPM modules. The main app is inside the folder Apps.

Related Projects

This application makes use of a number of open source projects built by me, including:

• Alfaz
• Beatz
• Defectz
• Gavetaz
• Variationz

Credits

• Composable Architecture powers the app architecture.

License

MIT License. For more information see the full license.