Even then we need to use typecasts because Swift can’t know that the table view cell it got back is actually a MooncakeTableViewCell.
App interface builder code#
Similarly, when we create view controllers from a storyboard or dequeue table view cells, we use strings to identify important objects in our code – a system so pervasive, it even has its own name: “stringly typed APIs”. As a result, we end up with lots of unsafe functionality: we Ctrl-drag from IB into our code to connect something to an action, but if we then delete that action the code still compiles – IB really doesn’t mind if the code it intends to call no longer exists. You see, Interface Builder doesn’t know much about our Swift code, and our Swift code doesn’t know much about Interface Builder. Sure, they might start off small, but then you add another view controller and another, and another, and suddenly you realize that you have ten screens of data in a single file, and any source control changes you make are suddenly quite painful.īut although being a single point of failure isn’t great, and it’s basically impossible to see what’s changed when someone opens a pull request with a storyboard modification, storyboards and XIBs have a bigger problem. Worse, storyboards have a habit of growing larger and larger over time.
Well, apart from that one time once, but broadly the answer is no – storyboards and XIBs contain a fairly large amount of XML that isn’t easy to read or easy to edit.
Well, let me ask you this: have you ever edited a storyboard or XIB by hand? Still here? That means you’ve used IB before and are probably curious how SwiftUI is different. If you haven’t used these before, you should just skip this bit. They might not like them, but they are at least familiar with them. SwiftUI vs Interface Builder and storyboardsĮvery experienced iOS developer is familiar with Interface Builder and storyboards, and perhaps even XIBs too.
0 kommentar(er)
