One of our major goals for the first half of this year was to release the official WooCommerce iPhone app. While we released the app a bit behind schedule (in July), we were still really excited to get our first iOS app out the door and to create a mobile store management tool that we’d want to use ourselves.
However, the process of building the app wasn’t entirely smooth sailing, so we figured we’d share some of the details behind development and the lessons we learned along the way now that we’ve had a couple of release cycles under our belt.
Lesson 1: Aim Big — it’s possible
We’ve had the wheels for this app in motion since early 2013. At this point, there was no way to easily connect WooCommerce to any external system (including an app) – in fact, WooCommerce 2.0 was just being released. The only way to connect WooCommerce to an external system was to build a plugin that could be installed, then connect the app to this plugin.
However, we saw that there would be a bigger need for the ability to connect WooCommerce to other services, and that a real API would be a huge benefit to the WooCommerce ecosystem instead of a closed plugin just for an iPhone app. We’d already approached WooCommerce about this being a joint-venture, and we all agreed that building a REST API was the way to go.
If you don’t think your app is possible, chances are that you can make it possible. We learned a tremendous amount in building the initial API and app, and our business was better for it.
Lesson 2: Build or Outsource?
We knew that we could begin development on the app before worrying about connecting it to WooCommerce, so the question was whether to build the app ourselves, or hire someone to help us do so.
While Justin and I were interested in learning more about developing in Objective-C for any future apps we might want to build, we didn’t think we could continue to be aggressive in building new WooCommerce extensions while also learning/developing in Obj-C. We made the decision to instead find someone to lead development of the app.
We lucked out in finding a really excellent iOS / Mac developer in Justin Schottlaender, who’s worked on the app with us from the beginning (we affectionately call him iJustin amongst ourselves). With the engineering of the app locked down, we also needed someone to lead design and usability.
Fortunately, partnering with WooCommerce included a great person for this part of the project: Jay Koster, who is a truly excellent frontend developer, and is one of the major designer / developers behind WooCommerce itself. We were therefore ready to start building with WooCommerce (a la Jay) contributing design (everything from screens to icons), iJustin joining on the SkyVerge side and ready to build and guide design / UX, and myself and Justin at SkyVerge to help out with the WooCommerce side of things and to manage the project (features to include, integrating with WooCommerce, etc).
If it’s your core competency, build. If not, outsource.
Lesson 3: You’ll hit bumps in the road.
Building out the initial spec for the app was fairly smooth, and we were really excited to keep moving forward with the project once we’d had a basic concept in place (as much of the development on the app side could be done without being connected to WooCommerce).
However, the teensy-tiny hurdle of building a REST API was left. As WooCommerce 2.1 turned into a huge project, building the REST API was consistently delayed, which pushed the project back. At about this time, I started to lead the REST API development, so the development for this was actually driven forward by the app.
As we had a limited amount of time to get the REST API out the door, I had to make decisions on what was absolutely needed to be in the first version of the API, which would decide what could be done with the first version of the WooCommerce iPhone app (though this process probably warrants a post in itself). This was fairly challenging as we wanted the app to have more features than we could realistically build in the time available.
We started with read-only functionality for the API due to these constraints, which would let us get version 1 of the REST API out, and we could at least begin to connect the app to our WooCommerce test stores to ensure that everything would work as expected.
Expect that things won’t go smoothly, and get to a minimum product as soon as possible.
Lesson 4: 90% done is really half-done
This is the way it goes with most software products. “Almost done” usually means about 90% done, and 90% done really means you’re half done. The app was no different.
We were wrapping up development shortly after WooCommerce 2.1 was released. Even though we thought we were ready to cross the finish line, there was still a lot to be done before app could be released.
We polished up how the app read information from WooCommerce stores, patched parts of the API that needed to be patched and began beta testing. This last leg of the race took longer than I thought it would, and with the benefit of hindsight, I’d actually let it take even longer.
We beta tested the app in different environments, and purposely only gave beta testers a bit of documentation to see what questions they would ask.
If you’re looking at your own roadmap, know that the last step isn’t the last step; by the time you get there, it will actually be the last 10 steps. Plan accordingly.
Lesson 5: Worst Case scenario? Nope, there’s worse.
Sometimes you don’t realize that the assumptions you’re making are assumptions, which later proved to be a problem with the app launch. For example, some of our beta testers were familiar with what the WooCommerce API did, which meant that they understood the limitations of version 1.0 of the app and didn’t push it to either break it or ask us, “Why can’t it do XXX?”
We also really underestimated the diversity of WooCommerce hosting. The major difference between our app and something like Twitter is hosting. If you use something like the Twitter or Facebook apps, you’ll have a consistent experience because they have control over the entire process – from the servers that host the API to the app itself. Users have to run an updated version of Facebook since they can’t control the updates themselves. They can’t run Facebook on their own servers. They can’t modify Facebook or run tons of 3rd party add-ons inside of their Facebook profile. This isn’t the case for WooCommerce.
All of these introduced potential points of failure, which made this app far more complicated to launch and support. We can’t control hosting or server environments, the WooCommerce version in the store, 3rd party plugins (which can introduce conflicts), or added functionality — not to mention the hurdles with security and caching plugins, which can tend to blindly cache or block legitimate parts of the API. The sheer number of variables here were hard to calculate, and they introduced points of failure that users aren’t used to since they compare this app to Twitter or Facebook.
Despite attempts to try the app out on different hosting, we ran into a huge issue with servers that don’t properly recognize basic HTTP authentication (yep, they do exist). Luckily we had previously built a fallback for this issue into the API (see issue 5207) as we found that 10% of users were using hosting servers that didn’t allow us to authenticate their API credentials.
Moral of the story: what you think the worst case scenario is will never be the worst. We ran into way more issues with hosting environments than we anticipated.
We also ran into far more conflicts than we thought we would, as this was the first full-scale test of the REST API. For example, we ran into an issue with WP Super Cache that threw an “API not found error” – none of our test sites used this, so we didn’t encounter it until launch day tickets came in.
Basically, we thought we’d had a solid test group. We were wrong – there are so many more issues that can arise, and we’ll take more time in the future to test tons of plugins, even more hosting environments, and any crazy server configuration that we can.
Lesson 6: How do you fix things?
The deploy process for an iPhone app is also way different than it is with a plugin, which changes how you look at things. If we run into an issue with a plugin release, we can typically deploy a new version with a fix within a couple of hours if urgent.
Minimum turn around time for an iOS app? 2-4 days. Typical turnaround is more like 10 days, as Apple reviews each submission for update.
When we released version 1.0 and discovered some server incompatibilities, we were obviously all-hands-on-deck fixing it. However, even though we were able to get the fix ready to go by the next day and submitted the following day, we had to wait 3 days before it was pushed live (we even had the review expedited by Apple).
I can’t stress how important lesson 6 was for us: when something goes wrong, how does it get fixed? How long does it take? After we’d learned more about this, we tried to be more extensive with testing each release, and we even ended up scrapping one feature for a later release because testing showed it consumed too much battery power and had inconsistent performance.
Lesson 7: Knowledge is power
We also tried hard to educate people on how the app works, but still had questions like, “Why can’t I add products?” and “Why can’t I just use this with WooCommerce 2.0?” We tried to get people excited about using the app first, then making sure they understood requirements for the app. At least that’s how the process went in our head.
However, it was more like, “Oh there’s a WooCommerce app? Cool, getting it. I’d like to add some products from my phone.” But the app doesn’t do this (yet — the REST API didn’t support it then). Despite efforts to clarify that the app was WooCommerce 2.1+ only and that some requirements had to be met, we (a) had people ignore this, and (b) should have been more insistent about this in copy, marketing, and other content.
For example, users that had sites in maintenance mode were unhappy that they couldn’t connect the app to their shops. We had to explain that if visitors can’t find your store, how can the app find it to connect?
Now that the REST API has been completed, some of these features are possible, but this was a major time-suck in answering emails / support about the app at first.
Lesson 8: Expectations are Key
We knew that users would want to add products, add orders, and do all sorts of stuff with the iPhone app. However, we could have managed expectations better (which ties a bit to knowledge). Yes, there are still going to be people that didn’t read anything we wrote about the app, but at least we can point to this information as a reference. This kind of functionality is certainly coming, but until the REST API gets to that point, the app can’t add this functionality.
So why did we launch it? We needed to know what people actually want – what issues they have, what they’d pay for, and what’s most important to them. We needed to validate our ideas before we invest tons of time and money into building them into an app.
Does this affect the happiness with the app currently? Yep, but it’s a risk we need to take in order to improve the app and WooCommerce in the most efficient way possible. Otherwise, we could spend time adding tons of features that nobody actually cares about.
The moral of this lesson is that getting people excited about your app is great, but their expectations are more important than their excitement.
Our Advice
First, everyone asks, “Why didn’t you go with Android first? You’re crazy — it has way more users!” Despite the temptation, don’t go that route if you’re not comfortable with it. The decision to go iOS first is one we’d make again.
Yes, there are more Android users. However, development for iOS is easier, as you don’t have to worry as much about out-of-date versions of the operating system. We were able to require iOS 7.0 at release with a 0% effect on our users. You can’t do the same thing in Android, as there are versions in the wild that are 4 versions back (and users update far less frequently), and it’s used with so many different types hardware that a consistent experience can be tough to manage. We had to worry about that enough ourselves with the WooCommerce app since we don’t have control over the site it connects to.
You also don’t have to worry about 10,000 different screen sizes with iOS app. The App store is more establised as well, and iOS users are more likely to purchase apps versus Android users.
However, the most important reason we chose to go with iOS is that we know it. We use it and we’re familiar with it — we know what we like and don’t like. This was more important than other reason in terms of our ability to make a product we were happy with. For an initial launch, it made far more sense for us than an Android app, and you should start with what you know first.
Once you’re ready to launch your own app, definitely go the route of more testing. Even though it felt like we did enough, we didn’t. Test more. Test the worst scenario, then try to find one worse and test that.
Make sure you educate your audience, even at the expense of getting them excited about your product. Yes, both are important, but you’ll be doing the right thing by your customers.
