"You should create a mobile app!"

We used to get that all the time. Multiple times a week. So I tasked Jack (aka BoyScout) with creating the mobile version of the site. It was his first assignment after starting here at PCPP.

Initially we thought we might go after multiple apps - iOS, Android, and eventually Windows Mobile. (Jack is a Windows Mobile guy, bless his heart. One of the few. So it was like one of those, "I feel for you" pats on the back to let him know I'd be ok with him investing time in building an app for that platform one day, even if I knew it'd never pay for itself dev-time-wise.) After a short while we figured that a mobile site would be a good placeholder while we started working on native apps.

A mobile site lets us hit all the platforms at the same time. It also lets us test out functionality and mobile UI much faster. Want to change something? No problem - don't resubmit to the App Store. Just push the new code live and see how it does.

One thing we realized was that putting the PCPartPicker functionality into a mobile interface was hard. PCPP is fundamentally a very data dense site. Before the UI rework with Phil Coffman, it was crazy dense. So fitting all that into a mobile interface was really challenging and required a lot of thinking on how to best present it. The current strategy is that once we feel like we have the mobile site where we want it, we'll be able to quickly go after native apps.

Though on native apps - a word of warning... We won't be providing an offline mode. The current compatibility databases in PCPP are quite large, so there's no reasonable way for us to ship that inside an app footprint. It's just not going to happen.

With the desktop site redesign, one of the thoughts was whether we wanted to go with a responsive design or not. To get things out faster, we opted to not go with responsive design. However, I think in the long run we do want that. It's just that it's a ton of work and testing. So there's the possibility that we may take the current design and make it responsive (down to mobile) while applying the usability lessons we learned from the mobile site. If we went that route, that might delay native apps a bit more.

The other thing is that we're a small team. Jack is tasked with mobile work, but also several other things. Some of the other things (not yet public) I think are significantly more important that native apps. I think when people see what those things are they'll agree. But what it means is that we have to look at mobile from a time perspective. I think the functionality competing with Jack's time is more valuable to end users than native apps.

Anyhow, that's a bit of what's going on with native mobile apps. It's not a clear answer, because, well, things can change every week.