#swiftbysundell

Having dealt with concurrency and data synchronization issues in the past, I’m always interested to hear how other folks approach that problem set. With that in mind I checked out Swift by Sundell Episode #95 “Concurrency orchestration” with special guest Brent Simmons. I usually keep these notes in order of the discussion in the podcast, but I’ve reorganized this time to keep related topics together. 

~~~~~~~~~~

Concurrency

You usually want to be pushing background work onto a serial queue.

Want to stay on main thread unless there’s a really solid reason not to. Write it the ideal way. If you see a blocker, use profiler and see what’s the root cause.

Identify things that need to go in the background and make them self contained (example rss parsing, parsing data and turning into model object). During parsing you shouldn’t be doing anything that could affect the rest of the app. Put the work on a serial queue and callback on the main thread.

The fact that something is on a background thread should not leak. Send the operation to the background queue, then callback at the end. Don’t have the background thread sending notifications or doing other things that leak knowledge that it is background work.

Threading leads to so much uncertainty and problems. Reducing areas of moving back & forth makes your code more resilient.

Try giving structure

Going from main to background to another background can be okay, but consider treating it as a stack and moving data back up rather than cutting straight back to a previous queue/main queue.

Thread safety

Sharing mutable data across threads is setting self up for crashes or data inconsistencies

Databases

serial queue for reads & writes that calls back onto main queue

Keeps changes ordered

Always calling back on main thread

Apple tends to callback on thread work performed on.

URLSession does work on background then calls your callback also on background.

Can lead to data races, or calling UI APIs from background threads.

Need to look out for these and make sure UI work is going back on main queue.

Can write code such that you accept a callback queue but have it default to main so you can choose a different queue if necessary.

Performance problems on main thread

Many developers tend to drop to work to background threads before profiling to know where the issue is coming from.

Not everything can be solved with concurrency. The problem might manifest as a lot time in a function, but a background thread might be a bandaid rather than solving the issue.

Senior developers

Role is to find simpler solutions, find the simplest way to create a performant experience, not complicated code.

Brent Simmons project - NetNewsWire

Open source project. 

Originally Mac only (project started pre-iPhone). Rewritten in 2014. 

Created version of the app using SwiftUI & combine only, did not ship since performance wasn’t where they wanted things to be, but held onto that code. 

They are using a couple pieces of SwiftUI in shipping app, but mostly waiting to fully shift over to SwiftUI

Mac vs phone SwiftUIMac performance noticeably less than on iPhone. large reason chose not to switch over to SwiftUI after investing time was degraded performance on Mac

Anyone can join the open source development of net news wire:

Check the app out

Check out the GitHub

Join the slack group and “work” channel

Talk about what you’re interested in building or ask for a bug to work on

Concurrency for NetNewsWire

objects are never mutable on main

Has a single background queue for database operations

Status objects (read/starred) is reference object created & mutated on a background serial queue

Any thread can say to update the “read” status, but that “read” status is only ever updated on the one synchronized queue.

Reflection

How are you handling threads in your project?

Does your background work callback on background or main?

Is your background thread sending notifications or other things that leak background status?

This week I wanted to learn more about SwiftUI and dove into “Swift by Sundell” podcast episode 91 "Is SwiftUI ready for production?” with guest David Smith, available on most podcast providers and online.

~~~~~~~~~~

It isn’t a question of “Is SwiftUI ready?”, but “Is your app able to take advantage of it?”

Working with SwiftUI

Parts that aren’t great:

Some layouts are hard to do

Usually when model bleeding into view, or views that are distant siblings that need to know about each other

Look to redesign to make them parent child or find a diff solution

If you find yourself thinking about using the preferences system probably want to take a different approach

Can be tricky to make separate view the same height/width

Trade off of investment vs productivity - guest is finding it a net win on time to get UIs built

Live changes vs build & run very impactful

Customization of Components

Can be hard to customize built-in components like a list. How do you approach? Is there a concern changes to work around will cause breaks?

You have slightly less control than in UIKit

Embrace default behavior - easier to maintain, will behave more closer to how users will expect based on components similar to it 

If need to make a custom component, break it down into atomic SwiftUI views

Try to not implement uikit in same views because leads to brittle code. Avoid mixing code in a way apple isn’t testing and can’t guarantee will continue to work how you expect

If you need complete fine grain control, SwiftUI may not be the right tool

Getting to a place where it’s a bit more like web design you can’t make assumptions about window size or text size - just like we cannot at this point make assumptions about screen size or text size and need layouts that can handle variation.

Data Management and Movement

What are good ways to model complicated set ups i.e. Sharing data and constructing view hierarchies?

State needs to be shared between views

Guest: A lot of singletons - shared observable object that are for a particular domain. On change updates anyone subscribed to that domain.

Reading from external data sources into an object and view just needs to pull from that object for updates

Think of redux style shared data store - singleton of state that’s subscribed to for changes

Build hierarchies that each manage a piece of that shared state, try to scope them so they don’t leak to places they aren’t necessary 

Try to have leaf nodes used used on the hierarchy not aware of the state objects instead having them passed data by their parents. 

Screens vs views - screen is aware of data source and unwraps optionals and passes data to the views - That way can experiment with cases by passing data to views in preview.

Only put things in the environment object that are truly global, think about the app level - Something like an image loader you use everywhere could be in environment. 

Interoperability 

Are for putting SwiftUI into uikit project but not moving the other way

Try to give SwiftUI the simplest Lay-out possible

If resizing needs to happen (such as for text), try pushing that to SwiftUI 

Lets you do changes piece by piece and experiment before moving completely to SwiftUI