RequirementsIt starts with the customer telling you what they want in the software project. The customer might be a paying customer. Or it might be another department within your company, your boss, or the instructor in your class.
It is important that the customer, whoever they are, tell you clearly what they are looking for. The main avenue for communicating this information is the requirements document. This is a written formal document that lists everything the customer is looking for.
The communication of the requirements document is usually followed up with a face-to-face meeting to settle details and verify there are no misunderstandings.
SpecificationYou or your company will then reply to the requirements document with another document called the specification. The specification will list all the details about how you will accomplish the customer's requirements. The specification will usually be created with conferences and meetings, because it must be detailed and specific; it is rare that one single person knows all the details about design, coding, testing, pricing, customer contact, and so on. Those functions are usually split up among different departments. So the specification document may require a bit of coordination.
The customer will then review the specification and sign off on it once they believe it sufficiently handles all the details they require.
CodingOf course, someone must code the customer's final product. Traditionally, coding does not start until the specification document has been signed off. In the modern world of technology, this rarely works. Instead of proceeding neatly from step to step in this process, we frequently work together on all steps at the same time. All modern companies like Google and Facebook work this way. You can tell if you are looking at an older or more traditional company because they want you to know about SDLC or Software Development Life Cycle. You can tell if you are looking at a more modern company because they are looking for things like Agile.
In Agile programming, there may be a lot of back-and-forth between requirements, specification, and coding. Because of this, the requirements may change while you are in the process of coding. So you have to be ready to change plans at a moment's notice without complaining. This is why the process is called Agile (able to change direction quickly).
TestingEvery software product must be tested. Larger companies usually devote whole departments to nothing but testing. This is an important part of the software process. Without it, you may release a product that has bugs, and this will give you a bad reputation. If your product is not fully tested, it may get bad reviews in the iTunes store (or Google Play) and other potential buyers may decide not to try it.
MaintenanceThis can easily be the longest part of the software process, because maintenance can last many years. Every time Apple changes Swift or Xcode, or the libraries, or a new product comes out (iPad Ginormous?), you may have to change things in your code. Also, buyers will report bugs in your code, and request new features.
So it is important that you write your code clearly, with comments, so next year, when you are trying to fix a bug, you can remember how your own code works. You'd be surprised how easy it is to forget what you were doing after you've not looked at your code for a while.