Skip to content

Category: UIKit

Keep control of your modal presentation in iOS 13

You hear about the large features in new major version iOS updates, but it’s often the small changes that cause you headaches: the places where Apple has deprecated functionality or changed defaults that you’ve been relying on for years.

iOS 13 has one of those major changes with respect to how modal ViewControllers are displayed. They are now displayed in a card format by default. That itself is not overly problematic, but as part of that change, it also enables the user to dismiss a modal by swiping down from the top of the screen.

If your app expects that it will have full control over being dismissed, this could be a major problem. Suddenly, your login form that you are displaying with a modal can just be swiped away, leading to unexpected behavior: crashes, unpopulated screens, access to things a user shouldn’t have access to.

Building with the old iOS 12 SDK is an option — for a while. How do you restore that classic functionality, making your modals fullscreen by default, with full control over how they are dismissed? Thankfully, it is not a hard fix, but the fix depends on how you are presenting your ViewController. Let’s cover all of the different fixes now.

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.

How Do You Get the Data From Your Custom UITableViewCells?

You don’t need to progress very far into iOS development before you need to deal with tables. This means: UITableView, and probably your own custom UITableViewCells. A common pattern is to have editable controls in those cells, so that the user can change data from the table itself. Now you’re faced with a problem:

How do you transfer that data back to your UIViewController so the app can use it?

You know how to do this with standard controls, like UITextFields, UIButtons, etc. But you have a UITableView with a bunch of UITableViewCells. They don’t really behave the same way:

  • They’re dynamically constructed by your UITableView
  • There are a variable number of them (usually)
  • Getting access to them from the UITableView is not easy
  • You don’t treat them the same way as “normal” UIViews, such as hooking them up using outlets in Interface Builder

But tear all this away, and your UITableViewCells are not special snowflakes, they are UIViews just like any other. You should treat them exactly that way. Then the answer becomes simple: you do the same thing that Apple does in their UIViews: use delegates. Here’s how.