CoreKit is an ultimate cross platform framework and toolset to help you create applications for all the Apple platforms.
A universal open source library to help you build apps for Apple platforms, but how? The framework is trying to focus on these three key things:
- user interface building
- asynchronous code
- network stack
User interface building
Have you ever heard about the UI stack?
There is no need for a long explanation, anything your app will do should follow the principles of the UI stack. The main question is that how should you achieve this stateful behaviour? You can use multiple views & hide them according to the current state, but that's not a very good solution. You could also use child view controllers, and a coordinator or a state machine to manage the states, but that would only solve half of your problems and eventually it will lead to new ones.
You should always use collection views
You know there are lots of iOS Architecture patterns and some people think that there is no silver bullet. I think they are wrong. VIPER and MVVM architectures are really close to the ultimate pattern, but they're missing one important thing: You should always use collection views instead of regular views inside your controllers. From the moment you start following my advice, everything inside your project will be more flexible and highly reusable.
Collection view sections (header, cells, footer) are really good building blocks. All the elements inside a section are reusable views, which means if you scroll inside a collection view, all the elements will be reused if they are not presented on the screen (low memory overhead, not like in a simple scroll view). A collection view is a descendant of a scroll view, so if you have to avoid the keyboard for input fields, that could be handled easily. Cells can set their sizes based on the content, orientation or whatever you want, this is also a huge advantage too. Inside your cells you can use traditional view components, like labels, image views even stack views, you just have to calculate the size of the cells & auto layout can take over the rest.
Apple over-engineered the problem
There is a wwdc session video back from 2014 about how to build advanced layouts with collection views, but the guys at Apple over-engineered the solution a little bit. My approach is more simple, without parent and child contexts. The base idea is to have a generic data class which can encapsulate a cell (item) and an object to decorate the cell, now put these data class instances into section objects. Each section represents a section inside the collection view, they can have selection handlers, but induvidual data elements can override the selection behaviour too. Let's go up one more level, there is the source class which gathers together all the sections. In other words, the source class is the data source of the collection view.
This way the UICollectionViewDataSource protocol implementation is not inside my view controller it's in a separate data source file, that means you can completely eliminate massive view controllers from your project. This data source is generic and it's extendable, so I can reuse all my data sources anywhere I want. I am using cells / items so all the view components are instantly reusable and memory friendly. I can use different layout subclasses to display my data, and I also made a grid system to simplify the UI implementation. This solution supports form elements and autorotation as well. If I have to come up with an imaginary name for the pattern that would be Collection View View Model (CVVM) architecture.
Generate your own architecture name with: iOS Architecture Generator
Oh, one more thing:
It works on tvOS, macOS & iOS too.
You can share the code between your iOS, tvOS and even macOS application too. I made a neat little trick to elimiate the borders between iOS and macOS collection view cells / items, also I made a wrapper around UIKit / AppKit types and defined elements like AppleView, AppleImageView insteadof NSView or UIView. This is what going to happen eventually with AppKit & UIKit for sure.
Handling async code should not be a pain in the ass. With promises, it's so much easy to tackle down the issue. That's why CoreKit has a built-in promise type. You can always go with Operations if you want, that's also an option, but please, never ever try to manually handle async method callbacks / completion blocks, that's usually gona result in a pyramid of doom.
This one is a though one, Alamofire is the de facto standard if someone is talking about http networking in the iOS ecosystem. However developers are creating new levels of abstractions - like Moya - over the Alamofire framework. This is because Alamofire only provides convenience methods over the NSURLSession APIs. Let's face it, the most popular networking library is just a syntax sugar with some little extra spices like multipart form data encoding. Which is super, but it still won't solve the main problem: how to create a network stack in an iOS application? Where should I put the base url, how should I store "global" server parameters for each request? This is the exact problem what the network stack in CoreKit is trying to solve.
CoreKit is not just a framework, it'll will help you making apps with various tools.
App icon generator for Apple platforms.
The problem is that usually you have to provide the same icon file in x sizes inside an asset catalog. Are you tired of manually resizing app icons? You will definitely fell in love with this icon generator tool. Everything that you'll ever need to know is written in the manual entry, so don't hesitate to man iconer or iconer --help!
Build phase manager for Xcode
I use build phases to generate app icons with iconer, link the resources for a given target, generate documentations and to bump the build number count. There are many build phase scripts and snippets around the web, but there was no common "package manager" for these build scripts. This is why I made Xphase.
The future of CoreKit
As you can see this is just the beginning, CoreKit is a work in progress project of mine, and hopefully it'll reach the initial 1.0 state in the near future. I'm constantly looking for contributors, so if you like the idea behind the project - or found a bug - please don't hesitate to contact me.