Full-Stack Developer & Technical LeadSmashing Boxes2013-2016 Featured by Apple on the App Store
The Challenge
When I was given the opportunity to work on our surf forecasting application at Smashing Boxes, I took it without hesitation. CRNT was to be our first product that was our own. The only caveat – I had to develop both the iOS and the backend side of it, and it all worked well because I had just come from many years of backend development. Just like me, Raleigh, one of our designers, was himself a surfer and I believe the idea was his own – a really clean and easy-to-use application that allowed people to check the surf conditions on the spots they wanted. The user would be able to have a list of favorited spots, quickly click on them and see forecasts. The design that Raleigh brought in was very innovative at the time and gave the user something they didn’t have in other applications – a way of quickly seeing everything pertinent to them at a glance.
Building the App
iOS Side – Getting My Hands Dirty with Core Graphics
The iOS side of things contained a lot of Core Graphics code – as you can see in the screenshots, the design had a lot of custom elements and graphics that I had to build from scratch. It was actually a really fun experience to create graphics with the tide information and have it shift over in a way that the graphic line would overlap perfectly with the vertical line showing the current conditions for that specific time. I had a lot of fun using my math knowledge (which was probably my favorite subject in university) to make that happen.
What made this challenging was that we couldn’t just use standard UI components – everything had to be custom to match Raleigh’s vision. But honestly, that’s what made it exciting. I love when a project pushes you to learn new things, and Core Graphics definitely did that for me.
Backend Side – Where Do You Even Get Surf Data?
When it came to the backend side, I decided to go with PHP which was what I had developed with up until that point. I was pretty familiar with creating API endpoints through code, but how about the logic for getting surf forecasting data? How was I to obtain that and how could I leverage any sort of existing data point to be able to return forecast for a specific location?
That’s when I discovered NOAA – the National Data Buoy Center. As you can see on the image below, NOAA has many bouys spread around the world and, thankfully for me, an API that I could hit in order to get data. CRNT needed data like wave height, tide conditions, water and air temperature, among other things. I devised an algorithm that would obtain the surf spot’s latitude and longitude “draw a radius” of a specified distance and find all of the bouys available in that radius. The code would obtain as much data as possible from the first bouy, and fill in the missing pieces with the next closest bouys in the list. This helped paint a more complete picture of what the surf spot’s conditions were like – and that approach turned out to be pretty accurate according to our users, even compared to other sources like SurfGuru.
The API was built with PHP at the time, and it was honestly a great experience to be able to not have to ask “the backend developer” for changes to certain endpoints because… well, I was that backend developer! 😂
How It Turned Out
I’m pretty proud of what we accomplished with CRNT. The app ended up being featured by Apple on the App Store, which was incredibly exciting for our whole team. But what really made me happy was the user feedback we got.
One review that still sticks with me said: “the most accurate surf app that works with the Watch OS I’ve found and I’ve tried all of them. It’s the closest to Surfline which is by far the most accurate.” When users are comparing you favorably to Surfline – which is basically the gold standard for surf forecasting – that tells you you’re doing something right.
The multi-buoy approach really paid off. Instead of relying on just one data source like some other apps, we were painting a more complete picture of the conditions, and surfers could tell the difference.
What I Learned
CRNT taught me so much about end-to-end product development. Being responsible for both the iOS app and the backend meant I could optimize the whole system in ways that wouldn’t be possible if I was just working on one piece. When you control both sides of the equation, you can make decisions that benefit the overall user experience rather than just your part of it.
It also reinforced something I already suspected – I really enjoy working on projects where I can see the direct impact on users. Building something that people actually use to make decisions about their day (like whether to go surfing or not) is incredibly rewarding.
And honestly? It was just fun. Working with Raleigh, combining his design vision with the technical challenges, figuring out algorithms, doing math calculations for the graphics – it felt more like solving puzzles than work most of the time.
What I Used to Build It
iOS Development
- Objective-C
- Core Graphics
- Core Data
- UIKit
- Watch OS Integration
Backend & APIs
- PHP
- MySQL
- REST API Design
- NOAA Data Integration
- Geolocation Services
The Fun Stuff
Real-time data synchronization
Mathematical calculations for tide graphics
Multi-buoy data aggregation algorithms
Custom Core Graphics animations