This repo contains simple iOS app which display data from Steam API - friends, own games, play time, some statistics from game (if game collects it), acheivements and so on. I plan to use this app as playground for my ideas about iOS development and also as showcase of my current skillz :)

README in Russian 🇷🇺

• framework-based layers
• test apps for some layers
• clean code. No hidden dependencies and singletons, no SuperDuperManager.shared.getStuff and so on. SOLID as it should be.
• SOA
• generic coordinators
• VIPER screen modules
• unit tests for storages

• SteamAnalyticsApp
• LoginScenes, UsersScenes и GamesScenes
• Services, UICommon, UICommonTestApp
• APIClient, Storages
• Core

Each layer can use only underlying layers. Horisontal connections are not allowed also.

Base data structures (User, Game etc).

Storages is based on CoreData and CoreStore. Each storage is enclosed with SomeStorageInput and SomeStorageOutput protocols. Basically only services can use Input protocols to save data from API. Interactors of screen modules subscribes for data changes and gets it reactively by Output protocols. Inputs and Outputs uses simple structs from Core, NSManagedObject and its subclasses are not exposed outside.

At this level Core structures are extended to Codable. Also there are some networking helpers (queries, url factories, etc). API clients protocols. Concrete implementation of these protocols uses Alamofire.

Services uses APIClients to get data from API and then to save it to Storages. Also there are services for complex logic like users comparison.

UIView subclasses and its models. SnapKit for layout (no xibs), Kingfisher for images loading. Also this level contains strings and images, wrapped with SwiftGen.

Test app for all cells and other views. Handy for UI developement and UI tests.

UICommon also contains generic coordinators. For detailed explanation please check my other repo. Main idea shortly:

• Coordinatable protocol with two associated type: start option and result.
• CoordinatorFactoring, which is used by coordinators to instantiate other coordinators (wrapped with type erased AnyCoordinatable) without knowledge of concrete implementation, only of start option and result types.
• Useful feature: with this approach you can use every coordinator separately in test application. Other coordinators can be stubbed. Please check StubCoordinator and StubCoordinatorFactory.

3 base coordinators: WindowCoordinator, TabCoordinator и NavigationCoordinator, its purposes is obvious.

Separate frameworks for diffenert flows: LoginScenes, UsersScenes & GamesScenes. Each contains: coordinator, viper modules, modules factory.

Each screen module is enclosed with same approach as coordinator: it has input and output protocols, and exposes UIViewController, so coordinator can intagrate it into views hierarchy.

VIPER-like pattern is used for every module, however as it is fully enclosed with protocols, it does not matter.

Main app is very thin and minimalistic - it combines all layers, sets up and injects all dependencies and starts main coordinator.

Charts pod is used for games stats history, in future I have plans to develop my own charting library.

Main app schema has xDebugMode environment variable, when it is enabled fake login button appears on login screen, it emulates login by user with great CS: GO stats :)

Unit tests for Storages. In-memory data stacks, background transactions awaiting.

• dark mode
• dynamic type

• sourcery for autoinits generation.
• test some DI container.
• enclose Storage's object monitoring.
• test apps for separate coordinators.
• stats from Dota2.

Email: mikhail.igonin@gmail.com

Telegram: https://t.me/mikhail_igonin

Twitter: https://twitter.com/frozen_lion/