An app I'm making to help people (mainly college students) split bills easily in groups.

• A beautiful and fast UI. It bothers me that it's 2018 and even with the ridiculous amounts of RAM and CPU power we have, users have to wait for software to catch up to them, when it should be the other way around. See this article for more. Anyhow, Splitty doesn't face this issue. It's a simple app, but I made sure it was blazing fast and very simple to use.
• Core Data for local object graph persistence. Splitty uses Core Data + a custom lightweight abstraction I wrote (see Database.swift) for all its local database work.
• Super nice custom UIControls and UIViews. Splitty required a few UI components that don't exist by default in UIKit, so I made them using UIControl. To see the controls, check out ToggleControl.swift and ToggleLabel.swift. Both of these controls were developed to look and feel like they're part of iOS. They respond to touches and highlights the same way the rest of the UIKit controls do, and they provide a high degree of customization, so they're reusable across other apps. Along with those, there are a few UIView subclasses in the Views directory. I broke all non-IB views out of view controllers and into custom UIView subclasses to keep my view controllers clean.
• Good software design and clean code. This should be a given, but it's worth mentioning anyway. I used SwiftLint throughout the lifetime of the project to make sure I was following all the right Swift conventions. On top of that, I made my code as Swifty as possible, and I took full advantage of the language's many features like protocols, error handling, higher order functions, etc. On top of that, I made sure to follow general software design principles like DRY and KISS to keep the code as clean as possible.

• Total calculation. The working list should have a footer view that shows the current subtotal of the list, along with a button to save it.
• Saveable lists. Users should be able to save the list they're working on when they're done with it. When they save it, they should be able to give it a name, and the list, along with its name, should show up in the "Past Splits" tab.
• Editable items. Users should be able to click on an item in the current list to view its details and edit it.
• Details for past splits. When users are looking at their past splits, they should be able to click on one to see the items in it.
• Barcode scanning. Currently, users have to enter all product info manually. I want to implement barcode scanning using AVFoundation so they can scan the UPC of a product and have its information auto-populate. The app should also track any changes they make to this information and persist them for future use.
• Empty states. Table views should show some kind of message (and in some cases, a button) when they have no content to display. This should also apply to the list of people that's shown in AddItemManuallyViewController.
• Group lists. Users should be able to connect their phones together using Multipeer Connectivity so they can all work on the same list together.

• Localization and string constants. Splitty currently has string literals strewn all over the codebase to set values for UI elements. I want to replace this with a Localizable.strings file soon. Currency values are already formatted using NSCurrencyFormatter, so they should be a non-issue. However, I'm unhappy with the way Models/Item.swift currently formats the names of its members to produce displayable strings like A, A and B, A, B, and C, etc. I want to clean this up and use something more generalized and localizable.
• Custom view and control configuration. Splitty has a few custom views and controls. I decided to move all of the logic for creating constraints to create more complex views out of view controllers to make reusable UIView subclasses instead. I'm unhappy with how I designed those subclasses to allow configuration of the more basic UIKit elements they're composed of. Most of it is currently done using didSet hooks and by using get {} set {} to wrap around the real values. I want to fix this and make custom view and control configuration more sensible.
• Core Data on the main queue. So far, I haven't moved any of Splitty's Core Data work onto background threads. This is mainly because the amount of data involved so far has been very small. There are no image files or binary data being stored, and most users' entire databases will probably be < 50K bytes. However, if any features require it for performance reasons, I want to move Core Data work to the background thread.
• Better abstractions for constraints. I've avoided external dependencies like SnapKit in favor of Auto Layout anchors. At first, they did a great job at letting me set up constraints with minimal boilerplate, but as the constraints in Splitty grew a little more, I feel more like I need to create some kind of light abstraction over Auto Layout to reduce the amount of code necessary to build constraints.