App Design & Development Planning Part 2

In the previous section, we covered User Experience Design, User Interface Design, Functional Design, Technology Selection and Mapping to App Features.

In this section we will cover the following as the second half of the design and development planning for your App:

• Build Phase
• Alphas Build Phase
• Beta Build Phase
• App Store Submission
• Maintenance

Build Phase

The build phase of the App deveopment process is where you start to see your idea take form! If you’ve prepared properly by following the steps in the previous sections, the build phase will likely be the most statisfying part of the process for you!

During this phase, you’ll need to be vigilient and pay particular attention to how closely your developer is following the user experience, user interface, and feature set that you’ve outlined for and with them.

Skills

The skills required to be successful are not small in number. I don’t want to overwhelm you by listening out every skill that might be valuable, but I also don’t want you to underestimate the amount of skill and expertise necessary for breakout success.

So, let’s identify some middle ground that we can agree is a good starting place.

First, let’s talk about the skills that are necessary for this specific phase of the process. Software Development, or building the parts of your apps that require the work of a developer.

Technical skills

I hope that you weren’t under the impression that there would be no requirement for code to be written while you build your app. I stand by my original claims that you, specifically, won’t need to write a single line of code. But, code does need to be written. There really is no way around that if you want to launch an app with powerful features that solve meaningful problems.

In a later section we do discuss the options of using no code solutions, but just like web apps, no code solutions or a compromise.

Because we are deploying a mobile app for the iPhone platform, you will need a developer that is able to write the code that runs on the platform. If you didn’t already know, the iPhone runs the iOS operating system. This operating system runs software that is compiled from code written in the Swift programming language, as well as the Objective C programming language.

As a result, you will need to find a developer that is competent in those programming languages. It is not required that they are able to write using objective C. The swift programming language was announced by Apple in 2014 and has been among the fastest growing programming languages in the world since that time. If your developer does not write objective C code, that shouldn’t be a problem if they have demonstrated adequate skills leveraging Swift.

In addition to being able to write using the swift programming language or the objective see programming language, your developer also needs to have the skill of creating user interface is based on the designs that you give them. Typically the skill goes hand-in-hand with being able to write the code. However, there are different ways that user interface is are created for the iOS platform.

You UIKit, Apple’s traditional user interface framework, has been around for over a decade and has been used by developers to create the majority of apps that are on the App Store today. unless you find a developer that is new to mobile app development in the last two years, they are likely familiar with UIKit.

In 2019, Apple released a new user interface design framework called SwiftUI. this new user interface design framework allows developers to rapidly develop visual Proto types that can easily be turned into the foundation of your functional apps.

In 2020, Apple made it abundantly clear that they are shifting their focus away from UIKit to SwiftUI going forward. this isn’t to say that support for UIKIT is ending, to the contrary. Even in 2020 when it was clear that SwiftUI is the future of development on Apple platforms, Apple still announced new features and technologies for the UIKit framework.

How does this apply to the skills necessary to build your app? You will be well served if you can connect with a developer who understands both SwiftUI and UIKit.

As a general principle, the best developer is a developer that is constantly learning and implementing new technologies as they become public. If you come across a developer today that is not aware of SwiftUI, you should run in the opposite direction.

I final point regarding the skills necessary for the build phase of your project includes the familiarity your developer has with Apple platform frameworks. if the developer holds himself out as an iOS developer, they shouldn’t be unfamiliar with the various Apple frameworks that they can easily leverage to get your app deployed faster. A healthy and honest conversation about this is crucial upfront.

Tools

There are countless tools that can be levers in the build phase of your app development. So, instead of giving you a specific list of the ones that you should use or avoid, will break down the tools required by general category. That way you can make sure you at least are aware of the types of resources necessary to build with.

First, you will need some sort of integrated development environment (IDE). For developers, this is a no-brainer. They already have an a DE, so you shouldn’t worry too much about that.

Apple provides their own IDE for developers to use when building apps for Apple platforms. Xcode, has all of the writing, building, compiling, running, simulating, and deploying technologies necessary to go from code to an app on the App Store.

Xcode has come a very long ways since it’s original debut. Today, it does the bulk majority of functions necessary in the development process. And, with the newly announced SwiftUI, it is now used almost exclusively for user interface design as well.

Other code editors, might be used by your developer to write different pieces of code that run part of your app’s infrastructure. for example, if your app has a server side component, your developer will likely not be writing that code in Swift but rather a different programming language. Developers tend to use different IDEs for writing this other code. A common one today is Visual Studio Code, a very popular and powerful IDE provided by Microsoft.

Physical tools required for the development phase include a Mac computer that is capable of running Xcode and an iOS device. Xcode only runs on a Mac, and the Mac should be relatively new to ensure it is capable of running the latest version of Xcode. This is important because about six months after a new release of Xcode, Apple stops accepting apps into the App Store that are built with older versions.

Side note

Apple’s rapid adoption of new technologies for developers can be difficult to get used to at first. But, it’s best you get used to it than try to fight it. There are numerous and clear benefits to doing this. It keeps your team lean by not requiring backward compatibility beyond about 1 year, and it allows Apple to focus and provide full support to developers adopting the latest technologies. And these benefits extend to users as well. With 92%+ of iPhones adopting the latest version of iOS, its an expectation that your app do the same.

Timeline

The best way to maintain a timeline for your project is to leverage project management software. There are dozens of powerful and popular project management software options to choose from. To reduce the amount of time you spend picking a good project management software, I would suggest writing out your project plan on paper first, then trying to find the project management software that captures the way that you think.

alternatively, your developer might already have a good project management software that they are using to manage their ongoing projects. Take some time to familiarize yourself with the options that are available, and explore what other people are using and having success with.

In the software development world there are a few different productivity paradigms that are used. You might be familiar with the term agile. Or perhaps you’ve heard of scrum. Other development paradigms include extreme programming, and the waterfall.

All of these software development paradigms have their own way of managing time, resources, and Development priority.

Methodology

As mentioned in the previous section, there are several different paradigms that are used in the development of software.

A large contributor to your decision and your ability to use any of these methodologies is how many people you have on your team. For example, you might be able to adopt an agile Software Development framework for your project, but you won’t likely be able to do a full scrum deployment if you only have one developer working on your project.

A great primer on scrum software development is the book from novice to ninja.

A well-funded project with several developers working on your app allows you to adopt more comprehensive development methodologies. But, if your project only has enough resources to fund one developer, you won’t be able to take advantage of some of the more advanced methodologies.

As a result, the best way to start is to work closely with your developer on expectations and timelines that account for their skills and the complexity of the app you have designed.

It’s important For you and the developer to remain flexible as the build process proceeds. This isn’t to say that you should allow timelines to slip, but because you’re building something that does not already exist, there are things that you don’t know that you don’t know. A healthy culture of understanding and open Ness will allow you and the developer to handle situations of delay in a professional and productive way.

Pivots

You may be familiar with the term pivot in the start up world. Typically this term is used to describe a point in time when they start up realizes they need to entirely change their product offering or business, or both.

In this context I am referring to a technology pivot. A technology pivot is similar to the type of Pivot a start up would make, in that you are dramatically changing directions on something significant in your app.

Doing a technology pivot during the build phase of your project should only be done after careful consideration and discussion with your developer. The need to execute a technology pivot might arise from new information that your developer obtains or new information that you as the entrepreneur obtains. No matter the source, it should be discussed thoroughly before implementation.

You might be wondering when a technology pivot would ever come up. You might be surprised to know that it happens all the time. Because new technology is announced almost constantly, there is bound to be something announced that directly impacts your project. This could be in the form of a something small like a new feature, or something much larger like an entirely new user interface design framework.

The typical response to the announcement of new technology is to push the implementation of that technology in your app out to the next year. This response is usually done by companies that have existing products on the market. However, you don’t necessarily need to adopt this type of response. If your app has not been released yet, you have an opportunity to Adopt the new technology in the first version of your app and avoid waiting a full year.

This has the potential of giving you a strategic advantage over your competitors who are not able to make such a dramatic shift so quickly.

But, keep in mind that making these types of technology pivots close to the completion of your project might have some serious financial as well as launch date implications.

As I mentioned above, this should be the topic of thorough discussion with your developer. It can be extremely exciting, but it is likely to result in more development time and cost. An obvious trade-off for the opportunity to be first to market with killer new technologies.

Alpha Build Phase

The different build phases of app development can be broken into several different steps. We have discussed the design and pre-build phases above, as well as the beginning of the build process with skills and tool set up. In this section we are going to talk about the actual building of your app.

During the alpha build phase your developer will be writing code, lots of code. The result of that code will be a minimally functioning app that looks vaguely similar to what you have designed on paper.

Your developer should first work on the navigation and display of the various screens that your app Will present to users. because you have already gone through the process of mapping out what features go in what parts of the user interface, your developer should have a very detailed guide to help them know exactly what is expected of them during the alpha build phase.

Well you might be tempted to take a step back and let your developer do his work, it’s actually vitally important for you to stay very close to the process during this phase.

I don’t mean that you should be sitting over your developers shoulder as the right code, but you should have a regular check in with them to make sure they are understanding your future to user interface mapping that you have provided. It’s not enough for them to tell you that they understand, the alpha build phase is the time where they should be showing you on an ongoing basis that they actually do understand.

One of the software development tools that is provided by Apple two members of their developer program is a software testing program called TestFlight.

Test flight enables two different types of beta testing to users of the platform. First, you are able to use test flight to distribute early builds of your software to your internal team. Second, if you are able to offer a public beta version of your app to up to 10,000 individuals Who can participate they simply tapping on a link generated by test flight.

During the alpha build phase, your developer and you should make extensive use of the test flight program that allows internal teams to test the app during development. As mentioned above, you might be tempted to leave your developer to their own devices while they do their work during this phase. Don’t allow yourself or the developer to except this as the normal way of doing business. Insist upon the use of test flight for early builds of the app to be deployed to you and others that are on the team.

As the entrepreneur and the one funding the development, there’s no quicker way to lose track of progress or cost them to not know where your project stands on a daily basis. Test flight and access to early builds of the software help prevent that from happening to you.

Beta Build Phase

As mentioned in the previous section, TestFlight is a powerful tool that allows entrepreneurs to share their app with up to 10,000 beta testers before it becomes publicly available to the world through the App Store.

While you might be tempted to give me the access to anyone that has shown remote interest in your app, that wouldn’t be wise at this stage of development.

The data build phase of your app is a time for serious bug tracking and bug smashing. At this point of your development, all of the features that will be launched with your app should be in each one of the beta builds of your app. There shouldn’t be any question about what screens are in or out, or what features are in or out.

At the beginning of the beta build phase you should expect there to be more bugs than at the end of the Peterbilt phase. When your app is stable enough during this phase, that is when you should feel confident and comfortable with starting a public beta for your most passionate and close fans. However, being passionate and close doesn’t necessarily mean they should participate in the public beta program.

When selecting the individuals who will participate in your public beta, you should initially focus on those individuals who understand how beta software is expected to behave; buggy.

You should also prepare instructions to public beta users so they know what features and screens you already plan to address in the final stages of your development. You don’t want to waste the precious little time that they contribute to providing feedback to them telling you things that you already know.

So, each time you release a update to your public beta, you should provide instructions to your users for what they should be focusing their testing on.

it’s worth repeating, your public beta testers are not individuals who find your idea fascinating or to think that it would be a great solution to the problems. Your public beta testers should be a little more technically inclined than that. Otherwise, you run the risk of alienating potential customers that expect your app to just work

App Store Submission

There are a number of requirements that you must satisfy in order for your app to be excepted by Apple and published on the App Store.All of these requirements are clearly outlined in the Developer portal. They look very similar to the boilerplate language that you would get before installing software, but you shouldn’t treat it like that.

The specific language around what your app needs to do to satisfy the requirements for App Store approval should be you’re number one focus at this stage. Apple has demonstrated that they will not hesitate to reject your app for reasons that you might think are insignificant. They enforce the policies of the App Store approval process strictly.

Because this is the case, you do not want to be found in open violation of requirements that are clearly stated in the documentation. Take time to read it. Take time to discuss it with your developer. Take time to ensure that you are meeting the requirements in each section.

Failure to do this will result in your app being rejected. In some situations, the result of App Store guideline violation is not just a rejection of your app, but a removal of your entire developer account. Effectively blocking you from launching this or any other app.

I don’t mention this to alarm you, but to impress upon you the importance of adhering to the guidelines strictly.

In addition to following the App Store guideline requirements around what your app can and cannot do – this includes providing adequate justifications for requesting access to user data in your app – You will need to provide artwork as well as text beastdescriptions of your app. This artwork and these descriptions will be in the form of screenshots, video, and other graphics.

Just like the functionality of your app needs to strictly adhere to the App Store guidelines, the artwork and screenshots that you provide must strictly adhere to the dimension requirements for the App Store.

The current App Store submission portal does not provide functionality to crop your uploaded images to the proper dimensions. You need to create images that are the right dimensions before you upload them. If you try to upload an image that does not meet the requirements, those images are rejected.

Once you have met all of the requirements for visual and textual descriptions of your app, you can then hit the submit button but will put your app in the queue to be reviewed by Apple. This process can take anywhere from a few hours to a few weeks. However, you should expect something closer to a few hours if your app is relatively simple.

Prior to hitting the submit button you can specify when you want your ad to be released once it is approved. You can say that you want your app to be released the moment that it is approved, or you can specify that you would like to manually release the app after it is approved, or you can specify a date that you would like it to be released that is likely to occur after the date the app is approved. Obviously, if your app is not yet approved and the date that you have specified has already occurred, you will need to manually release your app after approval takes place.

Congratulations, if your app has been approved by Apple and you have released your app out to the world, you are now officially the owner of an app deployed on the App Store.

While it might feel like the end of the process, real success comes from all of the work that you do after your app is deployed. But we will get into those topics in later sections. Let’s wrap up by talking about how we can maintain the app that we built going forward.

Maintenance

There are a few specific instances where you will be forced to pay attention to the technical health of your app in the form of maintenance.

• When a bug is detected by one of your users
• When iOS is updated by Apple
• When you want to change or add features in your app.

I hope you didn’t think that once the app was deployed to the App Store that you could say goodbye to your Developer forever. If you went through the design and development process the way that I outlined it, you could potentially say goodbye forever to the developer you worked with to build the app, but you won’t be able to say goodbye to Developer‘s forever.

Unless you want to step down from your strategic position as the owner and Entrepreneur to learn how to work directly with your code base, you will need to continue to work with app developers into the future.

Did you expect anything less? After all, you just launched a software company!