iOS Procedure for setting up a new project?

[Jetheat]

I don't know how to code so I don't know about frameworks or anything like that.

What I would like to know is, if a professional iOS development firm was to start a new project, how would they go about setting things up?

Would they download certain libraries or set up some frameworks or make a timetable...

I'd like to know the professional procedure which professional developers go through while setting up a new project.

I'd also like to know how long it takes to set this up also.

After that, what are the first steps to start the work? What files should they create? What stuff do they need to hand?

It would be great to get a step by step procedure regarding this.

I'd appreciate it if someone could detail the procedure.


Thanks,

JH

 

[SomeWhores]

I'll start this off with I'm not a 'professional iOS development firm' or at least I don't call myself that. This is just how i start new projects at work (iOS engineer) and for clients.

Usually I just open up Xcode & select create a new single page application creating git repository and with Core Data enabled. It's simple and really I don't care about any of the boiler plate stuff Xcode will give me anyway since i'm going to change it most likely. Can't speak for game development though.

Second step is to navigate to that projects folder in terminal and run `pod init`. Usually I'll add `AFNetworking`, `GroundControl`, `OCMock`, `GoogleAnalytics-iOS-SDK`, `SDWebImage`, `CocoaLumberjack` & ` BNRDynamicTypeManager` to my `Podfile` since i almost always want or will use those libraries in one way or another.

If i don't have one already, I'll create a remote repository location somewhere like Github, BitBucket, GitLab instance, random server I have, etc. Really anywhere, I don't care, just somewhere else to host my code and push my code up there. If I haven't, I'll most likely update/touch my `.gitignore` file to ignore things like my Pods directory if I don't want all my dependencies checked into my repository.

Next I'll usually setup a Settings.bundle and link my pods update command to replace the necessary files so that inside the Settings.app on the iOS device i have an 'Acknowledgements' tab that pushes to a list of a licenses for the libraries i use. Mostly because I prefer that method of attribution.

I've never timed how long it takes. Hopefully it takes me less than an hour but usually somewhere in there I'll get distracted and start actually working on the project and not just the setup anymore so it probably actually takes a lot longer to 'complete the setup' i guess.

After that I'll just start working on the project. Probably creating my entities in CoreData and all that jazz. Really just kind of depends on what needs to be completed first/laying the 'foundation' (that will probably change later) for the project at that point I guess.

 

[DannyBres]

Can I ask why you want to know?

 

[Jetheat]

Thats great thanks.

Just wanted to know so I can lay it out for developers I plan to hire and give them a timeframe to work by.

 

[chown33]

Thats great thanks.

Just wanted to know so I can lay it out for developers I plan to hire and give them a timeframe to work by.

I'm not sure I understand your purpose.

You plan to hire skilled developers who are presumably capable of developing your app, and you then plan to tell them how to do their jobs, despite you stating in your first post that you know nothing about writing code?

What practical benefit do you expect to gain by telling skilled developers what they should already know? And if they don't already know it, do you expect that telling them will actually make the process work? And how would you know what a reasonable timeframe is? They should be telling you the timeframe, after you give them all the requirements.

This seems poorly thought out no matter what the reason. You either hire competent developers and don't have to tell them how to setup or produce, or you hire fledgling developers and expect to guide them at every step. But you certainly don't do the latter if you don't know anything about producing software. That way madness lies, for all involved.