Washing the Car
expresswash_us.png

Project information

Website: www.expresswash.us

GitHub organization: github.com/ExpressWash-9

GitHub, iOS app: github.com/ExpressWash-9/expresswash-ios

TestFlight: testflight.apple.com/join/xOHV2Zmj

This was my Lambda Labs project at Lambda School, an eight-sprint course to design and build a real, working application with a team of other student engineers.

You can download and run this app via TestFlight, but no one will come to wash your car because there is no company backing this app. 😉

"Shark Tank" demo

At the end of each Labs cohort, students vote on their favorite projects. The top four teams are chosen to participate in a Shark Tank-style review. Watch our demo below for an overview of both the web and iOS apps for ExpressWash.us.

Tech stack

The iOS app was built in Swift 5 using UIKit and Core Data. We used Cocoapods to integrate Mapbox for the map displays and Stripe for payment processing. Robert and I built this app from the ground up.

The web back-end runs on Node.js and communicates with the front-end and iOS apps via a REST API. Check out the README on the front-end and back-end repos for more details.

ExpressWashScreens.png

Challenges faced, lessons learned

UX

Our team was originally assigned two UX engineers who were going to design our interface. Due to some changes at Lambda School, they were pretty quickly removed from our project, well before we got any designs from them. This lead to us spending more time on design and not having as clear of an idea about the app's user flow before he had to start coding, but I believe we did a good job of overcoming this.

 

It also lead to design differences between the web front-end and the iOS app. The web team inherited an existing app that was minimally functional. They spent their first two release canvases making sure that the back-end worked well and met our needs, and only at the end did they tackle the front-end. They tried to adopt some of our design elements, but didn't have time to really make the two versions of the app look the same.

What I would do differently: It's tempting for software developers to want to start coding right away. We spent a few weeks talking about the purpose of our app and how we might make it work, but not enough time on design and flow. Of course we worked out the kinks this caused as we went, but spending a little more time up front on flow (if not design) so that everyone understood the steps a user would need to execute would have been beneficial.

Unexpected time constraints

The Labs program lasts for eight sprints. In the part-time program, each sprint is two weeks at five days per week, three hours per day. The first couple of sprints are dedicated to introducing the program, getting assigned to your project, and then planning. All of this is expected.

Because of the COVID-19 crisis, the school decided to remove one sprint for everyone as a way to help us adjust/cope with the dramatic changes in the world. While the break was welcome, this eliminated 30 hours of work time. This happened very close to the beginning of Labs, which meant that even if we wanted to spend our now free time on coding for the project, we would not be able to; the project simply hadn't been planned and approved yet.

How we handled it: On the iOS side of things, we knew that we had a lot to do since we were building the app from scratch. Our first release canvas was very large, so we made our second much smaller so that we were sure we could complete in the time allotted. In the end, we were able to finish everything on time and only felt some minor strain while polishing the app at the end.

Core Data, JSON, et al

I spent most of my coding time during the first half of the project on the data model and associated controllers, although a couple of them were done by Robert. Because of the way the data was structured on the back-end, I had to manually implement coding and decoding of the JSON and create representations of each class to act as intermediaries. Getting this right took more time than expected, and we ran into complications that required back-end developer support when Swift's strict typing conflicted with JavaScript's loose typing. It would have been possible to change my decoding methods, but both teams decided it was best to have things working correctly. Luckily the web team was made up of some amazing guys, and we were able to coordinate and get things fixed quickly

iOS-specific issues arose later when dealing with Core Data itself. I learned a while back that this was one area of our training at Lambda that was lacking, and this project highlighted the gaps in my knowledge. We ran into a couple of instances in which Core Data objects became duplicated, and I had to track down where we were going wrong. I'm sure there's still more that could be improved in this part of the app as it stands today.

What I would do differently: This app is actually not super complicated as far as the data that's required for display, and if I had to do it over again from the beginning I would forgo Core Data altogether. The app already communicates with the server for pretty much everything and re-fetches the relevant data, so it's not really necessary to store it in a local database on the device.

That being said, I'm very glad that I did use Core Data. It gave me a chance to dive into it more deeply than I had previously, and to learn some better practices to use in the future. I know what to watch out for now and have a better idea of how to manage the local data and why. Core Data is very powerful, and even more so when combined with CloudKit, and I look forward to utilizing what I learned in the future.