One of the standout trends from WWDC20 was the addition of sidebars in iPad OS that are reminiscent of the ones found on the Mac. These provide a more optimal way to use space on the iPad, feeling substantially better than a tab bar. With the ability to show and hide the sidebar depending on context, you can both create excellent navigation and maximise screen space usage without losing any convenience on the iPhone.
When building modern applications, things tend to move quite quickly. When you add multiple developers to your team, things really start to get going. With enough developers, you’ll find you have multiple in-progress things, that aren’t quite ready for production. How do you let the developers keep working at their most efficient speed, whilst keeping your app in a constantly releaseable state?
Enter feature flags.
You’ll have heard the term feature flags before.
Here, I’m referring to the process of having a feature ( and all of its code ) hidden behind a flag that can be enabled on an app build. You may choose to allow developers or testers to adjust these at run-time, but the important part is that you can have a hard off for features that aren’t quite ready for production. …
With WWDC20 taking off on June 22, and alongside it the betas of the next operating systems, now is the time to get ready. We can only guess at the sorts of things that Apple may add in iOS 14, but that doesn’t mean we cant get ourselves into a good position for whatever it is.
Here are a few things you should be doing to be in the best possible position — and how you can do them.
Dark mode is the biggest user-facing change that we saw, bringing a system-wide appearance that satisfied the night owls among us. Implementing it can be extremely easy, and it gives you a chance to refine your assets, removing duplicate colours as you make new ones that can respond to the system-interface mode. …
SwiftUI is really flexible and offers more than one way to customise your views. It lets us lean on Swift to really push the declarative syntax and create slim views.
We’re going to look at three ways to do the exact same thing: customise some text to match our company's branding. This header text will be used throughout the app in various places.
One of the simplest ways to customise your views is to simply make custom ones. You can break down your views into small chunks with all their properties pre-set and then reuse that wherever possible.
This pattern can be repeated throughout your app to compartmentalise everything, helping debug views and move things around if you want to change them later. …
Swift 5.1 gave us property wrappers that allow us to replicate the functionality we could get from keywords ourselves. If you’ve had a play with SwiftUI, you’ll find these everywhere, with
@EnvironmentObject being key to development.
To help get you started using property wrappers in your app, I’ve put together a few non-SwiftUI examples that have improved my workflow.
Fetched takes the pain out of setting up fetch requests and
NSFetchedResultsControllers and replaces it with a single addition to your variable declaration.
Instead of writing a service or cluttering your view models with core data logic, you can just add
@Fetched to a variable and have it automagically sort itself out. …
Since the advent of Codables, we’ve been edging closer to a completely typed networking solution built into Foundation. Whilst our models are now safe, our requests themselves typically still rely on strings and very manual parameters, leaving us open to developer error.
Even the best of us make mistakes, let’s be honest.
A considerable amount of time could be spent debugging these errors in a large project, which could be better spent on new features. To lower the risk of this we’ll need to turn our route data into something typed.
The concept I’ve always worked with is that a router performs a
Route, and returns a result to the service, or view, that wants it. …