Skip to content

Apps Dissected Posts

Catch SwiftUI model updates from bad threads before they crash your app

It hasn’t yet been reflected in the official SwiftUI documentation (yay, betas), but the WWDC presentations and further guidance from Apple engineers have made it very clear about one point of SwiftUI: as with UIKit, you must send SwiftUI updates only from the main thread. The more things change…

The bad thing about this is that if you don’t make your updates on the main thread, you get away with it.

Most of the time.

The reality: updating the UI outside the main thread — in UIKit and in the newer SwiftUI — is going to be a source of hard to debug bugs, possible race conditions when updates are made to the UI, and at worst, app crashes.

Your BindableObjects may have many attributes, all that require you to do a willChange.send(). With so many places where your asynchronous code may need to trigger an update to your Views, what can you do to catch those missed main thread migrations before they become headaches? Xcode can save your sanity with its built-in Main Thread Checker debug functionality. Let’s walk through a basic example.

Order your Core Data entities the right way for maximum speed

One of the earliest things you learn about Core Data is that it doesn’t support ordered entities out of the box. Sometimes you can have an ordered relationship, but the minute you try and move that database to iCloud, you find that ordered relationships aren’t supported. Long story short: if you want to order your entities, then you need to create an index attribute that allows you to sort your entities yourself.

So you do the natural thing: create your index attribute as an Int, and then assign each in order: 1, 2, 3…

This is fine if the data doesn’t change, but if this is data the user can add to and reorder, what if they want to move element 3 between 1 and 2? It means you need to change 2 entities in addition to adding the new one. What if there are 500 entities, and the user wants to insert a new first element. 500 entities to change because the user moved a single entity?!

There must be a way to insert and reorder IDs that avoids all of this rewriting, right?

Thankfully there are a couple of techniques you can use that will almost completely eliminate the need to rewrite a huge number of entities every time you need to insert or rearrange entities. Let’s talk about them now.

Frustrated by missing features in SwiftUI? Using UIViewRepresentable to wrap UIKit controls

When the SwiftUI announcement came out at WWDC 2019, you were buzzing about the new framework. Finally, a new way to build our interfaces. Out with ViewControllers, out with storyboards, in with declarative, programmatic UIs!

Now that we’ve all had some time to play with the framework, we’ve found out what we’re really trading away when we use SwiftUI, at least for now. One of the major things? The vast array of components and configurability available through UIKit.

You’ve probably found through experimenting with the new framework that there are things missing. Entire UIKit components are missing, and things like the broad number of properties you could set on TextFields, and the common pull-to-refresh control are missing.

You really don’t want to continue down the UIKit road. You want to go all in on SwiftUI now; it’s the future of development for all Apple platforms. “But how am I going to get back these features?”

This is where UIViewRepresentable comes in. Apple knew that SwiftUI was not going to be a complete port of UIKit for its first version, and so they provided this protocol which you can implement on a View struct to wrap a UIKit control, making it usable in SwiftUI. Let’s see an example how to use this: getting the pull-to-refresh functionality on a scroll view.

Got an app idea, but stuck on where to start? Here’s a framework to get started and keep going

Once you’ve built your iOS skills up to a certain point, your mind probably starts going crazy coming up with ideas for apps to build. App ideas that will grow your knowledge (like maybe cloning an existing app?), or maybe apps you want to release to the App Store to make some money. Finally, you pick one that you are ready to build. And then you freeze.

You’re thinking: ”I’ve got my great idea. Now how the @*%$( am I going to build it?” Because it looks overwhelming. So many screens to design and code, an app workflow to develop, backend services to connect up, new iOS concepts to learn. But you open Xcode, select New Project, and you don’t even know which new app template to pick.

The blank page problem. This happens when we’re starting an app, adding features, anytime we’re building something new. It’s something big and unclear. There are so many parts, and you have no clue how they fit together. Or worse, you don’t even know all the moving parts in the first place.

Every creative discipline knows this problem well, and all of them have developed various techniques to combat it. Here is a useful framework I use as I’m building a new app or new features for an app to begin and keep filling in that blank page.

Adding manual app badges to your app: step by step

It’s really common for apps that support notifications to use them to update the application badge to display numbers of unread messages, undone tasks, etc. But what if you don’t need or want the added complexity of supporting push notifications, or even local notifications, but want to alert the user via an app badge?

Apple’s documentation on this particular way of using app badges is not the best. Badges are combined with the UserNotifications framework, but if you want to set the badge yourself outside of a notification, that is part of UIKit. And the documentation are missing important points like: do you need to check that you’re authorized to show badges to set the badge manually? Will it error out? Crash? Result in strange app behavior?

Manual app badges turn out to be really easy, but the docs don’t make it seem that way. Let’s demystify them right now.