How to create an App Prototype and set up a development process in Xcode 14 + Cloud
Make an app prototype fast with these tips.
Here’s part 2 of a step-by-step guide to building an iOS app.
You can read about requirements, use cases, sketches, and design files in part 1.
Here, I’ll continue with how to set up your development process and create an app prototype.
Setting up a workflow
Set up the repository. To hold your documentation, files, and source code, you need a repository such as GitHub.
If you decide to outsource development, it’s crucial to set up a repository on your side and ask for daily contributions.
There are a couple of reasons for this — finding freelancers on Fiverr or Upwork is relatively easy, but getting great results on time is another story, especially if it’s something not easily copyable from other publicly available sources and requires custom research and work.
I’ve hired freelancers many times, and quite often, an assignment was canceled by the freelancer simply because they couldn’t deliver what was promised.
There are plenty of stories about how bad Upwork is for a freelancer (like this or this), but you, as the client, also have to constantly keep an eye on the progress and check the deliverables.
Set up continuous integration and delivery service. To simplify the building, testing, and distribution of builds for testers, it’s very handy to have it in your workflow. There are many services that do this, such as GitHub Actions, Fastlane, CircleCI, and so on. I’ll cover Xcode Cloud as it’s simple and integrated with Xcode.
In the beginning, two workflows should be enough:
Development — just starts building the app on the GitHub repository master branch change, when developers commit/merge their code.
Release — archives and distributes to internal/external testers on the GitHub repository release branch change, when the master branch is merged into release.
Later I’ll add testing, but for the prototype, this is more than enough.
Create a prototype
Finally, you can start building! You are ready to hand over use cases and design files to a freelancer or build it yourself. Since I know a little bit about coding myself, I’ll go that route. Here are some tips:
- Start small. Begin with a small set of use cases, and always test a freelancer should you decide to outsource development.
As a prototype, I only implement a card list and individual cards that are displayed when taped.
I’ll expand on this in further iterations. Setting small milestones allows you to see results faster, and it’s so great to tap yourself on the shoulder while pressing release, right?
- Start with visuals. Begin with pure displaying logic, nothing else. At first, the goal is to get an implemented design, most of the screen states, check how it looks, with hardcoded values, images and texts, as well as test navigation and animations. This is the best approach to tackling unknowns at the beginning. Without thinking, you will know by the end of the development what data needs to be stored and what backend services will be required going forward.
- Structurize. This is the most important point. It’s easy to write code that computers understand, but to write code that is readable and maintainable by people requires some skills. And this is the part that fails most often with outsourcing. So, keep a constant eye on what is going on inside. The source code must be in the right place and well structured. I will cover this topic further in upcoming posts.
- Externalize. Keep your font, colors, style, and texts externalized as much as possible from the very beginning. When you decide to change something, it will be an easy task, otherwise going through thousands of files is no fun, and this kind of thing happens regularly.
- No perfection. It’s a prototype, and nothing is final here, so don’t go overboard with testing. We’ll eliminate issues further into the process after introducing automated testing — you don’t want the QA team clicking your app all day, right?
Okay, back to creating the prototype.
Because such an app requires lots of low-level customization, I’ve chosen to implement it using native Swift but with new data bindings and concurrency that will allow for easy conversion to SwiftUI eventually. I haven’t chosen to use SwiftUI right away, as it lacks the required functionality out of the box, and in most cases, it would be wrapped in good old ViewControllers anyway.
I use MVVM architecture as it works well in UIKit and SwiftUI and allows easy testing. Oh, and no drag-and-drop xibs or storyboards, as it seems Apple doesn’t like no-code anymore.
After following the listed tips, here is the app source code, some screenshots,
and a link to a testflight build for testing that was built and distributed by Xcode Cloud.
That was easy, right? :) Time to add some tests. This part is covered in How to add Snapshot Tests in Xcode 14 + Cloud.
