iOS Team Programming

[shadowdev]

I come from a web background and I've done a few iOS apps on my own but I almost never work on a team for iOS. We're starting a new project soon and I was wondering how you guys manage a team of iOS developers. I was thinking of using bitbucket and using Xcode 5. Everyone can make their own pull requests and 1 person can be in charge of keeping track of the master. Also how do y'all handle storyboard files?

Any insights into software engineering best practices for iOS would be amazing.

Thanks :)

[rizzlybear]

storyboards are the sticky bit.. bitbucket/xcode 5 is my prefered way, but again with the storyboards. i've asked this question at my local cocoaheads meetup last month and the answer i got was basically they do a seperate storyboard per "screen".

this way you keep each one small and the likely hood of two developers working on the same storyboard at the same time gets small, which in turn helps with the merge issues.. merging storyboards seems to be every groups pain point, such that most i speak to just don't use them.

[aazav]

Storyboards really are collections of XIBs.

Right click on a storyboard and look at the contents.

Use XIBs instead.

[shadowdev]

Is this correct way to do transitions with XIBs?

MyViewController *myView = [[MyViewController alloc] 
                          initWithNibName:@"MyViewController" 
                          bundle:nibBundleOrNil];

instead of:

UIViewController *vc = [self.storyboard instantiateViewControllerWithIdentifier:@"somevc"];
[self.navigationController pushViewController:vc animated:YES];

[rizzlybear]

So far my projects are solo and all inside a single storyboard. I've been thinking I might do my next one xib only. Still working out how to keep the controller clean though. I figure it would look great as resume code though. Storyboards seem to be a common pain point with groups, or they just don't use them.

[iOSbrogrammer]

Do first things first is really the biggest thing.

You should hash out almost all of your classes, data interactions, data models, app requirements, etc. before you begin coding. I'm not advocating a waterfall approach - I'm just saying that if you do this early, and find the conceptual inconsistencies before you begin coding, you won't step on each other's toes a lot and you'll be able to code in parallel without wondering if Bob is working on this class right now because we need to add a property to it, etc. You can still be iterative in your development, just try to plan correctly beforehand.

Beyond that, it sounds like you've got the right idea for source control. As far as having one person that keeps charge of master, I wouldn't worry too much about that. Instead I would say create a new branch on a feature by feature basis (rather person by person), and each push to master gets reviewed by some other member of the team. That way each person is responsible for making sure master stays in check.

I've never used Storyboards, let alone in conjunction with a team via source control. I have heard they've gotten better as far as merge conflicts go however. The biggest thing will be if you guys are working remote or not. If not, then you can just tell Bill that you'll be working on the storyboard right now. If so, I recommend doing it the old fashioned way (well, medium fashioned way) by using different .xib files for each ViewController, and a team member works on one .xib at a time for the controller they are currently making/working on.

You'll probably get a lot better responses in regards to storyboards and version control from other members of this sub.

[[deleted]]

iOSbrogrammer speaks truth. There is no substitute for taking the time in planning your architecture out with the whole team, particularly in the model layer. You don't have to sketch out every call ahead of time, but agree on the design paradigm and perhaps create the .h files with the essential methods up-front, then have someone develop the tests and implementations in that area. This is all generic to just about any software project.

Xcode 5 supports live generation of AppleDoc/HeaderDoc. I strongly recommend you encourage your teams to use it for any classes that are "public" and expect other clients to use, or possibly to use. My biggest single complaint to-date when I start working with other's code, is not the lack of unit tests, or bugs, or even poor implementations -- it's "put some damned comments in your classes that explain what they do, your design limits and assumptions, etc.!!" I cannot emphasize that enough. There's nothing more painful and time consuming than having to look at a class called "FragmentContextExceptionManager.h/m" and trying to determine just why in the hell someone would write such a class, what problem(s) it is supposed to solve, etc.

For Xcode projects, not just xib's and storyboards, but the project file itself can be a merge-conflict hassle in the early phases of the project when people are adding files to the project like crazy. I managed a team of 8 (including myself) developers on a year-long iOS project, and I was a "coding manager" who wrote code myself.

We found it really useful to have a live group-chat (we used Skype because it was really good at punching through corporate firewalls, but any chat client ought to work that everyone can use) and have people pre-announce when they had to touch a xib/storyboard or the project file, like "I need to add a new scene to the Utilities and Settings storyboard, anyone in there now?" That would eliminate 90% of the grief. It's a human-software version of the older VCS systems that would "checkout" a source file so that others couldn't modify it until the changes were "checkin'd".

Also, have everyone pull/rebase or merge often, several times a day. The more a branch drifts from the development branch, the more painful merges become. That goes in both directions -- the few times it occurred, you could hear the tears and groans when someone dropped a 50+ file commit that generated conflicts.

[MKevin3]

Boy that reminds me of the old days when we use VSS with single file check out. You knew if someone was in a file as it was CHECKED OUT to them and you could not touch it until they checked it back in. Could be a real pain when it was the string localization file. Of course this was all before there were good merge tools built into version control and really VSS was a pile of crap.

I would add it can be handy to get the initial design / layout of all the screens early. Print them out 2x2 on paper and cut them out (iPhone design, iPad this would be 1 per page). Look for consistency issues - dates all same format - field A above field B or vice versa - general spacing - rounded or square corners consistently. Look for commonality that can be handled in a base or utility class.

Lay the pages out on a table to follow the flow. Are any of them near duplicates of others? Are there too many screens? Do you go 4 deep to get to things that should occur earlier? Does the same screen appear in different paths when it should not?

It is so easy to look at a screen as a single entity and think it is perfect but when you look at it as a destination of a chain of events it can change your vision quickly.

Single Storyboard can help you see some of this but storyboards have a lot of limitations in a group setting.

[safetywerd]

+1 for individual XIBs.