Yi-Ning's Note

Creating a staging app

January 17, 2019 | 4 Minute Read

After the first released of DiscoverNP, I switched my role at my day job to mobile engineer. I learned a lot about app development in the last three months. I am happy that I learned about some good practices in iOS app development, but also super sad whenever I want to work on DiscoverNP.

Every time I open the project, I want to rewrite the whole app. It might help me in the long run to build more new features faster, but it will take me a long time to build exact the same thing.

During the holiday break, I finally have a week to re-write it!

Rewriting a whole app means that I have to test EVERYTHING. In addition to that, I already release the app. This means testing on my or testers’ phone can corrupt the data (in this case, visits record) on their phone. It is a messy situation - I want to test my app, but I don’t want it to have anything to do with the one I downloaded from the app store.

Solutions

  • Have some logic to use a different data store when testing, but this make the code very messy with testing logic in it.
  • Only test it on the simulator, but I still want to test on actual device.
  • Get another phone to test it, but do I really need to go this far?

Maybe I need a staging environment?

Staging environment

During the software development process, building, running and testing the software are usually happen on our own machines. After the software is ready to use, we can ship it to “production” environment. This sounds okay, but what if the data on the production environment does not work too well with our software? What if the production machine has a different configuration than our machine?

For these reasons, most of companies have the software run on different environments before shipping it to production. This does not mean every software has to have different environments. Some places I worked for have both testing and staging environment, some of them have at least one of it, some of them have none. For hobby project, we usually do not really need it.

What is staging environment anyways? It is running the software we are about to release with a copy of the production data. However, it is expensive to have a staging environment. Therefore, a lot of places use less realistic production data. The goal is the same - trying to be as close as to production environment to make sure the newly released software will work as expected.

Staging app

Because of my experiences with web development, I am familiar with using staging environment in the development process. Maybe I can build a staging app - which is very close to the production app with testing data.

I decided for DiscoverNP, I am going to build a separate app that has the same code. This way, I am using a different database. The data in my production app will not be touched at all. All I need to do is to create a new target in the project.

Create a new target in the XCode project

  1. Select the project file, right click current/production app target. Click “Duplicate”
  2. Rename this target to some other name, Provide a different app icon so it is easier to identified it is a staging app
  3. Building and releasing staging app by selecting your staging target

After creating the new target, make sure newly created files are available for both target.

This approach is great because I can now add different logic into the staging app and it will be separated from the production app. For DiscoverNP, I’d like to test my staging app without going to a National Park. I want to test my app when I go to work, or visit a city near me. I create a data file that is only available for staging target to have list of cities in the SF bay area.

For app worked with web API, it is helpful to make the staging app pointing to the staging server. Or even better, you can make it configurable in the setting section of the staging app. I’ve using this approach at my work to help back-end engineers to test the app with their local and staging server. It works pretty well!