@Tiberiu891 pointed the problem. You should be careful when adding items to the toolbar. The same instances added several times cause this strange crash. Here is an example: NSMutableArray* items = [self.toolbar.items mutableCopy]; [items addObject:self.fixedSpaceButton]; //... [self.toolbar setItems:items]; The correct way doing this is: NSMutableArray* items = [self.toolbar.items mutableCopy]; if(![items containsObject:self.fixedSpaceButton]) { [items addObject:self.fixedSpaceButton]; } //... [self.toolbar setItems:items];

The problem was in the available permissions. The solution: You need these additional capabilities. (In the case described above, I had only one - EDU Assessment Mode, which wasn't sufficient).

It's obvious - with SwiftUI we should drop the C from MVC, but still we should keep the business logic somewhere. Let's try to reason where is the best place? (We are developers working on a moderate iOS project - not a small one, but not something huge.) in the view? - No. (Too many reasons to avoid it - complex views, unreadable views, hard to unit test, etc.) in the model - Probably. in the controller - No. There is no controller in SwiftUI. Otherwise we need some place which we can call whatever we want. (Some people prefer to use "ViewModel". Please, don't mess this with MVVM design pattern.). Another generic problem that we should solve - caching (because we fetch some data from a server and we store it on the device, while the app is running, or even persist it between different sessions.) Also this data may be updated from time to time based on other users (imagine a chat functionality in an app). Who should be responsible for storing that data? It's not the view. It's not the controller. Guess, who? - The model. Well, if we continue the same way, the model is not anymore a typical model (closer to POJO) - it's growing and getting wiser and powerful (and massive :D). Which leads to some sort of separation if we want to make our codebase maintainable. In summary - if the project you are working is growing then you have to introduce something that will make it easier to grow. It's up to you to pick the right tools. MVVM or something similar might be an overkill in the beginning of any project. But at some point partially using any architectural Design Pattern (or just the good bits) will solve a lot of problems.