Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
bahua132611yI admit I know almost nothing about xcode development, but if you're all working on the same files, couldn't you just put it all in a git repo and work out of that?
Let me quote a great article from Medium: "The storyboard itself is a giant xml file. Everything, from where a button is placed, to where you’ve placed the actual view controller (and not even the contents inside of it — just THE VIEW CONTROLLER) is saved in it. That means if your teammate even moves a view a little you’ll have a merge conflict. The moment there is a merge conflict in the storyboard, it cannot be rendered in Xcode any longer. Your app won’t launch. Nothing will work.
Merging these conflicts can be overwhelmingly difficult. You have to make sure the xml is valid, meaning all the tags close. Especially bad when storyboard xml files can be potentially thousands of lines long. The storyboard is obviously not meant for human eyes, and conflicts are terrible since it’s almost random where the change will be, meaning you’ll likely spend hours trying to find that last tag or typo to fix."
In theory everything would be alright if one person does the UI, and another does the logic, but it's not that simple, there are a LOT of pitfalls :( Most efficient method is still copy-pasteing manually from one project to another, and I just can't wrap this around my head that there isn't any professional workflow still that works, so any advice would be appreciated fellas
bahua132611yMaybe a shared screen that everyone can control?
What do you mean? Like some kind of a TeamViewer screen sharing?
@Thorzilla I have been there.
The trick is to make only one dev (prefer a senior) able to make changes to the storyboard.
Add it to the .gitignore file, or use a local git hook to prevent changes to all envs. Only that dev can force add the changes to the remote. You can take turns if team is large.
in case An Idiot pushed an update to the remote - rollback his changes. when pulling - always overide the local version with the remote one.
Write the code first, and then add the sb chages with the sb dev later.
Or throw away the storyboard, and do everything in xib files. or code all the ui. or stop the insanity, and go write an Android app.