7 Things you must absolutely do before writing an iOS app
I have been writing production quality iOS apps for two years now. I know most of us developers have a tendency to jump straight into coding the core logic of the app, as that’s where the fun lies.It is boring to follow processes.
I have learnt the hard way that if you devote some time upfront to setup your project correctly, you would save tonnes of time in the future. You might not realise the importance of some of the below mentioned steps if you work as a solo developer. Most of the great apps are developed by teams and the following steps would certainly reduce the frustration of your team and increase the quality of your app.
1. Setup the coding style guides for your project
Coding Style Guides refers to the style and conventions to follow before coding in a specific language. It includes things like whether to use tabs or spaces, how to name variables or some conventions specific to a language(like in Swift whether to use Classes or Structs). There is no right or wrong coding style. You can setup your own style before starting with your project but remember the entire team needs to follow these guidelines. These guidelines will help to make your code more uniform and easier to read.
Some of the companies have open sourced their coding guidelines for Swift and objective-C.
2. Decide on your app architecture before writing code
It is very important to fix the architecture for your app before jumping to a code. A good architecture will make your app more testable, easier to understand and reduce it’s maintenance cost. You can either follow the traditional MVC architecture or the more fancier architectures like MVVM or VIPER. There are tonnes of resources on the web describing these architecture.
3. Setup your app folder structure
To keep all those hundreds of source files from ending up in the same directory, it’s a good idea to set up some folder structure depending on your architecture. For instance, you can use the following:
├─ Models
├─ Views
├─ Controllers (or ViewModels, if your architecture is MVVM)
├─ Stores
├─ HelpersFirst, create them as groups (little yellow “folders”) within the group with your project’s name in Xcode’s Project Navigator. Then, for each of the groups, link them to an actual directory in your project path by opening their File Inspector on the right, hitting the little gray folder icon, and creating a new subfolder with the name of the group in your project directory.
This may seem a minor thing but this will certainly make your app more structured and easier to understand.
For more on this checkout this resource.
4. Dependency Management
You will certainly use some third party libraries in your app. There are three important ways in which you can manage dependencies in your project.
CocoaPods
CocoaPods is the dependency manager for Swift and Objective-C Cocoa projects. It has almost ten thousand libraries and can help you scale your projects elegantly. It is the most effective way to manage dependencies similar to Ruby Gems in approach.
There is a hilarious youtube video by Google Developers explaining why you must use CocoaPods in your projects.
Github Submodules
You can also use git submodules to organize your dependencies as sub repos in your project. The advantage submodules have over Cocoapods is thatsubmodules are sub-repos — not only does this mean that git and git GUIs implicitly recognize them and more and more support easily working with them, it also means that your dependencies stay connected the wonderful world their git repos, Cocoapods or not, reside in.
The problem with git submodules is this: your project doesn’t have the source for code you depend on. It only has a reference to the submodule’s repository. And most of the time you don’t even control that repository.
Carthage
Carthage is intended to be the simplest way to add frameworks to your Cocoa application. Carthage builds framework binaries using xcodebuild, but leaves the responsibility of integrating them up to the user. CocoaPods’ approach is easier to use, while Carthage’s is flexible and unintrusive.
Unfortunately, there is one big disadvantage about Carthage — Only support iOS 8 or later.
The most used of these three and my personal favorite is Cocoapods as it is super easy to setup and offers you access to thousands of third party libraries.
5. Setup Proper Schemes for your app
Schemes tell Xcode what should happen when you hit the Run, Test, Profile, Analyze or Archive action. Basically, they map each of these actions to a target and a build configuration. You can also pass launch arguments, such as the language the app should run in (handy for testing your localizations!) or set some diagnostic flags for debugging.
A suggested naming convention for schemes is MyApp (<Language>) [Environment]:
MyApp (English) [Development]
MyApp (German) [Development]
MyApp [Testing]
MyApp [Staging]
MyApp [App Store]You can also use Targets to produce different Production, Test and Devlopment builds of your app as described below.
6. Setup Proper Certificates and Provisioning Profiles
This is one of the most painful and important steps required for testing and distributing an iOS app. Certificates are required for code signing so that you can run your app on an actual device.
There are two types of certificates:
- Development certificate: Every developer on a team has their own, and it is generated upon request. Xcode might do this for you, but it’s better not to press the magic “Fix issue” button and understand what is actually going on. This certificate is needed to deploy development builds to devices.
- Distribution certificate: There can be several, but it’s best to keep it to one per organization, and share its associated key through some internal channel. This certificate is needed to ship to the App Store, or your organization’s internal “enterprise app store”.
Provisioning Profiles — Probably the most confusing component in the system, a provisioning profile indicates the devices for which an application is correctly signed. If you visit the developer portal, you’ll notice you can create two types (again called Development and Distribution). Provisioning profiles say “applications with this Identifier signed with this Certificate’s private key are okay to run on these devices.” : https://www.quora.com/What-are-the-differences-between-certificates-provisioning-profiles-and-identifiers
You can read more about these by visiting the following links.
7. Setup a Continuous Integration and Delivery Process
Setting up a continuous integration and delivery process has become critical nowadays as it helps you to squash out bugs early in the development cycle and saves a lot of developer time.
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
There are a lot of tools available that can help you with continuous integration of iOS apps like Xcode Server, Jenkins and Travis CI.
Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently.
Why use Continuous Delivery?
1.Save days of preparing app submission, uploading screenshots and releasing the app
2.Colleague on vacation and a critical bugfix needs to be released? Don’t rely on one person releasing updates
3. Increase software quality and reaction time with more frequent and smaller releases
Although there are a lot of tools available for continuous delivery my personal favorite is Fastlane. It is super easy to setup and offers some powerful features that can automate your entire build and distribution process.
Want to learn more about iOS and Swift enroll in this Swift Development Course available on discount for a limited period.
If you liked this post recommend it so that others can enjoy it as well. Subscribe for more such articles on my website.
