I'm wondering how other people approach the problem of working on a particular screen in an iOS app that is, for example, behind a login screen and requires a lot of interaction to navigate too. It can make the development process quite long and tedious. Every time I tweak a part of the UI I must then build and run, login, navigate to the screen, check the result, then repeat until it is correct.

One approach is to add temporary code to the app delegate that sets the view controller currently being worked on as the root view controller of the window, then deleting this code once development of the view controller is complete.

However I feel like others may have a more effective approach than this.

1 Answer 1


The general principle to follow is to rely on the User Interface surface (UI) only for data input, and to push as much functionality as possible out of the UI into non-UI classes so that they can be automation-tested independently of the UI.

Architectural patterns such as MVC and MVVM facilitate this process by providing a sensible structural framework to enforce the necessary separation of concerns. More specifically, they separate content from presentation.

Following these principles reduces your UI testing to simply verifying that the proper data is passed to your underlying classes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.