How to handover an iOS project that creates views in code?

Question

I'm training the new iOS developer who will replace me. However, the majority of views in the project is created with code (using a library to make Autolayout more concise). There is no storyboard in the project and the process of starting the app is also in code (AppDelegate).

This makes the handover more troublesome as I know that the new developer will have a hard time tracing which classes I used for which UI elements, especially the one who is not familiar with it.

1) How should I make a document for the project which views are built programmatically? Currently I just took bunch of page screenshots in the app, ordered it in a flow, and put a class/file name on it.

2) Also, are there any suggested way or patterns to arrange the code so that the project built without using interface builder is easier to reason about?

Answer 1

It sounds like you've documented which view goes with which class and which source file. Pictures with a flow is a pretty good way to do that. It would also be important to document why you've done it this way, and if there are commonalities between the views what those are and the thinking behind why they are that way. Knowing your thought process may be more helpful than knowing the specifics of any given class. I often find that I understand a source base much better after I've figured out how the previous owner of it thought. It makes finding things in the future easier, too.

For arranging the project, I'd probably use Xcode's Project Navigator pane to arrange the source into related folders. For example you might have a view that has several options that lead to different sub-views depending on what the user presses:

Foo -> Bar 1 -> Baz 1
   \-> Bar 2 -> Baz 2

I'd arrange the files into folders something like this:

Foo
 +- Bar 1
 |  +- Bar1.mm
 |  +- Bar1.h
 |  +- Baz1.mm
 |  +- Baz1.h
 +- Bar 2
 |  +- Bar2.mm
 |  +- Bar2.h
 |  +- Baz2.mm
 |  +- Baz2.h
etc.

Answer 2

It's a good idea to have a comment at the top of each source file explaining what the code in each source file is good for, and what you would have to do as a user of the application to execute this code. You'd think that is common sense, but surprisingly often it isn't there.

And then what you did: Have a screen shot for each user interface class, with the name of the class, and a document telling other developers how you go from one screen to the next, that's not bad at all.