<thread>
Yesterday was the official public release of the app @cocoawithlove & I have been developing for around 8 months.
It is a “banking” app which serves the customers of a specific financial institution here in Australia: itunes.apple.com/au/app/apple-s…
Yesterday was the official public release of the app @cocoawithlove & I have been developing for around 8 months.
It is a “banking” app which serves the customers of a specific financial institution here in Australia: itunes.apple.com/au/app/apple-s…
Disregarding the limited utility of the app for most of you, I’d just like to quickly talk about how developing an iOS app from scratch in 2018 feels like.
First of all, the basic architecture of the app: we use MVVM-Rx layered in modules, and the only couple “real” dependencies we have is RxSwift and RxDataSources.
The vast majority of the code is purely functional and reactive. It is a pleasure to read as well as to write.
The vast majority of the code is purely functional and reactive. It is a pleasure to read as well as to write.
Secondly, Swift.
From Value Types to CaseIterable, passing by Decodable, Generics, Auto-Synthesised E&H conformances, Keypaths and the power of its Enums, Swift has become an essential pillar of the code we write.
I love Objective-C, but I would never want to go back.
From Value Types to CaseIterable, passing by Decodable, Generics, Auto-Synthesised E&H conformances, Keypaths and the power of its Enums, Swift has become an essential pillar of the code we write.
I love Objective-C, but I would never want to go back.
The Standard Lib is a pleasure to interact with and feels *almost* complete.
I just wish its documentation was better, e.g. clearly enunciating the constraints on a Generic Type for a method to become available.
I just wish its documentation was better, e.g. clearly enunciating the constraints on a Generic Type for a method to become available.
Xcode and LLDB still have some way to go to become reliable.
Swiftc’s error messages are still very poor and require a lot of implicit knowledge of the language in order to decipher what the compiler is actually complaining about.
The new build system is amazing.
Swiftc’s error messages are still very poor and require a lot of implicit knowledge of the language in order to decipher what the compiler is actually complaining about.
The new build system is amazing.
Finally, UIKit and other related frameworks.
It is _shocking_ how bad & buggy iOS <11 was. Since then however, the fundamentals got robust and behave exactly as expected.
You can (mostly) trust UIKit now, and be confident that any bug is in your code rather than Apple’s.
It is _shocking_ how bad & buggy iOS <11 was. Since then however, the fundamentals got robust and behave exactly as expected.
You can (mostly) trust UIKit now, and be confident that any bug is in your code rather than Apple’s.
I wish there were better Swift wrappers around the ObjC frameworks’ interface. Apart from sometimes adding default arguments, there is so much potential that could be unleashed by having access to Swift-only frameworks.
I am very excited by what may be unveiled in 2019.
I am very excited by what may be unveiled in 2019.
Overall this was, and continues to be, an amazing codebase to work on.
iOS development, thanks to technologies such as Swift and FRP, has come a long way from what it was just a few years ago.
iOS development, thanks to technologies such as Swift and FRP, has come a long way from what it was just a few years ago.
You don’t need a boatload of cocoapods anymore. You don’t need a team of 50 engineers to maintain a bunch of dynamic code and the thousands of unit tests it entails.
All you need is a fresh, modern, trustworthy approach to writing apps. And 2018’s iOS provides that.
</thread>
All you need is a fresh, modern, trustworthy approach to writing apps. And 2018’s iOS provides that.
</thread>
